 Next to me is Mark Kennedy. He's one of our architects in the semantic research lab. We're going to talk to you today about a little bit of proactive security against the malicious code that's being written out on the net every so often distributed in various forms. Mark's going to help out here this morning and actually stick around until the end because he's got some really neat stuff on the other machine and we're going to show you later on. Alright, so I've been starting my presentations for the last year and a half or so with a great quote. At least what I think is a great quote. I'm going to see if anybody has the answer to this. Security is to the internet as somebody. Wake up people. Didn't hear it. Intelligence is to the military. That works. Anybody else? Sounds like a ringer. Bicycle is to fish. I'll give you a hint. Alright, a little hint. Actually, Bill did have the answer. He was an insider. He saw the presentation at Black Hat. Safety is to commercial aviation. This quote actually came from Bartsdale about a year and a half ago. He was relating the state of the internet security to the situation with air safety back in 1937. If we kept safety to 37 levels and had traffic increased to 1999 levels, we'd be dropping two 747s every day. I don't think many of us would be flying. That's the state of the internet security today and that's what we've got challenges to solve. So we're going to talk today about mobile code. And the mobile code is really a concept I think everybody's at least at this point aware of because it really exists in just about any website you go to. People are transferring it through other means as well through email, through FTPs, through downloads and so forth. So most sites are enabled. What we're talking about is traditionally Java and ActiveX, obviously expanding out to scripting languages, JavaScript, VB scripts, but anything could be mobile code. Excel spreadsheets are containers of data. The data itself could be code, could be malicious. And we actually have seen cases in the past where Excel spreadsheets have been used to carry some malicious code and bootstrap it onto your systems. Greeting cards that you may get may in fact be trojanized and we'll show you some of those a little bit later. But generally the concept here is something that's moved between two points, usually with some malicious intent and usually without a lot of activity or action on the part of the user to get it going. This was a little historical. Some of you may be a little more advanced in that, but that's okay. There's always new people and they have to get up to speed. About a month and a half ago we had the love letter. And right after the love letter, there's a guy by the name of Zivronovsky over in Russia. Now maybe some of you are politically astute and know this guy's a little bit on the fringe. Nevertheless, he had a couple of really interesting comments that he made publicly, as he always does. And one of them was, hey, we're going to knock you all down with this type of code. We can launch these things. We can have our scientists create really interesting attacks and send them out to you. And he was really piggybacking off of all the press and the hype that we got off of love letter. Now you put this one aside and you say, well, if this radical individual is saying this, what about all the people that are not looking for the publicity? What about the non-politicians who are actually doing it? And then you start to get a little worried. So you look at the risk criteria here and you look at a number of categories of tools that you're using in the internet space, receiving mail, opening attachments, surfing the web, using the instant messengers. These are all mechanisms by which you move code from outside of your system onto your system. It's not just the floppy drive we used to use back in 1990 or the CD-ROM. So if we look at this, and this I have to give credit, I have a whole team of people here in the front row that I used to work with when I was back at Finjon. And one of the guys who developed some of our best script attacks over there was a guy by the name of Paul, a marketing guy. A marketing guy turned script kitty. He's working his way up. He's here at DEF CON this year learning and trying to move himself up to the next level. But in any case, what he really was able to demonstrate was something that I think everybody should be aware of. How easy it is to go out of the network that you're know and love, go over to say an internet café, have some anonymity, do a couple searches very quickly on some tools, joiner, binder, all these tools that allow you to put two bad things together with a good thing, and basically create your own Trojan. Right? Nasty stuff. Well, some of the software out there, joiner in particular, is so easy to use, it's got a graphical user interface. I mean, it doesn't get any easier than that, right? Bad program, good program, combine them together. Now you've got a good program on top, bad program on the bottom. Send it off to somebody, right? Send the greeting card to your boss. I'm not advocating that. But send the greeting card to your boss, you know, and suddenly he opens up that greeting card, happy birthday, and underneath you've got a little back office install going. Now you can listen to what's going on on his machine, see what he's doing, see what he's typing about your review. Again, not advocating this. You know, don't try this at home. But if you were to try it at home, the tools are available, right? Paul, my little script kitty over there, you know, did a great job. So let's do an example that I think will make a lot of sense, will help bring it home. We're going to interrupt the PowerPoint, we're going to scoot down into lotus, right? The press has always talked about... What is that other program that they use? Outlook. Outlook, right, that was it. So the press always talks about outlook being susceptible, but I mailed myself something in lotus. Two little things here, games and a pinwheel. We're going to launch the pinwheel and see how it works here. So this thing is going to take off. This is exactly how I would launch it if I got anything and this thing goes around. Oh, that's cute, you know, go look at it. And says, I think, hit escape to exit. Lo and behold, you know, little semantic thing pops up, tells you what was going on. And if you actually hit the... There's a couple things, you probably can't read what it says, but we actually created a little directory there. And to see what's going on there, we moved a couple files. Let's see, there's board minutes from April 2000. There's some letters to some girlfriend. Memory scan documents. All kinds of other things that we moved into this directory. Certainly, we could have moved them out the open internet connection should I have been at the moment of time when I was connected, or when I launched this, connected to the net. If we look at some of the other things we did, if this was a Sony VAO or some other machine with an actual camera attached, I could have activated the camera. I could have recorded what was going on in the room. In this particular case, there isn't a camera on this machine, but there is a microphone. And if we listen... If I got anything and the thing goes around, oh, that's cute. Go look at it. The microphone was enabled, engaged, and we recorded some information here. Now, some of you out there saying, okay, I'm a little smarter than you. I'm going to disable the microphones. I can get into my Windows environment and disable the microphone. And I say, wait a minute, I just installed some... I just ran an executable on your system. You think I can't re-enabled what you disabled? And some of you are a little smart and you say, well, I'm going to remove the DLLs, the actual software that caused the microphone to work. And I say, well, you know, I'm installing software on your machine. I can reinstall those DLLs. And some of you are smart and you say, well, I can cut the wire to the microphone. And I say, well, I can't re-establish that. And then, of course, there was a guy who came up to me the other day from this little group called Incutel. Anybody ever heard of those guys? You know, they're the venture capital arm of the CIA. That makes sense. And they said, look at this little nifty device. And he actually can plug it into the side of the input mic here. It actually disables it temporarily. And it really does act as a sever device. It's a piece of hardware. Unfortunately, he kind of laughed about that. He said every so often bumps up against it and breaks it. So he's got a whole supply of these things. But there are things you can do. Obviously, if you've got a camera, you can tape it up and so forth. But these are really serious things. Think about the idea that about a year ago, I think it was, the State Department was bugged, right? Somebody was physically planting a listening device in one of the conference rooms of the State Department. And you think about that and you say, does that make any sense? I mean, what information is actually useful at the State Department? I'd much rather bug the CEO's office at Semantic and find out that accent is in play and do some stock trades in advance of that announcement. That's obviously much more valuable information. So if I could install telephony information, internet telephony, turn on the microphone and just siphon information out of that environment, that's pretty good. That's pretty exciting. Obviously, there's standard information you can get about the environment in which you're executing and we showed that as well. Let's go back to the program that we've already got going here and we'll go on and talk about some other things like how you deal with this. So if you look at this concept, this personal surveillance protection idea, you wonder whether it's true. Can you actually block these things? Now, again, I just discovered that there's a piece of hardware that you can temporarily plug into the side of your machine to block the microphone. That's novel. Can you do it in software? Can you do it without adding hardware to your machine? Can you prevent things from being bugged? This is a controversial slide. Some would argue that back orifice is a good thing. Some would argue that it's a bad. I'm not here to create the controversy. What I'm simply saying is some people may want to know when back orifice is installed on their machine and some may not. Those who do obviously want to know if there's a way to prevent back orifice from getting on there. It was interesting. The government guys, they actually run these experiments all the time. They've been listening to each other for years. They're talking about this now. So this stuff is real. This personal surveillance is happening. It's possible. Here's the classic one. Where's the antivirus? What's it doing? Antivirus is a pattern matching approach. It's a reactive process. We first have to know that something is bad. We first have to know that you've trojanized a greeting card. Understand the pattern in that greeting card. Then put that pattern into the pattern database which then has to be shipped into your desktop. Code scanning is looking for fragments of code that we know. This is how antivirus works. This has worked for ten years or more. The idea is that you can only anticipate so far. You can only anticipate what the next attack stream may be. You don't necessarily have full capability to stop every new and novel attack. That's primarily because there's no dynamic inspection capability inside of the AV product. If you did start to tweak up heuristics or statistical analysis, what would happen is you'd get a lot of false positives and people would be scratching their heads saying, what the heck am I supposed to do now over blocking is a traditionally difficult problem to deal with. If you look at why this isn't really quite adequate, the updates being done after files have been deleted don't quite help you get the files back. The idea is you want to make sure you don't get the files deleted from your system beforehand. Again, adequate for catching known attacks, but not necessarily sufficient for all the new attacks that are coming down the line. Well, obviously we're very good at what we do and we are able to catch a number of variations like post love letter, able to catch 31 variations following that particular virus or worm. We aren't necessarily able to predict what the next one might be like new love. Some heuristics are getting better, especially since the machines can handle it a little better today than they could in the past, but nevertheless we still have this issue of false positives. The idea of getting more reactive is actually a really good one and that's one that makes sense as well. It's a closed loop system that allows you to have something quarantine temporarily and have it inspected and analyzed in an upstream fashion so that new definitions or new updates regarding that particular bad attack can be pushed back down. This closed loop system actually makes a lot of sense. The whole point of this exercise here is to restrict the propagation. In the old days when it was sneaker net, when it was isolated to a particular land segment, we could go out and stop that segment from infecting other segments. We had human time involved. Today we don't have the human time involved so anything we can add to slow down propagation allows us to then function as humans and get back to the business of stopping these types of attacks. This series of quotes I've liked a lot. I've used it for a long time and I still use it today because it still makes sense. It's still valid. The guys over at TREM, our products are inherently reactive. The guys at Network Associates, for those who don't know, that's the McAfee guys, it's impossible to detect all the variables associated with bad attacks, malicious attacks in advance. And even my friend Cary Notchenberg over at Semantic has said we need to re-examine the way we solve this problem, this anti-virus strategy that we've been relying on for the last decade. So let's see where we're going here. We believe that the ICSA has it right. Trojans and Win32 viruses, yes guys, they're a little harder than the scripts but you've got to get into it, are going to be the way that people are going to attack systems in the future. Why? Because users can be social engineered on the network front quite easily. It's easy to get email from your boss and say this must be valid and click it and open it. And once this executable starts to launch, it has all the rights and capabilities, all the privileges you have as a user. So these things are very significant. So what do we do now? We start to look at behavior blocking technologies. We start to understand the types of behaviors that we think are undesirable, types of behaviors that we think are desirable. We want to monitor what programs are doing on the system. We want to understand where they're going, what they're trying to reach into, what they're trying to accomplish. And using that concept of behavior blocking, it is possible to stop bad things without having to rely on updates or pattern updates or definitions. This is very complimentary in fact to traditional heuristics as well as traditional pattern based antivirus. Some of the original research in this area came out of Finjon about a year and a half ago or so. And it talked about the idea that we want to intercept behaviors at the lowest level of the operating system, ring zero. And sitting as a, what some would term as a proxy between the executable that's running and the operating system in fact becomes very useful in stopping requests for operating system services that would otherwise be very nasty. So the idea is identify the operating system services that are higher risk, sit between those services and the executable, track executables as they come onto the system, understand what those executables, where those executables are spawning processes, track each of the processes, and eventually understand that the processes they've spawned may in fact be dangerous. This is a very safe way of doing it and it's very efficient because the executable actually sits way down at the operating system level. It's a very small piece of code and it's very strong against common application attacks that we've seen in the past. And likely very strong against attacks in the future. Also because it's not sitting out in the user mode, it's sitting down in the kernel, it itself happens to be a little bit more protected than an application that might sit at ring three. You force programs in this theory, in this technique to run inside of this sandbox, so to speak, by wrapping them up front and then forcing their execution through this driver. If you look at this particular log again, unrelated to the FinJohn stuff, but if you look at the type of things that you can track or that you might be looking to track, I ran or Mark ran before the executable called Pinwheel. This log is from an executable called Games and subsequently another one called Cartoon. But you can see what this particular program is trying to do. It's trying to open up a bunch of files, a bunch of programs in the Windows directory and you start to think, well that doesn't seem like a logical thing, that doesn't seem like a good thing. This program probably is not going to do something good and based on that type of behavior you can then shut it down. Now what else is interesting here is that you see all the PIDs, all the process IDs that are being generated and you can actually track these back so you have a hierarchical relationship between PIDs that have been spawned by say Outlook or Lotus and see that you want to track those perhaps more with greater intent or with greater observation than you might PIDs that are spawned off of something else. We still need a lot more research in this area of executable blocking or behavior blocking. Obviously finite granularity on programs like Outlook themselves, subclassing the Outlook objects so that we get greater control over the behavior that we want to monitor. Otherwise we're going to still have the traditional problem of over blocking. We also have to understand that a lot of these things can in fact be stopped by looking at the very simple operations that scripts and other executables use. So we can stop things like Love Lugger, like Explorer Zip, fairly well and to the extent that people tend to duplicate off of existing bad code we have a good chance of stopping a lot of the repeat attacks. If we look at a narrower focus and specifically looking at the scripts again with Love Letter there were 31 variations of Love Letter and you have to be able to anticipate what those variations may do. We can look at attacks based on common vulnerabilities without the side effects of false positives or over blocking. This is really good technology for stopping traditionally script oriented attacks and a lot of those are things that we've seen in the last year or so. We can also look at the idea that instantiation of objects spawned by specific programs that are higher risk like Outlook, maybe you can throw Lotus in there as well, is in fact very important as well. I'll be able to understand where it's going. I'm going to turn it over to Mark and he's going to talk about some of the technology that he's been able to pull together in the last few months or a year. Earlier this year I was tasked with trying to address the script based alarm attacks that had started with BWAA and later achieved more fame or infamy with Love Letter and stages. So I was working on a technology which I called Gatekeeper. I wanted to eliminate the scripting engine as the vehicle that worms can attack your system primarily because when a worm is distributed as a script, you're distributing the source code and anyone with notepad can make a new variation and send it on its way. That's what we saw with Love Letter. Most of the Love Letter variations, they changed the subject line, they changed the body of the message, they didn't touch the code because most of the people making those changes didn't understand the code but they didn't need to. So script is requires a much lower level of sophistication for people to do. Microsoft is excellent at providing examples of how to do this stuff. A lot of the worms came from Microsoft sample programs. So I wanted to close that address down and make it harder for people to like these things. So we came up with a prototype technology for addressing the script based attacks. When it was done, it provided 100% protection against all of these script based attacks even though while writing it, I had never seen what these things were doing. I just knew the behaviors that they had to do in order to accomplish what they had been doing. It blocks outlook for the developers too like Melissa even though that was running as a macro inside word. Runs on all the Win32 platforms where Microsoft supports scripting. It's very low overhead. It's only brought into play when the objects that can cause damage are brought into play. And we'll be posting a working beta of this soon. It can work bundled with an AV solution. It's sort of akin to our auto protect solution. Or it could be packaged as a standalone product. I'm going into a little bit of detail about how it works. Script in and of itself can't do anything. It doesn't have any persistent storage native to the scripting interface. In order to do this, it must make use of certain objects, the window scripting host object, the file system object, and the outlook object being the most common. These objects are all known. If we limit access to the potentially dangerous aspects of these objects, we can render these scripts powerless. We do this by stealing common interfaces. It gets a little technical here that the scripting interfaces are implemented via COM mechanism. COM is a common interface with various invocation methods that can be employed. These methods cannot change as one of the rules of COM. We infiltrate this, position ourselves between the scripting engine and the COM objects, and we can then limit what they're doing. We're instantiated on demand, so we're only loaded when the potentially dangerous objects are loaded. What about good scripts? Microsoft came up with the scripting engines because it's a useful technology. If you're an admin for a large network and you need to deploy a job across your organization, script is a very useful way of doing that. Microsoft likens it to the batch files from the DOS environment, and those were very useful. These scripts will use the same objects that the malicious ones do. How do you tell the good guys from the bad guys? The only difference between a good script and a bad script is intent. And intent is very difficult to gauge. So we came up with gate key. Through gate key, we can allow an organization to sign, not digitally sign, it's not quite the same thing there, but they can indicate this script originated from within our organization, therefore it is going to be trusted. It's a companion technology to gatekeeper. This is a first generation pass at it. Ultimately, you can digitally sign the script itself and use that signature. But the mechanism is what really is being discussed here is not that it isn't spoofable, but rather that you need to have a mechanism to sign what you've created and then use that reference. The keys would be at a very small functional unit, so maybe my division has its own key for running the scripts within that. So you could spoof my key and run in my division, but as soon as I send it over to another division, it's not going to run there because it doesn't have their key. So it's designed to stop the broad based attack. Love letter went out to everybody. Anyone running script could be affected by it, but if they had been running this technology, they wouldn't have been. It communicates with gatekeeper to allow access and full functionality to the objects if the script is trusted. The administrator specifies the keys, so it protects you against external attacks. Internal ones are another issue. There's follow on technologies we could do with that, but that's beyond the scope of what we're going to talk about today. Let's talk about what actually happens in the scripting engines when you don't have gatekeeper. Wscript.exe is invoked. It then goes out and invokes the scripting engine to run the script. It passes the text to the script to be parsed and then it tells the scripting engine to execute it. While it's executing, the scripting engine will come across a create object of the file system object. That will go instantiate the file system object using common interfaces. Same thing when we do the scripting shell. When we now call open text file, we'll invoke the open text file method of the scripting object or of the file system object. Same thing is true when we go to the reg write command. Now, when we have gate key installed, when the scripting engine is loaded by Wscript, gate key gets installed first. It insinuates itself between Wscript and the scripting engine. It then gets first crack at the source of the script and it checks it to see if it contains the key. It just remembers that fact, yes, I saw the key, no, I didn't see the key, and it doesn't do anything else at this point. And we allow execution to continue. When the scripting engine goes to create the file system object, the operating system is fooled into loading gatekeeper. It then instantiates the real object. It's now, again, sitting between the scripting engine and the file system object. Same thing is true when we go and do the window scripting show. Now, when they do that open text file, we steal that interface. All the interfaces went through scripting and comm must come through a method called invoke. That's where we're sitting. We then go check with gatekeeper. We intercept the call and we go up and check with gate key to see if it saw the key. If it did see the key, everything's fine and we allow the call to go through. We're functionally invisible at this point to running without gatekeeper. Same thing true when you go through the shell object. Now, if you don't have gate key, or we didn't have the key installed, when we check with gatekeeper or gate key to see if it had the key, it's going to come back and say no. Now we block the invoke. So you can instantiate the file system object, you just can't use any of the methods on it. It's worthless. Same thing happens on the other objects that we protect. What this ultimately means is that we're pushing you toward away from scripts, because we think we have a pretty good approach to stopping those, and forcing you back into the Win32 world. Job security for the Sark guys. We have a little demonstration here. I don't know how many of you were exposed to the new love worm that came out about two weeks after Love Letter. It didn't reach wide penetration partially because it was sort of like the Ebola virus. It killed its host before it could replicate. It was very deadly. So what I'm going to do is actually run it on this machine. We say don't try this at home. Okay, now we're running in a virtual NT box. We have the new love worm, assuming it's just come into you as an attachment. So we launched the code. And we don't see anything happening. While this is running. Okay, while this thing is running in the background, we're looking at the WinNT System 32 directory. VBScript isn't the fastest executing code in the world. So it will take a little while, but the effect will be worth it. This is also on top of VM where we obviously didn't want to clobber the machine in... The bits were harmed in the making of this video. No, it's not a service. It has infiltrated the common infrastructure and gets invoked via the normal common methods. Not from within script. As I said, the point of... You would have to be executing 32-bit code in order to get around it. And if you're a 32-bit code, you don't need the scripting interfaces. You have access to the machine. So we're trying to limit the playing field and say, we're going to take VBS and JavaScript away from you. So now you have to write 32-bit code. And by that, making it raising the bar. Those are not accessible from script, except by mechanism. Here we go. Now we're seeing something. There we go. Notice all my files are changing into VBS. And if we change the view here, not only are they now all VBS, they're all zero length. So that VM environment, that machine... The Windows directory? The Windows directory was shot. And it's still off busy doing this to every file on the system. And once it finishes every file on the system, it's going to go to all your network drives and do the same thing. When I said that it killed too quickly, in a lot of cases, it sent itself along through Outlook, but it then deleted Outlook's DLLs before Outlook had a chance to actually send the message. Somebody's got to teach these guys better logic. It has that potential. In the first cut of it, I said no access whatsoever. Now I'm sitting on all the interfaces. I can not only look at the interfaces that you're calling, but I can look at the parameters at which you're calling it with. So I could say, if you want to delete a file in the temporary directory, that's fine. If you want to delete a file in the Windows system directory, that's off limits. But in, you know, development goes through stages. I said, let's start with the most restrictive and thereby easiest for me to write, because as all programmers, I'm inherently lazy. I'll put this very draconian solution in effect and see if anyone squeals. If it works, great. If we get pushback on it, we have the ability to go further down and refine these policies. The same is true of the way that we control the digital signatures. There's more intrusive methods that we could do, but they would introduce levels of complexity into the system. In the current version, a user is empowered to enable his script to run. He can physically add the key necessary to make a script run. No administrator interface is required. We could go to more restrictive models, but then if I'm a script writer in my organization and I want to write a script, I have to now submit it to somebody else to sign it and verify that it's okay before it comes back to me. That's going to be a barrier against deployment in some organizations. We'll do that if that's what they want. Now let's go to a VM running gatekeeper and see what would have happened. And this actually did happen when I received the first sample of NewLove. These VMs were stored in a suspended state, so they take a little while to come back. But not as long as booting in T4. So now we're launching the same NewLove worm. There's a lot of swapping going on here. This machine's got about 192, 256, but there's two VMs running on it. In addition to its native operating system. Okay, we run the worm now. Gatekeeper has intercepted the call. It tells you what program was executing it, what script file kind of got clipped off there was trying to execute it, what method it was trying to call and what object it was using and what method it was trying. Now you'll notice here, gatekeeper is not asking me if I want to allow this. Every user who was affected by NewLove, or by Love Letter, answered yes to the question do you want to run this? It might have a virus. Asking doesn't work. People will say yes, then they're dead. So we don't ask, we tell. Now realistic, when? Right. If they knew that it was good, they could go in and add the signature that allows it to run on that machine and then they can run the script. The end user is empowered to do that. Then they probably shouldn't be running it. Again, as Mark was alluding to earlier, the idea here is to reduce the threat, limit the propagation of malicious code as it's moving rapidly across the network. This is far from being what we would call enterprise ready or carrier class ready. This is very early stage research that we think is pretty interesting in terms of being defensive services that could be deployed. Even if they were deployed today creating a very harsh environment, or in Mark's words draconian, it would still have a very good effect in terms of pushing people away from script writing and into things that are a little bit more sophisticated with Win32 writing. These aren't in the sense of keys. We use the word very loosely. It is just basically a sequence at this point. Again, just to prove for concept, this is research. This isn't commercial product. You mentioned defending against malicious code by policy which allows malicious code that is not just a compile code, but suppose a popular workflow and a function. Then you get a kernel executing allegedly legitimate code. It's like kernel executing at that point. The question was what about a buffer overflow x point where it's not you don't know exactly who is executing the code that's been injected into the system. It would be masquerading as kernel running it. But in that case it wouldn't be kernel executing it. It would be Outlook or Outlook Express or Internet Explorer. If you have a policy in fact that says Internet Explorer is not allowed to go in and modify my Windows system directory it doesn't matter how Internet Explorer was coerced into doing that it would be stopped from doing it. Other questions The question was when I named the product Gatekeeper or the project Gatekeeper did I make allusions to the movie The Net where they actually created viruses in order to get people to install antivirus software which was actually the real virus. No. I just came up with a name. Actually the name is not fixed yet. This is the working title of it. The final name not determined yet. Market texture folks what's it? Not based on Ghostbuster. If you really think about it it's a gate and it's keeping out scripts. It's a fairly simple concept. Again this is an internal code name kind of like Whistler with Microsoft guys and it's not the final name. I work for Symantec. As quickly as I can get it up there. This will be out there and available for download and your comments would be great. RTS format. I can't say that about any other scale. 10 years. It's imported by everything. It's very simple and it works. Why are we continually trying to make a broken system that still work when bottom line nobody uses scripts? Well what you're talking about is Mac does not scripts. Mac does not scripts. Nobody uses it. As any query I'm going to show is actually the same. Say maybe 1% of the actual script usage is not the way that it's happening. A lot of it depends on the organization with which you work. There are corporations that we deal with where scripting is a way of life and disabling it is just simply not an option for them. Let me give you a better example of the type of things that are happening in corporate settings. There is a capability inside Excel to call programs outside of Excel in order to execute programs and bring in their resulting data back into the Excel spreadsheet. You kind of look at that and say that's pretty far-fetched. Most people in fact don't use that function. But if you go into financial organizations they actually have very complicated spreadsheets that take advantage of these invocations to bring things in. So now if you actually think of a spreadsheet as a carrier of malicious code you could actually let's call it ASCII executable stuff sitting in an Excel spreadsheet that you can save and then execute from the same Excel spreadsheet. That Excel spreadsheet can be moved over the web from one point to the next and as soon as it comes on board because of the way the Windows operating system is configured it will automatically associate the XLS object with the Excel application, launch the Excel application in the background because your browser is still the primary and allow this thing to then take off. Now the response on the Microsoft end was what we're going to remove this function. Well that's really going to your concept of let's remove Word document functionality, let's go to RTF. Well the reality is there are corporations that rely on this functionality that can't eliminate it. This is something IT has to improve because honestly what you're ending up with is individual users having to keep building and distributing stuff that they have no idea of what they're doing because they're not qualified to be doing what they're doing and here we are wondering why our levels are improving. Well I mean you can translate that to the entire web infrastructure saying those who are developing web services, forget about documents and Excel spreadsheets, look at the web services that are being developed. They're not always being developed by people with understanding of how programs may affect people downstream. The unintentional use of some software is usually what is exploited. It's not the intentional use, the intentional use is usually well thought out. But it's the unintentional side effects of a program that can be used to buffer overflow concepts and things like that. And so if you look at that really the problem is that we just have a lot of people writing code and that's not going to change. And so you're going to expect various quality in the code that's being pushed to you and therefore you're going to need some type of defensive infrastructure to protect you against anything that may be coming at you. Other questions? We've got some time I think or not. One more question if there's any. I can't hear you. Do you want to repeat the question? What was the extension you put on it? The question was what if somebody makes a batch file that goes in and modifies the registry in such a way to allow the batch file to execute script? Is that what you're getting at? Potentially that's possible. As far as gatekeeper is concerned... This may not sound like a real satisfactory answer to you at this point, but that is not a script based attack at that point. It's a batch attack. We have other technology that we're working on that will address the problems that go beyond script. Part of it also the reason that Love Letter was so successful is that people had never seen a VBS extension. A lot of people have been sensitized about finding X's that they receive. Batch files also to a degree that were recognized as executable, but VBS I've never seen this thing before. Maybe it's a picture. I don't know. I'll open it. Alright. We'll be around the rest of the week. Thanks for your time today and catch up with you later.