 Hi, my name is Fufas and I'm here to give a little talk at DEF CON, which is a very exciting thing for me. I've been coming for a number of years and I've always really enjoyed it and I always apply to give a talk and this is the first time I've been accepted. Now there have been a number of really interesting talks so far in the con about Windows security. In particular I would like to pay respect to Jamie Butler's talk on the root kit stuff and Brett Moore's talk on Windows messaging, those were both really interesting and they were ways that people are sort of pushing back the boundaries in terms of what is understood about the internal workings of Windows and really breaking new territory and showing people things that we all thought couldn't really be done. This is not a talk like that. This is a talk about stuff that is already known at least a little bit. So what is it really about? We're talking about getting a better handle on some stuff that everyone has talked about for a long time, but no one is really addressed in a coherent and rigorous manner and we're talking about providing some tools to help produce more thorough and authoritative testing results so that when we go and make these same observations that other people have been making for a long time, we can do so in a way that's more convincing and terrifying. And then also we want to have just some general enjoyment from looking at old stuff and maybe seeing it in a new light. There are a few organizational details I'd like to get out of the way. I have updated the presentation since the time when I... Oh my goodness. It's off the side of the screen. They told me it's 1024 by 768. Well, there are some interesting words off to the side. Just a second. I thought switching to 800 by 600 would be sufficient. Pardon for another resolution change here. Come up here. Thank you. All right. OK, so some things may look a little funny on this now, but we're going to try. So there are a few organizational details. I have updated the presentation slightly since what was written to the CD. That is all available on the website, the actual version that I'm giving now, if you feel like a sense of longing for updated materials. And a lot of people contributed to this talk. Some of them deserve special attention. Joe Mokun sitting in the front row here has done a really great job. He's responsible for the updates to Hydra and to the Samba software that I'll be talking about. And he built the Kizab prototype that we'll be talking about. FenFen did a lot of research and basically handed me the IE split that we're going to talk about on a platter. So I really didn't have to do anything but write some Perl. And then FizGig, also sitting right up here with the elegant blue hair, helped a lot with teaching me how to work the development environment and getting it installed and stuff. I don't know how many of you have installed visualstudio.net. Recently, but it's not always a smooth and quick process. And also, I would like to get some style points for not using presentation software. I am always amazed that you come to hacker conferences and see everyone using PowerPoint or whatnot. It's very funny to me. OK, so when you talk to expensive consultants about risk, which is what all security consultants will try to steer the topic to sooner or later, one of the common things that they talk to you about is trying to rank things numerically. And they say something along these lines. This is a common formula. There are others. But one of the common things that they say is that risk can be measured. And we say that this is the estimated annual rate of occurrence. In other words, how many times per year you think a bad thing will happen to you multiplied by the estimated single loss expectancy. So in other words, how severe the consequences are for you. And hopefully you have this information in some sort of handy flipbook format that will show you exactly how bad things are for you. And from this, you should be able to calculate risk. So this is a well-known thing. And people have talked about it for a long, long time. But historically, people have a bad tendency to underestimate risk. And a good and interesting example of this is at the end of World War II, the Allies embarked on something called Project TICOM, which is the US sent people in behind what was German-controlled territory. And they rounded up Nazi cryptographers. Now, it's well known probably to most people in this room from watching cool spy movies and stuff that towards the end of the war, the Allies had been reading a significant portion of Axis encrypted traffic. The enigma machine was pretty much broken via a number of different avenues. And so the Allies wanted to know how much the Axis knew about this, how aware were the Germans of this. Because they wanted to go into business after the war selling enigma machines to other foreign nations, and it would be convenient if the secret didn't get out. So they rounded up the cryptographers and they said, hey, boys, what do you think? Did you know that your machines had any problems? And it turns out that when they talked to the actual technical cryptogies, they all knew there were problems. They all said, yeah, we know there are weaknesses in our system, and this or that thing might happen. But no one would ever really go to all that trouble. And so there was sort of banking on this. This is a documented thing. There's a link to a description of this in the bibliography. They knew that the enigma system had problems, but they didn't think that anyone would go to the trouble of actually doing all the work to crack it. If you look at Michael Howard and David LeBlanc's book on writing secure code, it's a Microsoft press book. It's actually a very good book, I like it a lot. They have in the, at the end, they have a top 10 list of lame excuses that they've heard from developers about why they didn't make their software better. And the two of the ones that I wanted to cite today were no one will do that, and also why would anyone do that? This is a very funny sort of lazy wrapper around the idea of security by obscurity. Security by obscurity is the mistaken belief that by hiding stuff, you can actually control that annual rate of occurrence for your bad security events. That's what security by obscurity is all about. And of course, the moment that the secret is out, you can have the annual rate of occurrence skyrocket. So last year, I don't remember exactly when I think summertime, there was a document published in a prominent security philosopher thinker was let go from his job. And nevermind the fact that the place that he was let go from is the long history of letting people go. This is just sort of more interesting because it made headlines. One thing that people talked about was the fact that corporate partnerships were gonna have, start having really chilling effects on security research, and this was a bad thing. And then another thing, the one thesis of the article was that there was an analogy between operating system monocultures and monocultures in biological systems. And so if you had creatures that all had a same genetic defect, when a virus came that exploded that defect, they would all be wiped out. And this is why we have genetic diversity in nature. And so the theory was that maybe the same thing could be said of operating systems in large environments. If you have a bazillion systems and they all have the exact same security flaw, when somebody figures out how to do something with that flaw, all bazillion of them have troubles. So that in itself is a persuasive point. It doesn't necessarily prove that this is worth deploying multiple flawed operating systems in your environment, but it's an interesting thing to think about. So there was a lot of discussion about that too. And I kind of let it go. That was interesting at the time and I forgot about it. And then I went on vacation and I read the Cuckoo's Egg, which is a kind of classic of computer security writing. And I had never read it before and I was trying to catch up on my hacker trivia because I lost in the last round of Hacker Jeopardy last year to Kevin Mitnick's team and I was very bitter about that. And so I thought, I read this. And in it there was a really fascinating quote which is reprinted lovingly in your conference programs if you were to look at the blurb from my speech. And he talks specifically about the Morris Internet Worm, which was of course a fascinating topic to me since that was the very question on the basis of which I had lost in Final Jeopardy at Hacker. And he talks about that very issue and he talks about how that worm was a problem if you were running Berkeley Unix but if you were running AT&T Unix, it was really not such a big deal for you. And so he's making the analogy right back then. He says, oh, it's just like viruses in nature. This was a book that came out in 1989 and spent four months on the New York Times bestseller list. So what was the big idea when someone else just repeated that same idea? Why were people so upset when that same idea just got repeated in recent times? Well, here's my theory. It's sort of like the old loft heavy industries website making the theoretical practical. This idea had been around for a while. Everybody had absorbed it but it had never been said by a real live security professional in a trade journal that people read, well not in a trade journal but in a publication that people would read. And it suddenly got a lot more scary when it was set in that atmosphere. And that was kind of interesting to me. So I thought, well, how can I get in on this action? What kind of old crappy ideas can I dig up and make interesting? So we're gonna address a few specific topics. One is discovery of trust relationships between Windows hosts. And when I say trust relationships, I'll define this a little bit later. But I'm just talking about if you hack one host you basically inherit ownership of the one next door. Taking advantage of those trust relationships without the tedium of cracking passwords, just being able to exploit that in a happy and quick way. Having fun with wireless interfaces that are perhaps a little too promiscuous or friendly with you. And then tinkering with poorly configured web browsers. And everybody already knows that these are problem areas. It should not come as a surprise to anyone in this room that there have recently been security discussions regarding each of these points. And we also know that if you were so blessed as to apply what the consultants tell us are best practices across your network that you would fix 90 or even more percent of these problems. But in general, like the Nazi cryptographers at the end of World War II, people tend to kid themselves by thinking that they've taken care of these problems in some shortcut way or by thinking that the problems won't really affect them and why is that? Because there isn't really an easy way to demonstrate these risks. So that's what I hope to provide today is a way of talking about these things in a more easily demonstrable manner. So I want to talk briefly about, I want to talk briefly about what I consider to be security equivalent hosts. These are hosts which have something in common with each other, such that if you have compromised one, you've effectively compromised the other. You don't really have to do any work to have control or access to the other. So this is a situation in which the security of a community of hosts becomes equivalent to the security of the least common denominator. In other words, the weakest link is the one that will get us in. A classic example of this, I did some consulting for an insurance company a number of years back and their crown jewels were on an MVS system. That's where they did all of their real processing and that was really interesting. But MVS is a reasonably mature model with sort of good security and it's not like MVS Ode gets out there very often. So they did a nice thing though because their users hated to have to remember passwords. They would synchronize passwords between their Windows domain and their MVS hosts so that when you logged into Windows, you didn't have to think of a whole nother password when you wanted to get on to do your claims processing or whatnot. So this meant that if you could own the Windows domain, you owned major portions of MVS. That's security equivalence in action. The Windows domain in those days was actually a relatively porous thing and you could get in when you wanted. And that meant you could impersonate important corporate office in-frame. All right, so the dominant causes of this problem are lax policies or inconsistently, hey, that's better, isn't it, when I take my hand away, inconsistently applied standards or shared passwords between platforms. Those are the dominant causes of these problems. All right, so when you go and look, particularly at Windows networking for this symptom, there is a variety of, it's just sort of a mishmash of tools out there and they all take input in a slightly different way and they all give you output in a slightly different way. There are lots of little tools from different sources so that, you know, it's like global and local from the NT Resource Kit or Enum from the fine folks over at Razor at Bindview. They all want things, you know, sometimes you put two backslashes in front of the host name, sometimes you don't. And they all give you just different kinds of output and they don't even necessarily work real consistently like active directory systems nowadays. Some of these will puke out and not give you complete results. And that's, well, it's frustrating when you're trying to get complete results. So we would like something that gives us a single format for input and output so that we can be consistent about this. We would like it to be a simple command line executable so that it's easily wrapped by something like Perl and we would like it to give our output in a way that's easily imported into things like a spreadsheet or a database or whatever other reporting tool we have so that we can give charts of how many of your hosts suck or how many of them have this bad problem and a consistent user interface so that when you're scripting it in Perl, you know what you've done at once, you can do it all the time. So this is really not aimed for the small environments where it's feasible to do this work by hand and you don't care that the output is funny and you have to munch it a little by hand. It's really not that much. And it's not really aimed at the really well-maintained large environment either because the results should be the same no matter what you're looking at there. This is aimed at the large disorderly environment which is something that we encounter in our daily lives very often. Things with different generations of systems out there. They've had a few different rollouts of software and so forth and we wanna extract information from them. So I have begun work and it's included for you on the CD on the Opportunistic Windows Networking Reporter which is a nice little utility, a command line utility and it's a pretty simple thing. The base executable is just a stub. All it knows how to do is load a certain kind of library and call it. And so we have OWNR module files, .omf files and these just accept commands and run them. So that's just a DLL that exports a single function and the function is called go and we provide a handful of them to you on your CD and these do a few things for you. They'll report the attributes of a user account, all the information that we can get from a user account. Report the membership of groups on a single host. And the output is just a simple stream. You can redirect it to a file and we always try to get as much information as we can out of the API. We're not gonna leave some parameters uncrossed. And so it's just this very simple architecture where we have an executable that calls other little libraries and they all have a single function at the export. And so the smarties in the audience are probably looking up here and saying, hey dude, haven't you just reinvented the comm, only stupider? And so I would say, well, shut up man. So let's have a little demonstration and for this I'm going to have to set the microphone down probably because I'm a bad one-handed typist and I'm trying to squeeze things into one corner of my screen anyway. But you'll notice a few things. When we run OWNR, we'll detect the presence of the different OMF libraries that are there. Each OMF knows enough to describe its own usage so that when you call it, it'll say how it should be called if you didn't know beforehand. Output is character delimited and it gathers more than just the basic information. So included on your CD, you have this and source code and all of the fun things you might want to go with that. You get a handful of the OMFs. You get a test program for debugging because it's a pain with the debugger to step into a library that you've loaded via load library. You want something that's actually linked with the executable. And there's a skeleton program for generating OMFs just to get you started. The OMF generator, or as we call it, the OMFG. OK, so here is the tool actually in action. I've got a little VMware session up here. And oh, great. Well, can we all see that well enough? Yeah, that's actually acceptable. OK, so let's run it. OWNR. No, I'm OK. Thanks. And you'll see it detected that it found these different modules. And there's a lot of debugging silliness in here right now. And when we release the next version, we'll clean up some of that. But we say we have these modules. One that detects information about a user account. And then there's one that will detect information about all user accounts on a local machine. So let's just do that. I'm going to run that against my own machine right now. So then you specify the module that you want to run and where you want to run it. What did I type wrong? S? Oh. That's the wrong module. All users is what I want. And sure enough, all the user information from my local box came back. And you can see that because of Visual Studio.net, I have the SQL debugger there. And there's a test user account. And we gathered it all. And that's kind of fun. Now, what's nice about this is we've got our fields separated with a single colon between the name of a value and the value itself, and then a double colon between value pairs. So this is really nice for importing into a single unified reporting framework so that you can just use tools like grep or awk or whatever you like to parse through that. All right, let's hop out of VMware now. And we've used this in production now a little bit. And I'm going to get myself a little console window here and get that over onto the screen. And I'll be right back. OK, so this is a suite of actual data captured in the wild from a network of about 500 machines. And we're going to show how this tool can actually allow us to derive somewhat interesting information. And I actually am going to grab this up. Thank you, KK. Oh, hands free. OK, so I have scrubbed this data so that you can't tell who it is, I hope. And so we're going to, now one of the interesting things about this data was that we found that the, we were already domain administrators by the time we ran this, so we could get a lot of information. But what's interesting about it is that there was information that, well, just being a domain administrator sometimes isn't all you need. Sometimes you need to be able to show people that this has real consequences. So what if we looked for the string CEO in there? Because there might be a user account for the CEO. Oh, sure enough, there is. That's interesting. Now I have scrubbed the CEO's name, and he is just now user 160. Now user 160 shows up on the domain controllers. OK, great. So user 160 has an account on these domain controllers, and that's very interesting. What else can we learn about user 160? So this is just the simplest possible query. And we don't have enough screen real estate to have it all on there. But what's interesting is here is a machine that's not a domain controller, and the local administrator's group contains user 160. So here's a machine that we might have overlooked otherwise. But it happens to be a machine where the CEO has been added to the administrator's group, which suggests that it would be an interesting machine for further analysis. There might be valuable things there. And that was something that you wouldn't necessarily have determined easily had you not been able to quickly sort through this large body of information. So again, I'm not really inventing anything new or fascinating here. I'm just making some stuff easier that was tedious before. All right, so now it's time for a little musical interlude. This is from the book, which one is this from? This is from Cyber Thief and the Samurai. So I was telling you I was reading a lot of hacker trivia. And the focus of this was largely Kevin Mitnick hacker-related trivia. And after the Christmas attack on his machines, Mr. Shimomura went and spoke at a conference. And I forget the exact name of the conference. And trivia buffs in the audience probably haven't forgotten that. But anyway, he went and tried to explain the nature of the attack, which was based on trust relationships by IP address. Certain IP addresses were trusted to come into his machine. We were unaware. Or rather, we hadn't really taken seriously the threat of IP spoofing yet. So here's the quote. Of course, Tsutomo didn't have to explain the technical details to this crowd. The system's vulnerability had been known for a long time. Two respected security experts, Robert Morris and Steve Belevin, had published papers about it years earlier. But it was such an elaborate method of attack that it had rarely been used. In computer security lingo, it was non-trivial. That meant that it required a lot of time, a lot of patience, and a lot of guts. Not only that, but much of the attack appeared to have been automated. That is, someone had written a computer program, which carried out the attack. That made the attack all the more alarming, because it meant that it could be done by anyone with enough savvy to run the script, which meant basically that someone with slightly above average technical knowledge by hacker standards, that is, like Kevin might indeed be able to pull it off. So this raises a couple really interesting questions. And the first in my mind is, how come nobody constrained together about five sentences regarding Kevin Mitnick without describing him as a substandard hacker? I don't really get that. But anyway, what is also interesting here is that this is a known vulnerability known by smarties in the industry, and yet it was mostly overlooked, because no one thought people would go to the trouble of figuring it out and actually making it usable. So if you want to write your own OMFs to determine interesting facts of your own interest, here's how you do it. You must export at least one function. It must have the following prototype. So it's just like main, basically. It should be thread safe because soon we are bringing you multi-threadedness. It should return one of the meaningful return codes to find in the header files for you, and it should accurately show usage information when it's invoked improperly. So you should note any other modules that it depends on and so forth. If you do those things and you make yourself an OMF, then it is free for everyone to share. You don't need to do any complicated installation or uninstallation. OWNR just detects the OMF when it is in the same directory. There's no conflicts with other versions or anything like that, and each one can call others that are present in a happy way because they all export things exactly the same way. So if you want to reuse some of that code, go right ahead. And hopefully this will be interesting. So the idea of this is to give us the ability to sort output nicely. And I've shown a little bit about how that might be used. You can use the tools of your choice and support your audience in a user-friendly reporting manner. Our goal is to try to provide more authoritative answers to questions like, well, if we have access to an account on one machine, where else might that be helpful? Or what percentage of machines have non-standard accounts or non-standard password policies? Or if we have control of this one machine, what other ones are available to us? All right, so let's step back for a moment and note that another old and familiar fact is that Windows authentication is vulnerable to replay attacks. This isn't news. You see the encrypted hash flag across on the network, and everybody knows you could replay that and be authenticated to a Windows device. There's a tool that's from, what, about 94 or something? An old tool called SMB Proxy, which claims to do this. We were never smart enough to get it to work, but it really would be nice to have that. And so it's been historically kind of inconvenient to take advantage of this fact. And so people, because it's been inconvenient to take advantage of that, people have underestimated the risk of compromise to local administrator accounts. And I really wish I had been able to attend the previous talk on locking down workstations, because this is exactly what I'm interested in. So wouldn't it be nice to quickly check to see if a given password hash is reused elsewhere on the network? And wouldn't it also be nice in the event that it is reused and you do find it to be successful someplace? To be able to mount file systems over there or to schedule commands and run them? Why, yes, I think it would. So and here is where Jomo Kun's contribution comes in. If you are familiar with Hydra, the fantastic password Swiss Army Knife tool from THC, you are already familiar with many of the things that this does. And Jomo Kun has added enhancements to it to do many things. Look for Cisco-enabled passwords and so forth. Just grind on them. And concurrent password guessing on multiple Windows hosts is what's interesting about this. And I say multi-threading, and he corrected me. It's actually using fork. It's not really threads. But multiple concurrent attacks on Windows machines. Lots of tools don't have this built in. Most Windows password grinders are going to go after one machine with a dictionary and an account list. Because only one session at a time is possible between two hosts. But we could have multiple sessions if we just targeted them at different hosts. So now you can quickly check to see whether credentials are shared in a large Windows environment. And you can also rapidly lock out accounts this way, so be gentle. So you could take a password hash table, like PWDumpOutput, and give that as input to this new Hydra thing that he's got. And so without cracking passwords, you can tell whether they are good on other boxes. Just without having to decrypt them, without having to run John or shell out for Loft Crack or whatever. You can just do this nice and fast to find out if the password database that you've captured gives you access to anything else. Now getting this to work for you may be a bit of a challenge. THC has a tendency to release outputs that break the stuff that Jomo Kuhn has contributed. They acknowledge that his contribution is in the source tree, but then the next generation of code somehow walks all over whatever he did. So there are patches that work, but you may not be able to run the bleeding edge version of the code. And this is where you should go to get them. Again, that link is also on your CD, et cetera. And work is underway on a more elegant design that actually uses threads and has built from the ground up to do this task right. And someday that will be available. OK, so we've now been able to tell whether a password hash is reused someplace else on the network. And that's pretty fun. So theoretically, armed with this knowledge, we should be able to mount a remote's file system without having to know that cracked password. And we should be able to schedule tasks remotely without knowing that cracked password. And again, this is all available for your enjoyment. Thanks to Jomo Kuhn, we've got patches to Samba 3, which are good for mounting remote file systems. And also to Samba TNG. And Samba TNG is the one that we like for scheduling remote commands. It's a little flaky for some other things. But it's good, good stuff. Again, taking PWDump output and using that for authentication to remote hosts. So what is the point of this again, now that I've been rambling for a little while? Note that I am not telling you about anything you don't already know. The technical vulnerability is a well-known one and has been for some time. We haven't invented any new techniques either. Everyone has told us for a long time that you can replay the same data across the network and get results. All we're doing is making this a little bit more easy and accessible and maybe scary. So for instance, having seen this, is there anyone here who thinks it's still a good idea to have a local administrator account with the same password on every workstation? That guy, OK. And everybody knows that it's a good idea to minimize the number of local accounts. Because local accounts are always going to be one with the username the same as the password or without a password on it. Somebody's always going to screw that up. So everyone knows that it's a good idea to minimize local accounts usage. And this is why, because with local account access to a machine, I might be able to get other things shared with the domain and so forth. So the expensive consultants have been telling people for a long time, move towards a curb-arised environment, harden your workstations, use an active directory design that compartmentalizes privileges. Now there's maybe a little bit more motivation. How many of you have heard that from an expensive consultant? How many of you have been the expensive consultant and have been ignored? Much greater response, OK. Good. All right. So that was some fun with Windows credentials. It also comes as no surprise that browser security is a hot topic. There are a number of great resources out there. Giorgi Koninski's resources are fun and interesting to read. Malware.com is my personal favorite. Lots of great stuff there. And Luda Yu's got a good collection of things to look at. But so far, most browser attacks have been what the defense people that I talked to call disorganized threats. They're a menace. They can do bad things to you. But they're not really targeted at specific individuals. They're usually targeted towards a victim community, which includes everyone who has this version of the browser or everyone who is vulnerable. We're not really looking at a specific victim in mind and saying, well, we're going to go after this person or this organization with a browser split. Does that mean we don't need to worry about it? Because it would be hard to do, not necessarily. And this is FenFen's contribution. And this is another little program that's available in the VZ file on your CD. The malware.com website has a write up of what they call the malicious shortcut self-executing HTML vulnerability, which FenFen laid on my desk one morning and said, hey, look at this. So it's pretty interesting. And I'll spend a couple seconds on how it works. We write a web page that initializes an ActiveX control called shell.application. Now that's a one that everybody has. But most people have it. We don't allow that to be initialized. We use shell.application to copy a shortcut file. And the malware.com proof of concept code uses the shortcut to paint.exe, because they figure everyone's going to have paint on their start menu. So we're going to copy that shortcut file, but we're going to alter the target of that shortcut to an HTA file that's housed elsewhere on a server that we own. And we're going to launch MsHTA to download and interpret the code in the HTA file that we've got on our evil server. So the HTA file, when it finally gets downloaded and executed, has little VB script that writes the contents of an executable image to the hard disk and then loads and executes that image. So it's multiple steps to get there. So it sure would be nice if we could change that proof of concept HTA to include whatever executable we wanted. So here's a way to do that. Take the executable of your choice and put it in a directory with these files that I've given you. There's a top and a bottom. These are just wrappers for your executable. And then you run this little script, hexify, which generates a middle file. And then you cat those three together. You can send an attachment to your intended victim. And then attachment contains a form that submits itself to your web server. So in other words, it automatically submits itself to your web server. The submission will force the vulnerable web client to download an HTML file that does the shell.application active x trick. If the browser, there is an unwary one, it will download and execute the script in phase two, which now includes the executable that you have put in there. And so the executable also will, I'm sorry, the phase one.html is nice too because it actually redirects the user to the website of your choice. So they may not even really have realized that they visited this hostile site. It redirects them someplace good. This is a trick stolen from Sphere Husby's book on writing secure code called Innocent Code, which is a fantastic book. I recommend it. It's really great. So that's all good and fun. And the sample that we've included is one that we have tried out in production. Also, it's a stupid little program that does a couple of things. It calls getComputerName and getUserName, and then it issues a get to foofus.net with those as parameters. So it's like get whatever question mark my username is, my computer name is. So it doesn't really do anything that bad. And properly configured browsers should not allow the initialization of that active x control. And even up-to-date antivirus should catch that file because antivirus vendors are getting wary to this sort of thing now. And sure enough, our company's antivirus will catch that. And I mean, we're not an antivirus vendor, but the one that we have installed on our desktops will catch that and say, oh, bad stuff came over the web. Help. So we sent this out to some people. Did we get any results? Well, we found a couple of things. The first was that a lot of antivirus didn't block things before they got executed. It would detect them and say that this was a bad thing, but it was already too late by the time it got detected. And the second thing was it wasn't out of date configurations that we found that were vulnerable. Can anyone guess who we found was vulnerable to this attack? Yeah, yeah, you did it, so you're not eligible. Software developers were vulnerable. Software developers who write active x controls in particular because they turn off their browser protection because they don't want to have to digitally sign everything every time they hit the build key to test their work. So they're unwary and they are vulnerable to this. So once again, there's nothing really new here. It's not a breakthrough technical achievement. You can try it out, though. You can give people that very same file and if you want to send me information about your friends, I'll still point to my website. But you can do other things with it and test and stuff. It's nothing really new here. It's been difficult in the past, though, to get information about whose browsers are vulnerable. This is a way to gather some of that information. We can now sort of send out emails to our user base. And by reading the email, their browsers will report back to us whether or not they're vulnerable to this particular hack. That's kind of a nice thing. And it underscores how crucial administration of software on the desktop can be. It's not just enough to lock down the operating system and set good policies and so forth. You also have to worry about the programs that are running in the operating system. So fans of previous presentations from me will remember these slides. And someone in the front row raises a hand. Now this graphic is ridiculously outsized for the screen on which I must present it. And I apologize for that. But when we think about our network, one traditional view is to think about the internal network and it just sort of barely touches up against the outside network at the firewall. That's the point where that's our point of ingress and egress and that's where we're going to enforce policy about what kind of traffic can come through. And so this is one of my favorite points to harp on. And so I will indulge myself a little bit. Nowadays, we're getting used to the idea of some hosts being outdoors. VPNs have allowed us to have some hosts that we treat as internal, but they're secretly outside. And evil packets can land on them. We may protect them in different ways and so forth. But we're getting used to the idea of some internal hosts in the outside world. And wireless networking makes this even more, oh my goodness. This is very funny formatting. Wireless networking makes this even more interesting because conceivably, there are sort of migratory hosts that come and go from our internal networks. We have people, whether they're contractors who come in and have to attach to our wired network to do work, or maybe they are employees who take their laptops home. They have a wireless network at home and they come back in and maybe they haven't turned off that networking card. Or sometimes there's just equipment you didn't even realize had a wireless interface. Almost everything is shipping right now with some sort of card in it. If you buy a new laptop, it's very rare to find ones without that. And so we sometimes find ourselves with pockets of the outside world popping up behind our firewall on the internal network. So there's even been a mention of this in the mainstream press in the internet week about two weeks ago. There was a discussion of the possibility of insecure wireless access at the Democratic National Convention. And they specifically talked about possibly seeing wireless cards in laptops that were attached to the wired network there and possibly attacking those cards and using that as a vector of ingress into the wired network. That's pretty interesting. I mean, it's not a brand new idea, but it's pretty interesting to see it popping up in a regular human readable publication, which is really the first mention of it that I've seen outside of pretty technical trade discussions and kind of inspiring. And I thought it was especially interesting that they didn't really bother to explain it. They just sort of took it for granted that people would understand what this was and they mentioned it. And there's a link to that story in the bibliography as well if you want to go read it. Anyway, I have no doubt that there are some insecure wireless access points there. So windows seem to slide from side to side. I've never experienced that before. Apologize for that. OK, so tools are becoming available for attacking or playing with some of these beaconing interfaces. Hotspotter is one. Hotspotter is sort of custom tailored to the XP client because XP loves to jabber. And we have one that we're tinkering with a little bit called KizApp. Actually, we built it a long time ago, Joe Mocan did. And it's sort of laying dormant for a while because we haven't had the need to work on it. But we're using the net KizMit Perl module. And it consists of a couple different things. We're going to take our laptop and we're going to have two wireless cards in it, not just one. One is for listening. We're going to run KizMit to listen. And we've patched IW event so that we're sending things to standard error and standard out. It's a little easier to look at. And we've written KizApp.pl to watch for probes, for networks. And when we see that, we have our other wireless card where we're running host AP. And when we see a probe for a certain SSID, we immediately announce ourselves as that SSID. And we're running a DHCP server so if someone is friendly enough to associate with us, we'll issue them an IP address and then we can look at them. So this is not something that's ready for prime time. The materials are available on the web if you want to look at them. It's pretty unreliable. It's not really stable, et cetera. There's work yet to be done on this. But we have made some progress so that we have been able to access networks this way. Again, though, before long, this is the sort of thing that's going to be a commonplace risk, just like everyone has been saying, but no one is really worrying about enough yet. All right, that's very swell. Let's move on to the next one. Here's a time for another brief interlude from literature. This is from Shimomura and Markov's book, Takedown. And it's also inspirational. So this is a discussion of the very same story. It's the very same point of history that I was telling with the last musical interlude. Talking about the conference describing the Christmas attack, I noted that the attack appeared to be scripted or automated based on the timing of events. The fact that it had taken a great deal of detailed analysis for me to reconstruct the break, and so this is Shimomura speaking, by the way, was something that clearly hit home with the audience. The situation I was describing was the type of attack that might have been going on undetected beneath their own noses all along. So it's exactly this. The problem is known. The fact that it is not really widespread doesn't mean it isn't happening. And that's a kind of interesting observation. We had a saying that we say to each other sometimes in the, you know, when we're attacking things and we say to each other, well, just because they're lame doesn't mean you're good. So what's in store for the future? One thing is I need to do some rewrite of a little bit of the enumeration when we're talking about multiple user accounts in multiple groups. The API has actually changed since I began work on this, or at least the documentation that's available to me has changed. And instead of using net user enum or something like that to enumerate users, you're now encouraged to use net get display information index and net query display information. So I need to do some conversion there. There are some accounts. If you've created a user account and not done that through the net user ad API, so you've imported it in some weird active directory way, OWNR does not find it right now. It'll show up as a group member, but it won't necessarily show up as a user. So and that's because I'm apparently using an out of date SDK. I need to clean up the code if you actually were to hurt your eyes by looking at the source that is available on the CD. You would see that it is somewhat disorganized could be better. I don't think that's necessarily out of line for something presented at DEF CON, but I'd still like to see it get better. And I'd like to make a couple of more modules. Getting more complete server information, not just user and group information. Doing some careful password grinding. So instead of the brute force hydro approach where we just blast out passwords at the maximum possible speed, let's look because Windows will tell us how many invalid password guesses are left. And let's not lock out accounts. Let's do this in a gentle way. And then going after more than one host at a time would also be very nice just in the interest of speed because it's a pain watching things time out. And maybe giving some better options for handling output right now, you should be able to, I don't right now give you the option of specifying the delimiting character of your choice. I should, that would be better. Things like that, just the niceties. But the basic functionality is there right now. So what are my conclusions? And I'm running a little bit ahead of schedule because we actually started a little bit early despite all of my troubles with getting my laptop to talk to the projector. So the first thing is there's still fun to be had with some old ideas. Sometimes when we look at these familiar ideas they might take on a new meaning or become sort of more intensely interesting as we play with them in more detail. And a lot of times there have been good concepts introduced but no one has really taken them to the point at which they become truly, at their logical conclusion and useful on an everyday basis. And then also the world still has this tendency to coast. If you can't demonstrate something to people it might as well not be real. And so real demonstrations are the way that we're gonna try to produce actual results and get people to take notice of the things that we're talking about. And then the other thing that we wanna do is encourage people to make more informed or better informed decisions about the cost of a fix versus the cost of the problem. So that original little formula that I showed you of talking about multiplying the annual rate of occurrence by the single loss expectancy. Nobody right now has a good handle on how to calculate those things. And this doesn't solve the problem but hopefully will at least get people to be more rigorous with their estimations of annual rate of occurrence. So with that I've been through the material that I came intending to show. I would thank you very much for your time it's been a real pleasure but I also would invite any questions that people might have. Ah, Sunday at Def Con. All right, thank you.