There have been a lot of discussion and misconceptions about Battle.net's authentication lately. Having done a lot of work on the Battle.net protocol, I wanted to lay some to rest.
The first thing to understand is that, at least at the time I was working on this, there were three different login methods (this is before they combined the Web logins with Battle.net logins - I can't speak on those). The three methods are:
- CHAT protocol - deprecated a long, long time ago
- Old Login System (OLS) - used by Diablo, Warcraft 2 BNE, Starcraft, and Diablo II
- New Login System (NLS) - used by Warcraft 3, World of Warcraft, and in some fashion by newer games. Also supported - but unused - by Diablo II
I'll describe, in detail, how each of these work. The summary is, though, that at no point does a game client ever send a plaintext password to the server. The closest is the SHA1 of the password, which is used for account creation in old games. For more information, read on!
Today, I thought it'd be fun to take a good look at a serious flaw in some computer-management software. Basically, the software is designed for remotely controlling systems on networks (for installing updates or whatever). As far as I know, this vulnerability is currently unpatched; there are allegedly mitigations, but you have to pay to see them! (A note to vendors - making us pay for your patches or mitigation notes only makes your customers less secure. Please stop doing that!)
This research was done in the course of my work at Tenable Network Security on the Reverse Engineering team. It's an awesome team to work on, and we're always hiring (for this team and others)! If you're interested and you have mad reverse engineering skillz, or any kind of infosec skillz, get in touch with me privately! (rbowes-at-tenable-dot-com if you're interested in applying)
Two weeks ago today, Microsoft released a bunch of bulletins for Patch Tuesday. One of them - ms11-058 - was rated critical and potentially exploitable. However, according to Microsoft, this is a simple integer overflow, leading to a huge memcpy leading to a DoS and nothing more. I disagree.
Although I didn't find a way to exploit this vulnerability, there's more to this vulnerability than meets the eye - it's fairly complicated, and there are a number of places that I suspect an experienced exploit developer might find a way to take control.
In this post, I'm going to go over step by step how I reverse engineered this patch, figured out how this could be attacked, and why I don't believe the vulnerability is as simple as the reports seem to indicate.
Oh, and before I forget, the Nessus Security Scanner from Tenable Network Security (my employer) has both remote and local checks for this vulnerability, so if you want to check your network go run Nessus now!
As I'm sure you all know, I normally post about IT security here. But, once in awhile, I like to take a look at physical security, even if it's just in jest.
Well, this time it isn't in jest. I was at Rona last week buying a lead/asbestos/mold-rated respirator (don't ask!), when I took a walk down the lock aisle. I'm tired of all my practice locks and was thinking of picking up something interesting. Then I saw it: a lock that advertised that it could re-key itself to any key. Woah! I had to play with it.
Now, maybe I'm an idiot (in fact, my best friends would swear it). But I hadn't ever heard of a lock that can do that before! So I did the obvious thing: I bought it, took it apart, figured out how it worked, then took pictures of everything.
This is part 3 to my 2-part series on password reset attacks (Part 1 / Part 2). Overall, I got awesome feedback on the first two parts, but I got the same question over and over: what's the RIGHT way to do this?
So, here's the thing. I like to break stuff, but I generally leave the fixing to somebody else. It's just safer that way, since I'm not really a developer or anything like that. Instead, I'm going to continue the trend of looking at others' implementations by looking at three major opensource projects - WordPress, SMF, and MediaWiki. Then, since all of these rely on PHP's random number implementation to some extent, I'll take a brief look at PHP.
In my last post, I showed how we could guess the output of a password-reset function with a million states. While doing research for that, I stumbled across some software that had a mere 16,000 states. I will show how to fully compromise this software package remotely using the password reset.
This is part one of a two-part blog on password resets. For anybody who saw my talk (or watched the video) from Winnipeg Code Camp, some of this will be old news (but hopefully still interesting!)
For this first part, I'm going to take a closer look at some very common (and very flawed) code that I've seen in on a major "snippit" site and contained in at least 5-6 different applications (out of 20 or so that I reviewed). The second blog will focus on a single application that does something much worse.
It's rare these days for me to write blogs that I have to put a lot of thought into. Most of my writing is technical, which comes pretty naturally, but I haven't written an argument since I minored in philosophy. So, if my old Ethics or Philosophy profs are reading this, I'm sorry!
Most of you have probably heard of the exim vulnerability this week. It has potential to be a nasty one, and my brain is stuffed with its inner workings right now so I want to post before I explode!
First off, if you're concerned that you might have vulnerable hosts, I wrote a plugin for Nessus to help you find them (I'm not sure if it's in the ProfessionalFeed yet - if it isn't, it will be soon). There's no Nmap script yet, but my sources tell me that it's in progress (keep an eye on my Twitter account for updates on that).
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.