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!

On the second to last assessment with my former employer I couldn’t help but shake my head as I heard the raging debate within the organizations. One half who had the overall control of the network were pissed that management was allowing half of the network users to run around with administrative level permissions. That’s right, over half of the user base had admin level credentials to their local machine. The thing was it was a university! Technically the machines were physical property of the user but it was attached to the network most of the time. The main problem which was in the process of being corrected was a lack of network separation.

I recall being asked by the administrators to display to management the risks of allowing users to run as local administrator. Outside of the legal liability of having them install and run P2P software, there is the unauthorized access aspect from the execution of malware. What was really funny is their grievances with the CS students who, no matter what the network administrators did to block outgoing traffic always seemed to circumvent their controls. As auditor I found this horrible, but as a cs major I found it quite entertaining. What I ended up doing was showing a 46 second camtasia video that MC had made on his blog showing remote code execution on a fully patched Windows XP SP2 machine. My immediate statement after the conclusion of the video was:

46 Seconds (long pause) That’s how long it took. You may not understand the full technical aspects of what just happened, but I assure you that what happened was full administrator level control of that workstation (pause) IN LESS THAN 46 SECONDS! From there on out I had their full attention!

This brings me to two posts. First a post that dean had done on Carnal0wnage a few months ago, and a recent one I picked up on google reader; Titled Testing for Client side Vulnerabilities. It’s an interesting post that doesn’t necessarily deliver a technical means in which to test but certainly outlines a few items to consider as a pen tester. One thing I personally can’t wait for is a client side framework to come out. You can use metasploit to test for the exploitation aspect of client sides but on a large scale I’m not sure how feasible it is. From attending Austin Hackers I know HD Moore is currently working on integrating Karma and Metasploit. This will also have the effect of having a client potential in it that can rotate through the currently implemented metasploit modules and test the workstation for any potential vulnerabilities that may exist on the connecting client. I’m sure that if it’s not it’s own module it would only require a few adjustments to make it into a client side tester. Custom implementations can then document certain things such as the connecting IP, what client side vulns may impact the machine and then you can go from there.

While we are waiting on that however, you can use javascript to rotate through the CSLID’s you have exploits for and test which ones are installed on a machine. From there you can go one of two way’s, you can either 1 just document the CSLID and IP Address or you can press on to exploitation. I guess that depends on both your time constraints and your ROE.