Metasploit Module: MS09-004 Microsoft SQL Server sp_replwritetovarbin Memory Corruption via SQL Injection
Type: exploit
Path: modules/exploits/windows/mssql/ms09_004_sp_replwritetovarbin_sqli.rb
Platform: win
Disclosure date: 2008-12-09
References: OSVDB-50589, CVE-2008-5416, BID-32710, MSB-MS09-004, EDB-7501, URL-http://www.secforce.co.uk/blog/2011/01/exploiting-ms09-004-via-sql-injection/

Description:
A heap-based buffer overflow can occur when calling the undocumented
          "sp_replwritetovarbin" extended stored procedure. This vulnerability affects
          all versions of Microsoft SQL Server 2000 and 2005, Windows Internal Database,
          and Microsoft Desktop Engine (MSDE) without the updates supplied in MS09-004.
          Microsoft patched this vulnerability in SP3 for 2005 without any public
          mention.

          This exploit smashes several pointers, as shown below.

          1. pointer to a 32-bit value that is set to 0
          2. pointer to a 32-bit value that is set to a length influenced by the buffer
          length.
          3. pointer to a 32-bit value that is used as a vtable pointer. In MSSQL 2000,
          this value is referenced with a displacement of 0x38. For MSSQL 2005, the
          displacement is 0x10. The address of our buffer is conveniently stored in
          ecx when this instruction is executed.
          4. On MSSQL 2005, an additional vtable ptr is smashed, which is referenced with
          a displacement of 4. This pointer is not used by this exploit.

          This particular exploit replaces the previous dual-method exploit. It uses
          a technique where the value contained in ecx becomes the stack. From there,
          return oriented programming is used to normalize the execution state and
          finally execute the payload via a "jmp esp". All addresses used were found
          within the sqlservr.exe memory space, yielding very reliable code execution
          using only a single query.

          NOTE: The MSSQL server service does not automatically restart by default. That
          said, some exceptions are caught and will not result in terminating the process.
          If the exploit crashes the service prior to hijacking the stack, it won't die.
          Otherwise, it's a goner.

Check method (fingerprinting):
# the ping to port 1434 method has two drawbacks...
    # #1, it doesn't work on mssql 2005 or newer (localhost only listening)
    # #2, it doesn't give an accurate version number (sp/os)

    # since we need to have credentials for this vuln, we just login and run a query
    # to get the version information
    version = mssql_query_version
    unless version
      return Exploit::CheckCode::Safe('Could not retrieve SQL Server version')
    end

    print_status("@@version returned:\n\t" + version)

    # Any others?
    return Exploit::CheckCode::Appears("SQL Server version #{version.strip} appears vulnerable") if (version =~ /8\.00\.194/)
    return Exploit::CheckCode::Appears("SQL Server version #{version.strip} appears vulnerable") if (version =~ /8\.00\.384/)
    return Exploit::CheckCode::Appears("SQL Server version #{version.strip} appears vulnerable") if (version =~ /8\.00\.534/)
    return Exploit::CheckCode::Appears("SQL Server version #{version.strip} appears vulnerable") if (version =~ /8\.00\.760/)
    return Exploit::CheckCode::Appears("SQL Server version #{version.strip} appears vulnerable") if (version =~ /8\.00\.2039/)
    return Exploit::CheckCode::Appears("SQL Server version #{version.strip} appears vulnerable") if (version =~ /9\.00\.1399\.06/)
    return Exploit::CheckCode::Appears("SQL Server version #{version.strip} appears vulnerable") if (version =~ /9\.00\.2047\.00/)
    return Exploit::CheckCode::Appears("SQL Server version #{version.strip} appea