Pentoo Updates

Blah blah BT4 blah blah your mom goes to college....

on other sweet distro fronts some updates to Pentoo have arrived

You can read about them here:

http://pentoo.blogspot.com/2009/02/cuda-stream-mpi-and-multiforcer.html
http://pentoo.blogspot.com/2009/01/deadline-approaching.html

support for the GPU cracking is very cool. I'll ask grimmlin if I can post the link for the current alpha ISO for people to play with and the rumor is a beta is coming soon!

ShmooCon Time!

ShmooCon is almost here and I'm exited to see old friends and meet/make new ones.

I'm currently scheduled to do a "Fire Talk" sometime between 2100-2200 on Friday nite. I'll be talking for a few minutes on "Attacking Oracle with the Metasploit Framework" and I have a video demo to go with it. Hopefully it will wet the appetite to download the mixin and play/test with the code and make suggestions on features and functionality.

More info on the Fire Talks and other podcasting type stuff here: http://www.podcastersmeetup.com/

I will of course be blogging and tweeting throughout the con.

See everyone this weekend!

New Shool Information Gathering Toorcon X Edition Video

I ripped the DVD from my talk at Toorcon X on New School Information Gathering.

Should be embedded below.


Toorcon X Gates: New School Information Gathering from carnal0wnage on Vimeo.

Sorry I dont have other videos and dont know when/if they will ever be released.

Identity Theft Protection Racket

Really good post on philosecurity on Identity Theft and the Protection Racket the Credit Card companies are running.

I tend to agree, if the credit card companies were really losing money everyone would have credit alerts and locks for free but right now, like data breaches, its really the user's problems and not the credit card companies or the people that lost the data.

Of real interest is that it mentions LifeLock got sued because it was issuing credit alerts on behalf of its customers.

"Last year Experian sued identity theft protection firm, LifeLock, for activating fraud alerts on behalf of hundreds of thousands of clients. Experian “claimed that alerts should be entered only when people have already been victimized by identity theft or have legitimate reasons to believe that they are at imminent risk.” (Network World, 2008.) I’ve heard that “identity theft occurs every 79 seconds.” Does that count?"

http://philosecurity.org/2009/02/02/identity-protection-racket

Fastflux makes for some cool graphs

So after the last post on automation by CG I figured I'd change track a little and take a look at something that is of interest to me. Data Visualization. I've found it to be incredibly useful in not only tracking down anomalous behavior on a network but also for displaying metrics and data to the non technical folks. Visualizing data from a security perspective can show some interesting and valuable information.

Take NetFlow logs for example. While there is no payload information, if you're able to gather the logs from an entire network you can determine everything from infected hosts scanning your network to attacks against a web application. I've not actually done it but I'm sure there are ways to apply visualization to offsec as well. Maybe not in the actual pentest but possibly in the reporting/debriefing stage. It would be interesting to graph the path of compromise into the network with the attack vectors used and overlay that with the defensive measures [Patching policy, IDS/IPS, FW, etc...] in place in the target environment. It would be a really powerful way of showing how the network was compromised. If I get some time I'll try and gather some data and generate some visuals depicting that. I strongly recommend 'Applied Security Visualization' by Rafael Marty and 'Security Metrics' by Andrew Jaquith for information on data visualization and metrics for information security.

Lately I've been looking at the Waledac aka 'The New Stormworm' bot and it's fast flux capabilities. It's spreading via email spam messages. These e-mails contain different domains that are part of a fast flux network. Each of the domains has it's TTL set to 0 for the DNS record so virtually each time the domains are resolved a new IP address is returned. I took 82 known malicious domains associated with Waldac and using a simple perl script ran forward lookups against each domain gathering the ip and country information associated with that IP. I then stripped out any repeat addresses. I gathered approximately 2500 unique IP's in the short time I ran the script. Using Rafael Marty's Afterglow scripts and Graphviz's Neato I generated some simple link graphs of the source <> target pairs. In this case the source would be the domain and the target would be the fluxing IP address.

What's interesting about this graph is that it's immediately apparent that some domains are not fluxing and appear to be static. Perhaps this is intentional, perhaps they are no longer actively being used in the spam emails and are no longer part of the flux network or perhaps it's a misconfiguration on the authoritative DNS server for these domains. Unless you have access to Layer 7 traffic in an environment it's somewhat difficult to detect traffic to these domains using only NetFlow traffic but Emerging Threats and the folks over at the Shadowserver Organization have Snort sigs for detecting traffic from infected hosts.

As a curiosity I took the country location information for the IP addresses of the infected hosts and looked at the Top 10 Countries from that list. It's interesting to see that China and Korea have the largest percentage of infected hosts. This may be skewed by the time my script was running or it may be that the bot has been spreading longer in those countries. The above data, while interesting, is probably not that practical from an security admins perspecitive though.

Recently I needed to determine the potential number of hosts infected by the IE7 XML Parsing exploit. In order to do so I gathered NetFlow logs from the environment and next built up a list of known domains hosting the exploit. This list was gathered from multiple sources. Obviously this list is not comprehensive and likely there are numerous other domains hosting this and other exploits but it was a good start. Next I determined the IP addresses for these domains and using some Perl and the NetFlow traffic generated a list of unique source IP ranges with established communication to those malicious domains.

After generating the link graphs I was provided with a quick visual representation of which hosts had communicated with those domains. This created a quick list of potential infected hosts. I've since updated the graphs to show different colors for the subnets in the network, allowing me to determine areas that show greater infection rates. The next step is to determine the patching levels in those subnets with infections. This was done by looking at the SUS server logs. If the host was patched it could be assumed that it was not infected. Of course this assumes that the patch actually installed correctly too. :)

These malicious domains hosted more that one browser exploit though. Some of these domains had upwards of 20 unique exploits listed. Now we all know from using exploits for various 3rd party apps that these are seldom at the latest patch levels. So likley many of these stations were infected in some manner. The next step would be to determine what sites hosted what exploits and add an additional column in the csv file that contained this exploit information. Re graphing the traffic would show which hosts communicated to those sites. So if you knew that all manged/imaged workstations in that location had Adobe Acrobat 8.0 installed and some had visited a site hosting a pdf exploit you could determine that they were possibly infected. This does assume that you know what software is on those systems though. Waaay too many assumptions for my taste. The advantage of my graphing this data was that it had a very powerful visual impact that backed up my recommendation to establish and maintain block lists on the firewalls and to improve patching policies for third party apps. A very tangible dollar value could be applied to this as well. Each machine has a cost associated with it being infected and now needing to be rebuilt and patched before being allowed back into the network. Add to this the loss of employee productivity and you have a strong argument for blocking and improved patching controls.

There are other methods of doing the same thing but hey, I like looking at visual representations of the data and when dealing with huge data sets it can assist in picking out patterns that may hint at infections or other anomalous traffic.

Cheers,
dean

More on too much automation

I'm not the most articulate person, especially in writing, and while I thought by the people that bothered to comment on the blog, I got my point across other people make me think I didn't.

So, I'll try again, if this doesn't work I'll resign myself to just not being as l33t and skilled as other people in the community.

I'm not against ALL automation, by its very nature everything involved with "hacking" or penetration testing is automated but I'll try to restate. From the orginal post:

Automation is a good thing but when it comes to pentesting I really think there can be too much automation. Too much automation leads to "fire and forget" activities and lack of TLC.

Believe me, I'm all for bash running my nmap scan and rolling IPs for me all nite rather than stay there and do the stuff myself. I'm all for automating a tool that needs to run a set of commands on a subnet or group of hosts given the appropriate scenario. Hell I'm even all for running scripts that will log into every box and "do something" (go tebo!) also given the appropriate scenario.

But what I'm not for (but I do concede there are plenty of times when the following is perfectly acceptable and maybe regarded as "good" pentest):

Rolling in and run my full port nmap scan, nessus scan, core impact rapid pent test, connect to a couple of agents, take screenshots, high five with my team mates on how l33t I am, then head out and write the report.

I'm of the opinion that for the above scenario, a couple weeks of training and a couple of licenses later any in-house shop can do that for themselves.

I will propose that there is an alternate type of pentest where my goal is not to root as many boxes and I can but its too see if I can gain access to "what makes the company money". I am unannounced, trying to not get caught is part of the test, and where the customer actually has a great patching program, an IDS, possibly and IPS, an outbound proxy, somebody actively monitoring the previous technologies, and asking them to turn all that shit off is not going to happen....

how would our above scenario fair for that pentest?

how fast would your pentest be over if you did say....

"For example, I enumerate open shares on the entire subnet, then pull down all .doc documents, then search them for interesting information from the recon phase (i.e. the name of the CFO)."

I'd give it about 2 minutes before any SOC that doesn't totally suck blocks your ass and you have to go begging for them to unblock your IP...that's never any fun.

I wont address everything from the pauldotcom show notes, because frankly I think they completely missed the point of the post (because I am not against all automation), but I will address this.

"[PaulDotCom] - While I agree, automation can have a negative effect on risk identification,
its a vital part of every penetration test. Much of the post talked about how automated tools "Don't have the love" and "you need TLC". That's all well and good, but how do you show risk when you've got a meterpreter shell on 30 hosts? What are those hosts? Do you spend 3 weeks of your time and the customer's money to demonstrate risk? No, you automate the mundane tasks and pieces and parts that can be automated. "

I guess my response would be why do I need 30 shells to demonstrate a point? how would I have gotten those shells without being really sure about what/where the host was before I launched anything that would have gotten me a shell? but if ./autohack ran on a subnet and gave me 30 shells then I guess I might find myself wondering what are all those hosts and how did I get in. As for risk identification, if I got 30 shells the risk identification is an enterprise patching problem in this scenario.

"This does not make you any less skilled or a script kiddie, in fact, it makes you more of a master."

umm how? did I have to run a nessus with credentials to find those vulnerable hosts after checking 100's of KB's and throwing tons of traffic at the hosts or did core impact throw 20 exploits at each box before I got lucky and popped a few? Or did I limit my exposure and try to enumerate what services were running and what service pack the host was and try the latest exploit at one host to see what would happen?

I'll spare you the rest, like I said I think the point of the post was completely missed.

When automation is too much automation or where's the TLC??!!

Like the"hiring geeks" post by ax0n said, we automate. Automation is a good thing but when it comes to pentesting I really think there can be too much automation. Too much automation leads to "fire and forget" activities and lack of TLC.

For example there are a couple scripts out there that try to automate your whole scan, enumerate, and exploit process and all the pentest frameworks have some sort of autohack feature and they all suck (as much as it pains me to say that --especially because I am such a msf fanboy).

There is a certain amount of diligence I think that should be applied come actual "exploit" time. Scripts that automate or allow a "tester"(?) to script too much of the pentest while handy can cause real damage on a network, not to mention MISS things, possibly IMPORTANT things.

I've heard that some people will spend a ton of time writing a tool that will run everything from nmap and a bunch of different exes, some that do automated exploitation like adding rogue user accounts if it finds null passwords or something, or whatever random exe's that can find on the net. run that script and go for lunch.

The problems arises that:

1. That much output really saves you no time if you go back and actually go through and validate the results.

2. Seems like no one knows how to enumerate and certainly no one teaches it. Automating all the steps between scan and exploit don't help the lack of enumeration either.

2. There is no "test" you just ran a bunch of tools, the script did all the "work."

3. There is no personal experience or tester analysis if you just run a script. There is no thinking outside the box or expertise involved if you hit the autohack button or ./autohack.rb

4. What about stealth? what about tactics? what about proper footprinting? what about emulating anything besides a script kiddie attacker?

5. Where is the fun and challenge in having the script do all the work for you?

6. Every pentest is (at least should be) a battle of minds against the tester and the people admining and securing the network. If you've got any kind of decent admin the easy low hanging fruit should be patched up but that doesn't mean there still aren't vulnerabilities to be found and exploited by an experienced tester. Its all about finding the one thing that guy missed and then digging in from there.

7. There's no TLC with autohack, for the amount of cash you paid for a "real" pentest, there should be some love and work from your tester, that nessus report just aint cutting it.

Moral of the story, show some TLC, get good (better) at your craft and don't rely on the latest autohack script to do things for you.

Serving Up Malware via Ad Networks

So nothing new to serve up exploits via ad networks but I thought it was cool that someone was serving up a pdf exploit via the Ad Network

From http://www.curse.com/forums/t/69161.aspx

"I was looking at GridManaBars when Avast popped up a virus, 3 times. Twice on the addon's page, and once on the download page. I just viewed the page again, but nothing there.

Here's Avast's log.

12/2/2008 7:11:31 PM SYSTEM 1132 Sign of "JS:Packed-T [trj]" has been found in "hxxp://76.74.154.110/zv00108/pdf.php?id=9702&vis=1" file.
12/2/2008 7:11:31 PM SYSTEM 1132 Sign of "JS:Packed-T [trj]" has been found in "hxxp://76.74.154.110/zv00108/pdf.php?id=9702" file.
12/2/2008 7:11:50 PM SYSTEM 1132 Sign of "JS:Packed-T [trj]" has been found in "hxxp://76.74.154.110/zv00108/pdf.php?id=9702&vis=1" file. "

Url looks similar from what I recall, it's traced back to valuepromo.net. Ad banners I assume?

A robtex of that IP gives you two others in the valuepromo network

76.74.154.110 server2.valuepromo.net
76.74.239.45 server3.valuepromo.net
76.74.239.143 server1.valuepromo.net

http://www.robtex.com/dns/qiweroqw.com.html

google for those IPs and you'll see all kinds of people complaining about AV alerts and browser crashes.

The best stuff is here though

http://forums.techpowerup.com/showthread.php?t=81570

"
http://76.74.154.110/zyyqoeiwrueq/pdf.php?id=14273&vis=1

i'm sitting at techpowerup.com homepage and it takes me to this ^^ and brings me to a blank pdf document.... about 6 hours ago today, at techpowerup's homepage, it opened up acrobat reader (outside of firefox) with a blank document...."

Opens up a blank pdf, yeah that's not good...

On a more fun note, think of the damage you could do to competitor ad network by getting them to serve up malware and get their whole netblock blocked? good stuff.

Winzip FileView ActiveX Exploit

It's not new at all [CVE-2006-5198] but I noticed that MSF did not have any coverage for Winzip's vulnerable ActiveX methods and the PoC's that I found did not work for me so I put this together last night. The great thing about Winzip is that, like Adobe Acrobat, no one updates it. :-)

[1] WinZip FileView (WZFILEVIEW.FileViewCtrl.61) ActiveX

So run 'svn update' and have fun.

Cheers,
/dean

Interview with an adware author

really good interview with "Matt Knox, a talented Ruby instructor and coder, talks about his early days designing and writing adware for Direct Revenue. (Direct Revenue was sued by Eliot Spitzer in 2006 for allegedly surreptitiously installing adware on millions of computers.)"

http://philosecurity.org/2009/01/12/interview-with-an-adware-author