This week Last week Earlier this month Last month Last year (if this intro doesn't work, I give up trying to post this :) ), I presented at B-Sides Ottawa, which was put on by Andrew Hay and others (and sorry I waited so long before posting this... I kept revising it and not publishing). I got to give a well received talk, meet a lot of great folks, see Ottawa for the first time, and learn that I am a good solid Security D-lister. w00t!
Before I talk about the fun part, where I completely faked out my demo, if you want the slides you can grab them here:
http://svn.skullsecurity.org:81/ron/security/2010-11-bsides-ottawa/. You can find more info about the conference and people's slides at the official site. And finally, here's a picture of me trying to look casual.
B-sides conferences, for those of you who don't know, are awesome little conferences that often (but not always) piggyback on other conferences. They are free (or cheap), run by volunteers, and have raw and technical talks. B-sides Ottawa was no exception, and I'm thrilled I had the chance to not only see it, but take part in it. I really hope to run our own B-sides Winnipeg next year!
This is partly an overview of a new Nmap feature that I'm excited about, but is mostly a call to arms. I don't have access to enterprise apps anymore, and I'm hoping you can all help me out by submitting fingerprints! Read on for more.
It's been awhile since I've written on my blog, and I apologize. I'm at a job now where I actually spend my day working instead of pondering, so it's hard to find time! :)
So, what's new with me?
I'm working on some cool new Nmap stuff right now, so I'm hoping to write about that in the next couple months. Web application fingerprinting isn't something I've seen done much, but I'm hoping Nmap can make some good progress on it with the help of Yokoso, Nikto, and some other resources.
This post written by Matt Gardenghi
This is going to be a series of short "how to" articles so that I have a resource when I forget how I did something. Your benefit from this post is incidental to my desire to have a resource I can reach when I've had a brain cloud.
When cracking into a computer via Metasploit, I often (OK, usually) install meterpreter. It just makes life simpler. Well, the other day, I was chatting with @jcran about my inability to get access to network drives on a Novell network. The problem is that Novell maps drives in a sorta funny method compared to Active Directory. At least that was my thought. The problem generally is that Novell handles things extremely differently then AD, that I assumed that things would be different. #facepalm
Some of you may have heard what I did this month. It turns out, depending on who you listen to, that I'm either an evil "Facebook hacker" or just some mischievous individual doing "unsettling" research. But, one way or the other, a huge number of people have read or heard this story, and that's pretty cool.
Although it's awesome (and humbling) that so much attention was paid (at least for a couple days) to some fairly straight forward work I did, I want to talk about this from my perspective, including why I did it and what I think this means to the community. Then, for fun, I'll end by talking about other places this research can go and open up the floor for some discussion.
First and foremost: if you want to cut to the chase, just download the torrent. If you want the full story, please read on....
Way back when I worked at Symantec, my friend Nick wrote a blog that caused a little bit of trouble for us: Attack of the Facebook Snatchers. I was blog editor at the time, and I went through the usual sign off process and, eventually, published it. Facebook was none too happy, but we fought for it and, in the end, we got to leave the blog up in its original form.
Why do I bring this up? Well last week @FSLabsAdvisor wrote an interesting Tweet: it turns out, by heading to https://www.facebook.com/directory, you can get a list of every searchable user on all of Facebook!
My first idea was simple: spider the lists, generate first-initial-last-name (and similar) lists, then hand them over to @Ithilgore to use in Nmap's awesome new bruteforce tool he's working on, Ncrack.
I've thought about this off and on over the last few years. Today I noticed that Kees Leune (http://www.leune.org/blog/kees/2010/07/teaching-agai.html) is going to be teaching a class this school year. He was asking for comments and so here's mine....
I'd like to see a threefold class system. The first class would entail an overview of the 10 Domains. The second would be Offensive Security and the third would be Defensive Security.
There is a reason for that ordering. Without a good understanding of the fundamentals of security (10 domains) the second two classes will have less value. Understanding the idea of physical security as well as separation of duties and such really support defensive and offensive security. Defenders are better when they understand the threats. Therefore, I place Offensive Security before Defensive Security. But that's preference. You could teach them together and make it a two-part class (firewall defense/offense; Linux offense/defense and so forth).
I just released the second alpha build of nbtool (0.05alpha2), and I'm hoping to get a few testers to give me some feedback before I release 0.05 proper. I'm pretty happy with the 0.05 release, but it's easy for me to miss things as the developer.
I'm hoping for people to test:
- Through different DNS servers (requires an authoritative DNS server)
- With different operating systems (doesn't require an authoritative server) -- I've tested it on Slackware 32-bit, Slackware 64-bit, FreeBSD 8 64-bit, and Windows 2003, those or others would be great!
- With different commandline options (also doesn't require authoritative server)
We hired a new pair of co-op students recently. They're both in their last academic terms, and are looking for a good challenge and to learn a lot. So, for a challenge, I set up a scenario that forced them to use a series of netcat relays to compromise a target host and bring a meterpreter session back. Here is what the network looked like:
To describe in text:
- They have already compromised a Web server with a non-root account
- The Web server has no egress filtering, but full ingress filtering, and they aren’t allowed to install anything (fortunately, it already had Netcat)
- The target server has both egress and ingress filtering, and is not accessible at all from the Internet, but the Web server can connect to it on 139/445 (which are vulnerable to ms08-067). The target can also connect back to the Web server on any port.
The challenge was to exploit the target server with ms08-067 and bring a meterpreter session back to the attacker server.
Recently, I was given the opportunity to work with an embedded Linux OS that was locked down to prevent unauthorized access. I was able to obtain a shell fairly quickly, but then I ran into a number of security mechanisms. Fortunately, I found creative ways to overcome each of them.
Here's the list of the biggest problems I encountered, in the order that I overcame them:
- The user account couldn't 'ls' most folders due to lack of privileges
- Process management tools (like ps) didn't work (thanks to the missing 'ls')
- The user account could only write to designated areas, in spite of file permissions
- Architecture was PowerPC, which I have no experience with
- netstat, ifconfig, arp, and other tools were disabled
This post was written by Matt Gardenghi
This is just initial impressions of a beta product.
I've been playing with this for about a week now in an internal network. I have a dedicated box running Ubuntu 10.04 and Metasploit Express. I've noticed that Express loves CPU time but is much less caring about RAM. It's also not multi-threaded. I'd recommend a dual core box as Express will peg one core. If you want to do anything else while Express is running, you need two cores. Still, Express does not require an expensive RAM build out. I've run top plenty of times and seen that the RAM usage remains low even when I've had 170+ shells running. :-p Hopefully, we'll get multi-threading down the road. When multiple tasks are running simultaneously, this lack of multi-threading becomes an issue. Everything slows to a crawl.
This is another special blog written by Matt Gardenghi!
My boss passed around a document about database security in the cloud. It raised issues about proper monitoring of the DB, but offered no solutions.
This got me thinking. I hate it when that happens. Its like an automatic "boss button" that I can't switch off. /gah
For the sake of argument, let's assume we are discussing VMs hosted on some provider's (Amazon) VMWare ESX cluster. This could really apply to any VM on any company's specific VM host, but VMWare is big, popular, and a good basis to work from. Let's say, some marketing exec bought a package that would hold data on a machine in the cloud. (You may shoot him later; right now, you have to deal with the issues of integration into your secure environment.)
Today seemed like a fun day to write about a really cool vector for cross-site scripting I found. In my testing, this attack is pretty specific and, in some ways, useless, but I strongly suspect that, with resources I don't have access to, this can trigger stored cross-site scripting in some pretty nasty places. But I'll get to that!
Interestingly enough, between the time that I wrote this blog/tool and published it, nCircle researchers have said almost the same thing (paper (pdf)). The major difference is, I released a tool to do it and demonstrate actual examples.
I am not a forensics expert, nor do I play one on TV. I do, however, play one at work from time to time and I own some of the key tools: a magnifying glass and a 10baseT hub. Oh, and a Sherlock Holmes hat -- that's the key. Unfortunately, these weren't much help when I was handed a pile of drives and was asked to find out which version of Windows they had been running. I wasn't allowed to boot them, and I couldn't really find the full answer of how to get the version after a lot of googling, so I figured it out the hard way. Hopefully I can save you guys some time by explaining it in detail.
And if there's a better way, which I'm sure there is, please let me know. I don't doubt that I did this the hard way -- that's kinda my thing.
The order of events is, basically:
- Step 1: Copy the system's registry hive to your analysis system
- Step 2: Mount the registry hive in regedit.exe
- Step 3: Navigate to the OS version in regedit.exe
- Step 4: Unmount the registry hive.
If you know how to do all that, then thanks for reading! Check back Tuesday for a brand new blog posting! I have an interesting blog that combines DNS and cross-site scripting lined up.
Otherwise, keep reading. Or just look at the pictures.
There are the usual XSS tests. And then there are the fun ones. This is a story about a more exotic approach to testing XSS....
I was testing a company that had passed all XSS tests from their pentester. I found that they allowed users to write HTML tags. Of course they didn't permit <script> tags or <iframe> tags. (Well, they did allow those, but that was an oops - no server side filtering.) This company had whitelisted a variety of "safe" tags for use by clients.
In honour of this special day, I'm releasing an Nmap script I wrote a few months ago as a challenge: http-california-plates.nse. To install it, ensure you're at the latest svn version of Nmap (I fixed a bug in http.lua last night that prevented this from working, so only the svn version as of today will work), download http-california-plates.nse, and install it.
So, I realized that the reCAPTCHA plugin for WordPress
sucks was marking a lot of comments as spam, when it was actually working and not getting timeout errors (thanks to my egress filtering). I decided to toss it out and go with a math-based CAPTCHA for posts, so you should once again be able to post comments reliably! I'm hoping that by customizing the math CAPTCHA to use different field names/numbers, it should eliminate the same amount of spam that reCAPTCHA did.
Also worth noting: at the moment, registration isn't going to work because I don't have email set up. I'll post an update to that when it's going again. It shouldn't matter, though, registration isn't required to comment.
I also added an infobox on the side (-->) with information about the author of the post, since I've been taking turns with my buddy Matt Gardenghi lately. Now you can see who posted what.
If anything isn't working, or you'd like some feature/widget/whatever that I don't currently have, let me know!
Now that we know what we need to send and receive, and how it's encoded, let's generate the actual packet. Then, once we're sure it's working, we'll convert it into an Nmap probe! In most of this section, I assume you're running Linux, Mac, or some other operating system with a built-in compiler and useful tools (gcc, hexdump, etc). If you're on Windows, you'll probably just have to follow along until I generate the probe.
In Part 2: runtime analysis, we discovered some important addresses in the Energizer Trojan -- specifically, the addresses that make the call to recv() data. Be sure to read that section before reading this one.
Now that we have some starting addresses, we can move on to a disassembler and look at what the code's actually doing. Fortunately, the author made no attempt to disguise the code or pack or or anything like that, so a simple disassembler is all we need to examine the code.
A word of warning: this is the longest, most complicated section. But stick with it, by the end we'll know exactly how the Trojan ticks!
In Part 1: setup, we infected the system with the Trojan. It should still be running on the victim machine. If you haven't read that section, I strongly recommend you go back and read it.
Now that we've infected a test machine, the goal of this step is to experiment a little with the debugger and learn a little about the Energizer Trojan. This can all be discovered with a simple disassembler, but I find it more fun to take apart a live sample. All we're going to do is add a breakpoint at the recv() function and see where it's called from.
This step is going to require Debugging Tools for Windows. If you haven't installed it already, install it on the victim machine.