 My training squad over here, so they're just going to help me along. Is the audio okay? Louder! Louder! Okay. Louder. Always louder. Okay. In case you didn't know, I'm here to present on this polymorphic shellcode engine that I developed for UNIX systems and stuff like that. It's... I'm K2. There you go. K2 for president! Thanks, Joey. Now, the target here that... The whole point of this system is to allow you to bypass network intrusion detection systems without being detected, basically. Now, most of these systems here, at least for today, they're based on signature analysis, quite similar to a virus scanning technology from years ago. So they rely on hard-coded databases that they query for suspicious patterns. So if they see an IDS vendor will perform an attack, log that attack on the wire and see if they can come up with a mechanism so that they will be able to identify it at any time. Some of the drawbacks of this system is that they require quite frequent updates. As you can imagine, I mean, splice are written every five minutes, right? So, you know, you've got to update these things, keep them current. And that's kind of an ongoing battle. Whenever something comes across bug track, someone's got to go and identify whether or not this vulnerability is actually real and then generate some kind of signature for it. These systems analyze data on the wire in a serial fashion. So, I mean, from beginning to end and try to match it against known systems. Some other probable ways that they could go about it is protocol analysis. Now, you've got your intrusion detection system, and it's going to go, okay, hey, this is my web server. It should only be performing a certain amount of functions, right? So when I see my web server, like connecting back to the client, you know, that might be something suspicious, right, depending on like their particular configuration and whatever, right? So that would be a bad thing. Also, some things on the horizon appear to be statistical analysis intrusion detection systems. Now, these systems are primarily engineered with the assumption that network data over a long period of time is so similar. And what that means is that, you know, a finite sample of like a week-long worth of like traffic patterns can be extrapolated to like, you know, an entire year, and it should be fairly similar. So if these systems get going and you're able to identify good traffic throughout the entire thing or process in the long run, they should be able to identify any statistical anomalies based on that baseline. Now, these things are under development, and I really don't know any IDS vendor that really has something of that kind of quality or what have you. Some of the invasion techniques that are currently employed by people are primarily on the network layer. Now, this would entail stuff like IP fragmentation to confuse the intrusion detection system as to what the traffic is going to end up looking like when it arrives at the destination host. As many hosts reassemble fragments in, you know, various manners, and they might overlap in certain ways. So, you know, some of the ways to defeat these systems in the past has been just to like overlap your packets or send them out of order, do what have you. A lot of these IDSs, some of them don't even look at fragmented packets. So that was always like a really good way to get around them. Excuse me. Probably be something like spoof data, right? Like if I don't want the IDS sensor to know where I'm coming from, you know, that sure does aid. Sure, they might see what I'm doing and pick up the data, but it doesn't really matter if they can't tell where I was coming from. I suppose, right? I mean, that helps out in certain ways. And also, you could spoof the origin from some ignored host, like a DNS server or something like that that might have some special properties within the engine of the IDS, right? So it goes, oh, if there's some traffic from this host, let's just ignore it because it's so chatty. Some other things that we've got here that have been explored quite heavily is on the application layer. And this primarily is in the realm of data obfuscation. And what we're talking about here is, you know, with something like Unicode, there might be like a half billion ways to print the letter A to the screen, right? So if your split depends on the fact that you've got to have an A there and the IDS is just kind of geared towards an ASCII character set, which is kind of like a subset of Unicode anyhow, it might miss some kind of like more advanced encoding mechanisms that you might use. So again, this is another problem of the IDS, right? I mean, they've got to account for, you know, God knows what the end system of the attack is going to do with this data, right? Does it support Unicode? Is this Unicode? Or is it just going to interpret it in a different manner? So I mean, these are really hard things for the IDS to kind of understand. You can use things like alternate character sets or what have you kind of along the same lines as that. And another technique that you could possibly use is data encoding on the application layer. And that's pretty much what this particular utility is all about. We're going to encode the data in a way that every execution of it coming across the screen is going to be unique. So in essence, your splits are always going to be zero-day regardless of signatures, right? Because the signatures are designed to analyze a specific code and, you know, they're only good once they can get it into the database. But if you're able to have new codes every time being generated on the wire, then, I mean, it seems reasonable that they won't be able to detect it. Essentially what this utility is going to do is work with a buffer overflow exploits and it can possibly be adapted to format strings, any kind of shellcode or binary executing stuff that you're going to send across the wire. It should probably be able to help you out with. I assume that most people have a fairly good understanding of buffer overflows and, like, you know, there are, like, weekly talks on this. So, you know, you can just... I hope that you guys have at least read a paper or something. Now, you've got this beast that we all call shellcode, which is essentially the arbitrary commands that we're going to be sending to the target system. So, the shellcode is encoded prior to the launch. Each encoding, therefore, is unique. And, you know, we're able to bypass signatures. The decoder, what we have to do is once we encode the shellcode, obviously it isn't going to function when it lands on the target system, right? So we have to prepend that with a decoder. Now, this decoder itself will process the data after it appears on the target host. So, unfortunately, a lot of splits are written so that when you jump from into the knob section, you know, hopefully they wrote it good enough so that, like, they're jumping fairly close to the beginning of these knobs and not just, like, right, you know, right at the end and they just kind of coded it and it worked and they said, okay, killer, there we go. Because, you know, we're going to eat up a small portion of those available knobs. So your shellcode is effectively, like, you know, increased in size. So, I mean, even if the network intrusion detection system were on the host that was being exploited, it would not be able to detect anything because this is all happening on the application layer. And, again, signature analysis, you know, it should be able to, should be unable to match the shellcode or the decoder or the return addresses that are normally placed at the tail end of your buffer overflow. This is because I incorporated a number of primitives to modulate the return addresses based on your tolerances and stuff like that. The decoder itself, also, is in a polymorphic form. Now, polymorphic is essentially the ability to exist in multiple forms and be functionally identical. So, you know, we'll go into that a bit later on. Oh, by the way, I mean, anybody feel free to pop up and ask some questions. You know, I love interactive crowds. It's extremely polymorphic, you know. Well, currently, I only support one decoder because the encoder is in C and it's in the API and it encodes it and sends it out. And I've just been concentrating on making it cross-platform rather than adding, like, you know, tons and tons of bells and whistles to the decoder right now. So, I'm trying to get it across the platform. Well, you'll see. It had... You're a fucking guy. Actually, I just added... The question was whether or not I have genetic algorithms based to detect, you know, to breed new decoders which are able to survive in the wild. Right? Not currently, you know, this is on the horizon, right? Well, this is just the public version, Joey. Come on. Okay. I think we had an electric... You can configure that to your particular tolerances, right? So, if you've got a split that you've only got, like, you know, 200 bytes worth of knot sled, you can configure the decoder to, you know, fine-tune how it behaves. And, you know, I've had decoders as small as, like, you know, 40 bytes and as large as 400. So, it's fairly... Pretty much up to you. Yes? Oh, really? You made me skip my slide, man. Real men. I don't use knobs. Now, the attack payload of a buffer overflow, just a brief overview, typically consists of these three sections which we've got to, you know, take a look at. We've got this knot sled, which is the initial portion. We've got the shell code in the middle, and we've got these jumps at the back, you know, doing your frame or register overwrites or whatever the hell you're doing that we'll point back into the knobs somehow. Now, these three individual sections or what the IDS is will, you know, be focusing on, you know, one of these three. That was the Canadian beat. Also, format strings again, and we can adapt this for their use later on. Knot substitutions. Currently, the Knot instructions at the beginning of the shell code are substituted. Now, we've got an extensible list of possible replacements that can comply to whatever restrictions that your particular code needs to adhere to. For instance, if you say, I need two upper compliant code, two lower compliant in space, or I've got various banned characters that appear in the generated shell code, this API will automatically generate that for you. So, if you've got, if you don't really have any skills to like write that code yourself and you just want to cut and paste, you know, you can try and see if it can identify a sequence that will generate the code for you. But the more restrictions you place on the encoded shell code, the, you know, obviously, the less permutations you can actually form, right? I mean, I've had, you know, anywhere from three and a half billion possible shell codes or, you know, packets to send to, you know, 50, right? Just because of certain restrictions in the exploit. This note is primarily for Intel, the Intel architecture. Traditionally, guys coding Intel stuff don't really have to worry about the alignment, which is like where you're going to jump into the knobs. So, if you're jumping in there and traditionally it's only a one byte knob instruction, if we enable like multi byte, you know, instructions to be in that section of the shell code, you know, there's the possibility that you're going to jump into the middle of an instruction and not going to be able to execute in the way that you normally would. So, but I mean, I would encourage the use of multi byte knobs because, I mean, this greatly increases the, you know, the amount of codes that will appear within that section. I think I've got about 28 right now. So that's 28 out of a possible 255. So like a little better than 10% of, you know, character space will be available in that knobs section. You know, I've heard from statistics, you know, degree guys that, you know, this really isn't quite what you need to have to be statistically resilient to analysis. So if you enable these multi byte, you know, features that will allow you to have virtually limitless amount of characters appearing within that ops led. Okay, now, Joy. Is there any ideas which is like not plain basic stupid? No, they're all pretty dumb. They don't really have the current ability to analyze the instructions right now and see exactly what they're doing or the data per se that I have seen. Oh, the question was if I have seen any ideas out there which can actually intelligently analyze the data sections of these attacks and actually kind of understand what they're doing, kind of, you know, maybe similar to some virus scanner stuff which can actually analyze the data within like, you know, applications or what have you and identify a polymorphic attack or identify some kind of virus signature. Now, the basic assumption that we've got to make is that there's always more than one way to do it, especially in computer science, right? I mean, you know, how many ways can you like get that X equivalence there, right? You know, there's three right there, there's like at least a several billion more that you can probably do. So, you know, we're going to embed that into our decoder so that it will be, you know, stronger, you know, more able to withstand signature analysis, right? So, I mean, if I needed to calculate Pi or I needed to calculate X there, I could alternatively select, you know, one of these mechanisms, you know, the decoder itself. It isn't just one decoder. It's like a decoder with like a tree kind of system that can alternately select which way it's going, you know, on a random basis. And you can extend that if you feel that you've found another way to like add one to a register, you can just kind of like add that instruction in there and, you know, it can do that. There are also alternate instruction paths so that, you know, if we need to calculate N, we can use, you know, various values that we have also to calculate that. There's a read me with the distribution. If you read the read me, it goes into like a little bit more technical details of exactly what's going on. And of course, you can always just kind of read the source. That'll tell you exactly what's going on. I clicked already, but this thing's kind of lagged out. Non-operational code padding. This is the euphemism that I use to identify this expansion here. You see L plus A plus M equals E. But, I mean, that's functionally equivalent to like L plus like, you know, bracket one plus one minus two plus A, you know, all this other bracket stuff which, you know, nulls out in the end of the equation and you still wind up with E. So, you know, we've got lots of these non-operational padding instructions that'll appear in there. These are the things that you will tune to your likeness. You know, I don't know, on Intel, I've had success with, you know, as much as you want, right? It's your tolerance. The more pads that you incorporate, the more space you've got to take up on the knob sled, right? So, you basically got to tune that feature ahead of time. This is kind of what you were talking about earlier. Also, this padding is randomly generated based on your specifications in the API, right? Like, if you say no, again, the same thing, the two upper, two lower is based kind of stuff or carriage return, whatever. You know, you'll ban this stuff in the beginning and then we'll like add X or X or like jump nowhere to X location. Things like that, you'll be able to automatically generate. Man, it's hot here. Oh, yeah, I've got some new functions in this release. I actually initially released this polymorphic API at the CANSEC conference over in Vancouver. I guess it's like Dursec also, www.dursec.com. You can, right now, the decoder also can appear in like a out of order, you know, function. So let's say there's five operations that you need to have to decode the payload. What you do ahead of time is kind of like set up the structure and define what positions each instruction can enter into. In this case, as you can see, one, two, three, four, five, you know, one, three, two, five, four. So, you know, if you need to, so long as you're not altering the algorithm itself, right, a lot of instructions can appear in virtually any position. I also added a weighted knob slide. So if you have got like a hard on for like, you know, printable ASCII characters in your shellcode, you can like wait those knobs to like a certain level. Hey, hey, quiet, quiet up front here. Yeah, I got a real hard on for printable ASCII shellcode. No, so you can say, I don't know, like if you had, if you were attacking something over like a CGI listening on a web server, right, and you know, HTTP traffic typically has a lot of these angle brackets and stuff like that and whatever else quotes and this double quotes and whatever else, right? HTTP, you know, those characters. You can kind of weight those to whatever values you want. Also, this weighting will increase the variance in the API itself, right? So if you just kind of go in there and randomly weight everything yourself, that'll pretty much mean that yours is a custom copy, right? And the codes that it generates are going to be like more tuned to your preferences rather than the default, default one. So I mean, if anyone, if any IDS vendor actually does create some kind of method to detect this, you should be able to effectively weight everything out and presumably, you know, to your liking, it'll still be functional. But again, here, you know, we, there's occasionally the requirement for certain shellcode restrictions in your attack, right? So you're going to be going along and you find out that your split requires to upper to lower his space or like any special cars banned out of this, right? So you just kind of define that in the, in this structure, you say, like, you flip some bits and you say, you know, hey, I want this code to be to upper resilient or to lower resilient and it'll go ahead and do that for you. If it doesn't, you know, then it'll tell you. Currently, right now, I've got a 32-bit key that I use to encode everything and that's just kind of like applied, you know, against everything one at a time. I don't chain it or anything like that and like, you know, any kind of crazy stuff. I feel that that's enough. It allows you to create a lot of permutations of the shellcode and, I mean, it's really difficult to detect. Again, I've got return address modulation, right? So, I mean, if you feel that, I don't know, I mean, if the IDS vendor has a signature that'll detect against that, you know, you can enable that and that might help out. What I was thinking about, I was, you know, I was thinking about implementing a sliding key. So, you know, as you kind of encode each section, the key changes and the variance gets increasingly, you know, you get a lot more variance in your encoded shellcode. You know, possibly can the sliding key be used to generate normalized shellcode to the protocol which you're attacking? You know, possibly, right? I mean, I'm sure there's a way if you could develop an algorithm that can do that, you know, your decoder might be a little bit bloated or big, you know, I don't really know. I haven't put too much effort into that right now, but there's definitely the possibility in the future, right? No matter what, there's always a way around, you know, any kind of detection mechanism that anybody has. I believe, question back here? Yeah, exactly, right? So, the default weight of the members of the, like, decoder or the knob substitutions, right, is just one. You know, you should just go in there and modify that yourself and have your own custom version. Yeah? Well, you know, that's a possibility, right? You know, it could be a little bit weaker, but I mean, like, if you had a protocol which had, like, a lot of, like, you know, I don't know, X99 bytes in it, you know, you could, like, weight that knob replacement a little bit more and it might be normalized compared to the typical patterns. The current implementation of this API, of this engine, actually, I created an API for exploit developers, which is extremely easy to integrate into any split. I mean, I took the LSD SNMP Solaris RPC vulnerability and I just, like, called my three functions. I mean, you've got to be a little bit intelligent. You need to be able to figure out exactly, like, where the boundaries are in the shellcode itself, right? So, I mean, that isn't really too hard to figure out because, I mean, like, you know, a few lines above that, they're going to be filling all that stuff in for you. So, you know, it's really easy to integrate in source form, at least, into any exploitation scripts that you got, right? And I've also got a filter application for existing exploits. Let's say you're a kiddie, you know, and you don't really know how to program anything at all. You can just pipe the output into this filter and then you're going to have to, you know, select a few options. You're going to have to tell the filter, like, okay, the knob used in this blade is, like, X90. There are, and then you're going to have to tell it the return address, or the return address used in that particular splite. So, it knows when to stop encoding the shellcode. So, with those two things, it kind of knows, okay, this is how many knobs I've got. This is how much shellcode I've got to the boundary of, like, the return addresses and whatever. We currently support IA32 Spark and HPPA. I tried to, I actually limited all of these to, like, the most basic instructions that's possible. So, like, you know, Spark V8 and HPPA risk 1.1. And just so I mean, you're going to have the greatest leverage and, you know, potential to attack target systems. I'm sort of planning to do some MIPS PowerPC and Alpha work. I don't know. It's kind of up in the air right now. I haven't really been doing too much work on this lately, but I mean, if anyone wants to write their own decoder, all you've really got to do is write a decoder, like, you know, some assembly that does an XOR decode. Right? Pretty basic. And that's all you got to do. Countermeasures, that was the last slide. I don't know. There could potentially be some countermeasures for this stuff. I heard some Sourcefire guys or Snort guys talking about some specific demons that they could monitor on the wire, like, to detect all these patterns and what have you. But, I mean, I'll believe it when I see it. Sorry, guys. Yeah, K2.ca. www.KTWO.ca. Apparently, this is an older version of my slide presentation. I knew you used to have that in there. Sorry. This guy over here. This ugly, ugly guy up here. What's my name? What's my name? Self-mutating encryption generators and stuff have been, like, there for a long time. But, for example, like, if you're doing, like, an enterprise-wide scan, an anti-wire scan taking 30 minutes is not a problem, but an IDS is, like, more or less real-time. So, there is a practical inherent limitation in modus operandi when it comes to IDSs and anti-wire software. So, what I'm trying to say is that the techniques you present here would have, actually, a practical limit when it comes to detection in terms of anti-wire or IDS software. So, what do you think about that? Um... Man, I've got some serious power problems over here. Well, I'm sorry. Um, I just need... You can, right? And, I mean, another benefit of... of, uh, Sploits in the Wild using this kind of technology is that you're going to increase the, um, you know, processing power to identify what's going on here, right? And, I mean, I've got things like... Holy Jesus, man. So, um, I mean, I've got things that, like, you know, there's occasionally the need to, like, exploit something, like, you know, hundreds of thousands of times per second or whatever, right? Like, if you need to brute force an offset of, like, a respawning daemon or whatever, right? And you've got only a small window to attack in. Um... I seed the random number generator with, uh, the current time in seconds. And then I add to that the, um... add that, um, the current... your tick register, or the lower 32 bits of your tick register or your CPU. So, I mean, if you've got, you know, I really don't see any way feasible, like, at all that anyone could predict what is going to come down the pipe if you're seeding with your tick register, because, for one, they're not going to know your time. Like, the interval between... at which you're going to re-enter the function and you're going to grab the, uh, the tick register is always going to be slightly different on a multi-tasking operating system, right? So, I mean, at one time, it might have taken, like, 500,000 cycles. At another time, it took, like, you know, 500,000 and one cycles, and that's just enough to, like, generate something different. Joey? Yeah, I mean, I think, like, my company antivirus and anti-doctrination and antivirus has actually addressed these issues in terms of antivirus in the past, but in the future. Don't you see, like, there's a fundamental challenge you have answered here? When it comes to real-time, you can't do this shit anymore because there's so much processing power involved. So, in other words, you're like, you know, like, strike one for, like, ideas of when... Yeah, definitely. I mean, the amount of processing power that's required to identify... Joey was alluding to the fact that this is a paradigm shift in exploit development, right? And if currently everybody's relying on these really stupid, stupid exploits that go out, right? Like, stupid viruses that, like, you know, infect your boot sector, and that's it, you know? Sit there, memory resident. But as soon as polymorphism came along, it's kind of, like, enabled the viruses to have this endless cat and mouse game, you know, going around in circles forever, and, you know, that's still going on today. So, I mean, theoretically, this can go on for a longer period of time, and, you know, the amount of processing time that you're going to have to do to analyze the data that, as it comes across a wire, especially with high-speed, like, what, like gigabit? Like, ideas can just barely handle gigabit right now, so, I mean, I really can't see them and doing virtually any processing on the data. I know. Hey, box, we'll detect it right now. Remember to tune your values, so, you know, you all have your custom copy. It's in this structure, it's the last member, it's the last integer in the decoder structure, in the junk structure. Just as a hint. I've got a demonstration here that I intend to show. It might have some surprising results. I've got real secure, a little secure, analyze this. You're really secure from now on. Here, we've got the real secure console. Speakers come up here and beat me if you really want to talk, because I don't know how I'm doing for time. 20 minutes? Okay, I'm just going to grandstand for 20 minutes, if I can. Okay, I'll just be a second. I'm going to set this up here. Essentially, what I'm going to go over here is a couple of things from this Linux box to this Linux box. In this stupid hub down here, they're all kind of connected with this real secure box over here. Stupid. Stupid. Okay, let's see here. Okay. What I'm doing here is I'm going to imitate the IMAP protocol and, you know, some kind of integer login space. Login data. Quotes. There's some quotes around that login data. And then you say pass. This is what, you know, a typical IMAPs plate would look like. And I'm sure we've all seen those before. So I'm going to attack my box over here with my vulnerable IMAP. And we'll see what over here, what real secure does about it. Oh, whoops. This here's the new version. Real secure. Did its job and secured us. Thank you, real secure. It is a, this product does actually work, you know. Suspicious TCP packet from the address here. Essentially what I'm going to do is go through here, here's it. Let me give you a little background on why I'm, you know, going up against real secure here. Initially after the CANSEC conference or DRSEC, like www.drsec.com I, I, everyone started chatting about this a little bit, right? And they're like, hey, you know, blah, blah, blah. ISS released this big advisory saying, hey, we're not vulnerable. This doesn't work. I responded back and I said, hey, yes, you are. Could you please send me, this is my quote up here. I had asked for some technical details, TCP logs, et cetera, of an attack that was detected, but none could be provided. I have put it through some testing and I have found that it's most definitely vulnerable to these techniques. Okay. These are kind of taken out of context and responded back to this ISS.net mailing list here by, let's see here, Tim Farley at ISS. Thank you, Tim. He took me out of context here. Later on here he's going, oh, this guy, me, admits he doesn't know what real secure is supposed to detect in the first place, hence the request for the TCP logs. No, Tim. I have logged so that I can verify what the hell is going on and verify that you guys actually did some work, but none could be provided and that's what I meant that, he concludes that because it didn't detect something he threw in front of it, it must be vulnerable. No, no, no. Well, yeah, man. He goes on here to, this product does detect a lot of stuff. I don't want to give him too bad of a name here, but it does detect buffer overflows just like he's saying. It has a generic buffer overflow signature which attempts to identify hex 90 in your data. But as we saw just now over here, it actually has a specific IMAP signature. It's not the generic Intel signature. I can show you that in a minute. Real secure is not designed to attack to detect attacks by recognizing the shell code. Okay, Tim. Well, anyhow, he goes on, I conclude that you use something that we don't have an XPU for, I don't know what XPU means, but apparently it's something. Okay, two days later, by the way, this is all going on in a mailing list that I'm not a member of and I didn't find this out until months later, so I didn't have a chance to respond to any of this. But luckily, I was doing a Google search of my name and Newtate, so I was like, yeah, yeah, let's see how popular I am. And I was like, yeah, yeah, yeah. No, but someone CC'd me this. I disagree, you've left out these key steps, right? This is from Tim again. Tim Farley, ISS Atlanta, T Farley at ISS Atlanta. Tim Farley, ISS Atlanta, T Farley at ISS.net. Apparently, his phone numbers have changed, so no, actually, I've actually heard also that Tim is no longer with ISS after, and this is just like two months old, so apparently, I don't know, there might have been a little abrasion there because he's really abrasive towards me. So he left, he concludes that I left out some key steps that I don't understand the scientific method, apparently, right? So attempt an unmodified attack right here with the IMAP overflow. Verify the IDS response to it. Okay. Suspicious, yeah, I'm out. Okay. Attempt the modified version of it. Okay, okay, okay. Thanks, man. He just worked himself right into this. Okay. What I'm doing here, I'm doing the same thing I did before. You can't see that? I'll get a second version up there for you guys. There you go. As you can see, M7, like my favorite song, anybody know what M7? Magnificent 7. Apparently, what you do with it, this is the filter application, so it's going to take that same EXP that was run up there for, short for exploit. M7, I'll give you the help for that. You've got these four options here. ISM or H, short for Intel, Spark, MIPS or HP. MIPS doesn't even exist in this code. I'll just put it there for fun. I had the intention of coding that at the time when I wrote this. Now, and then what you do, you select your architecture here. As you can see there, I did dash I. This is the Intel overflow. And then you do dash O, the offset. So you tell the filter when the offset values are going to, so it knows when to stop encoding, because you don't want to encode those. Dash and Knop, you've got to tell it what particular Knop you used. I know everyone uses 90, which is the official Knop, but there is the possibility that someone used something like the capital A, like cheese does all the time. And then you do dash X exploit, or you could run the exploit pipe if you wanted to, because it accepts standard input. If you don't do that, I just did that for fun. And then in some other things here, dash U, dash L, upper lower code, dash B, give it a string that's your string of band characters, dash C, that'll output a C style array that you can just kind of embed in some other code, or you can take and analyze somewhere else. Dash T will truncate the exploit attempt, because we know everybody's so damned lazy that they don't actually know how big the buffer was supposed to be, and they just kind of ram a bunch of stuff down its throat. So you can 9 times out of 10 truncate this thing by 1 or 100 bytes, and it'll still function. Dash P is to pad the encode decode length. What this is, say I generated a decoder, but the jump offset was a band character, you might have to tell this filter application to add some more bytes in there in the decoder so that you're not landing in a band character, like a two upper two lower space character. Dash U is an attempt to modulate the offset back into the knob slide. This can be dangerous, because your exploit might not work, because, you know, you could jump out of range. So, we're going to go through here and run this new exploit. So, oh, this guy is not a marketing person, neither is Chris Rowland for that matter. Chris Rowland actually made the initial response that ISS isn't vulnerable, and he is an engineer, apparently, and he has written many of the signatures in real secure, so apparently he's really in the no guy. Oh, it's a two-way street. Well, by the way, I actually did send this code to ISS ahead of time before the public release, and they had a chance to analyze it and everything, right? So, I kind of see that as a two-way street, and they didn't provide me with their logs, which I would have seen as a two-way street, so I see some friction there. You know? Yeah, I don't want to slam them, man, but you didn't have to flame me without see seeing me on the bloody mail, you know? I mean, I didn't even know this was going on, and it was named, so here you go. So, let's do this. I map overflow and see what real secure has to say about it. Sensor error. I didn't know this was going to happen. I'm sorry. No, I'm kidding. Apparently, we just generated an exception fault. An exception encountered in function X1004E 360 in packet hash table, packet proto TCP, packet TCP UDP hash, 000143. So, apparently, I don't know. Let me think about this. Oh, okay. This appears to be, I don't know, man. I think, for some reason, real secure is attempting to diagnose the essence of the protocol here and figure out what all this means to it. No, I feel great that, like, my packets mean a lot more to it than the I map did, and it's thinking a lot harder about what to do, and it kind of, it just couldn't handle that, and it caused an exception. So, okay, let's see. I know I was thinking about that, dude. Oh, I flashed myself. So, we'll do it again. Another sensor error. So, this is a reproducible error. It looks like, well, well, I mean, I think this might be exploitable. You know, it just seems to me, yeah, my laptop thinks so, too. There you go. I think that he's thinking a lot. You know, so, this, you know, that address we saw here, what was that again? Let's get the new one. Okay. Similar kind of thing, hash table, blah, blah, blah, blah, exception, encounter, calling this function that it can't resolve the name of that, so I'm assuming that it's overwriting some kind of function pointer, something like that. So, you know, if we could take, if we could make some intelligent use of that, instead of just kind of random, this is designed to be random, and I mean, if we made some intelligent use of what that randomness was coming over here, you know, we could direct the instruction flow of real secure. Possibly. I'll set up another demo here. Just take a second. I flashed my under. Let's do it on another port. Explain this in a moment here. I'm going to send it to port 110. Okay. Tim, Tim, send an unmodified version. Hold on a second. I just put that up there for the guys in the back. Come on. Give me a break. So here's the unmodified split. Hold on a second. Real secure. I'm sorry. Let's try that again. Let me start real secure, you think? I tried it before and it didn't have to be restarted. I think the deal that this is crashing in is like, you know, it's shit's resolved when it's processing and it's able to handle it. Let me just try one more time. Let me get rid of this quote here. By the way, if you're making a pop three split, apparently put a quote there, No, I don't know. Do you think I can just stop it from the console or do you have to reboot or something stupid like that? Okay, okay. Let's try that. Stop. Sorry for this lag, everybody, but you know, it says NT I'm dealing with here. Bless you. I thought this was NT four for a second. There we go. Okay. Okay, we restarted that. Okay. What the hassle this would be if you're like running a live real secure. Okay. Let's see. Connecting active. So, I mean, you can all see what this does. User exploit code going to port 110 of the vulnerable system that we saw events happening before. So, bless you. Oh, it quits on. Oh, I know what it might be. Here. I think we might need a space in there. Actually, catch this before. Let me try a different port. We'll try the FTP port. Apparently, real secure is having a hard time. And we'll just let it have that hard time on a four meter wide screen. As you can see, I would have demoed, if it would have detected something, I would have known how it would have not detected something following that. But, yeah, I'm having some problems. I could do it. I could like, here, what I can do, I'll do the IMAP one again just so you can see all of you guys here can see that the scanner is actually functional. Okay, so, you know, I don't know why those other ones weren't being seen whatsoever, but who knows. Let me do them a favor. Let me check my policy and make sure that I've got all the policies going on here. I'll just do this in front of everybody so there's no question in anybody's mind what they're doing. This is version six, by the way. So it just came out the other day. Seriously, I was trying to run my demo and then they released a new version on me and I was like, oh no. Okay. It's like, why the sensor? No, it's not letting me click apply the sensor. Does anyone know how to use real secure? Okay, this thing could just be foobar. I mean, we could have just crashed enough stuff so that it just can't handle what's going on anymore. I don't know, right? I mean, I'm trying to apply this stuff. Any other questions as to how this is going to function or anything like that? Okay. Oh, yep. Good question. In terms of the decoder section itself, he asked how much randomness do I expect to have out of the decoder? Well, here, if you see right here, when I ran this code just now, it deduced that this here is the original payload and all of those blocks there are hex 90. Over here, we've got the fabled NSH, so anyone can see that. It figured out, okay, I've got this much to encode, blah, blah, blah, blah. Almost nearly 3 billion, so nearly 3 billion possible outcomes. So that's 3 billion parts of, you know, 3 billion shellcode permutations at least. Here's the encoded shellcode. Oh, man. This monitor isn't working in front of me, so I've got to go off the big one here. But here's the key we used, A2, blah, blah, blah, blah. And here's the encoded shellcode here, 54 bytes long. The order of everything went 0, 1, 2, 3, 4, 5, 6. Oh, 6, 8, 9, 10, 11, 12. I guess I can't see where 7 went either. As you can see, yeah, it's off to the side. As you can see, it's out of order. If I were to do this again, it could be in a different order. And the hard-coded value that I used is, I hard-coded a 42, a D, and this and that. You see that the D there is a character that you might have had to use that P option to pad all this out with. Here is the decoder engine itself, 73 bytes long. And here is the actual polymorphic shellcode. So this down here has this up here prepended to the front of the stuff. So let's run another one really quick. And we'll see that the last one was 73, this one is 66. So I mean, that's a fair difference. And the order here is 0, 1. Yeah, the other one went, if I look up here, it went 0, 1, 2, 3. Yeah, I don't know. I mean, real secure didn't cash it or something. But 0, 1, 3, 2. So now you see that 3 and the 2 are out of order. 4, 5, 7, 8. And the 7, 8 are in order. And the 6 is out of order, all this stuff. So you can see it's kind of out of order. The hard-codes are all different. The length of this stuff is all different. You can go in here. Yeah, question? I'm using a simple x-word with the key. What was that again? Yeah. Why is that? There's an even number of... It's image you are seeing where you generate a lot of multiple encryption generated and a lot of garbage instructions. Okay, I see where you're coming from. But you can... Every 4x block. Every 4x block, yeah. Yeah, it's the same key, actually. Yeah, I'm thinking about using a sliding key. I mean, that's kind of the reason for that. I mean, this is just to evade current and network encryption deductions. So I mean, in the future, if anyone does detect it by a mechanism like that, I mean, we can go ahead and add a couple extra instructions. The problem is, is I really didn't want to take up too much of the knob sled. Right? And I mean, any... Every additional instruction I use potentially is like in another few bytes of space, right? And I mean, this space is at a little bit more of a premium than it is even in the virus-coder world, right? I mean, because like, you know, one byte could mean the difference of getting root and not getting root. So I mean, I just don't want to make it too overly complex to start to begin with, right? So I guess they could do that. Give it a shot. See how it goes. See, right here, we say the maximum amount of non-operational instructions. By default, I use a 4. For Intel, Cisco, CPUs, I found that 3 to 10 works really good. But for risks, you should probably try and keep it to 2 to 4 because in the risk systems, it's always a 32-bit value. So I mean, that's 4 bytes at a time. Down here. Here is the... This function itself is... This here are the knob replacements. So basically, this is a regular knob. This is a multi-byte knob that you can replace it with. This is a single-byte one. These values here are all defined in the other header file. You can look them up and figure out what it means. But this last value here is the weight. So this one is like a 2. And what? This might be an old version. Anyhow, this is the weight here. Oh. Or this is the weight. I don't know. Whatever. Look at the other header file and it defines what everything is. And you can figure out what all those integers mean. And you can just go in there and tweak these values to your liking. Any other questions? You want to compare them and see if they're identical? You would prefer that they're different? Yeah, but there are some sections of this code that are static. So, I mean, they are... Okay, 1,004, E, 6, 0. 1,004. 1,004, E, 3, 6, 0. Yeah, it looks like it's the same. Okay, well, yeah, I mean, that could be right, right? But I mean, there's a lot of static data also. And I mean, it could be reading the offset section, which is the same every time. Or it could be... I don't know what it's doing, right? I mean, I haven't fully debugged it, but apparently we're smashing something. Right? And if we're smashing something, then that usually isn't the best thing to have go on. Especially in the IES, yeah. As you said, duly noted. Any other questions? Question? Yes? Question was, you know, hey, are we going to have lots of stuff that will generate a split and exploit the target system and the IDS simultaneously? You know, hey, that's definitely a way we might want to move. Re-code any binary app? I don't know, man. I don't think too hard. I mean, everything's pretty modular and tight, you know? Anyone fairly familiar with C should be able to, like, you know, do whatever they want with the code. I like to think that it isn't too sloppily written. You know, there's a couple of global variables that, like, my teacher, my profs at some school will get pissed at me about, but I kind of need those. I like globals. Anybody else? Yeah, I'm just wrapped up. I'm just doing Q&A. Okay, yep. Pardon me? K2.ca slash security.html. Anybody else? $5, all right. Go on once, go on twice. Okay, thank you.