On Wed, Oct 16, 2002 at 06:47:39PM -0500, Erik Parker said sometin like... > > Many people have discussed this concept, but nothing has ever taken form. > > > > In order to get a host machine to pull this out of the packet and USE it, > > you'd have to re-write the IP stack for that machine. If you can replace an > > IP stack on a machine, there's no good reason to be doing it in the first > > place, as you've already got root (or some form of escalated privs). > > Well.. That's not really accurate.. A few people have written programs that > let you send data in "Secret".. In Tcp headers, as well as ICMP headers.. and > the router does not toss them out, as long as their put in variable sections. > (and upd headers.. and just about everything else a router will let you send) Not every router will, and it's trivial to add data to a packet header. But the point is, a stack, without an application to decipher the "hidden" data, is a dumb object and won't know what to do. You can't interface with it and say "hey, drop me to a prompt then echo this "xxxx". > In fact, there is a ICMP chat program on freshmeat, that lets you and someone > else chat to each other via icmp packets. And there certainly is a point to > it.. It's easier to bypass a crappy IDS system if you hide your data. Right- and if I'm not mistaken I've seen them for quite a few other services as well. My point being that no out of the box STACK (not program, because that's up to the user) will know what to do with these bits of data. A program can be written to modify the stack in order to shovel anything in field 'x' to a certain location in memory or disk, then have the application check these spots. Again, you need would need to already have some form of access on this box, either with a user account or with elevated privs. > There have been people who were owned, and get shell code sent to > them via little bits of shell code tacked on to the end of email spam > messages, and a service on the remote side intercepting those mails and executing the code > via direction from arp traffic. In a free, open internet without firewalls or filters on routers, I can see this happening... Honestly though, unless it was a completly internal attack, what are the chances this stuff flying across an open network and not getting pulled off the wire (whether intentionally or not)? I think they're pretty slim, not that it can't happen. > The overhead is a lot greater, especially if you throw encryption into it.. > and the methods are slow, but they work.. Also, in the case of ICMP traffic.. > nobody really looks at it too closely for the most part, so it's pretty easy > to stick things in there. A backdoor on a system could easily sit and watch > icmp all day looking for their command packets to come in. Why? This theory is completly legit, you CAN hide data inside unused fields of headers. But why? Every scenario you have suggested leads to "..application running on host machine..." If you've got that, you've got access, or had access at one point. If you have had enough access to install something which will pick up packets (or allow socket access) to the traffic stream before the stack handles it, you had root access. Why are you backtracking and using this method? In my opinion it's not worthwhile to go about controlling a previously owned box by hiding data inside an SONET/Ethernet/IP/TCP/UDP frame or header. If someone has owned a box, there are TONS of other, more productive, quicker, and stealthier ways of remote controlling a box. Like you suggested, you're adding overhead, and causing headaches you don't need. > I'm not sure why you'd need to replace the IP stack on the machine.. you're > not modifying the internet protocol.. just some of the data it carries. s/replace/patch or modfy Regardless, you cannot perform remote command execution on a box by hiding data inside a header because the stack will not recognize it. Any stack. They're all written on the same premise: if I see this, I do this, if I see that, I do something else. If I see "blah blah" - oh no.. .I don't know what to do. I'll just toss it. That's assuming it's gotten past your external router, which should be doing some minimal checking for bad packets as it is... > Lots of ways to hide your traffic.. And technically, you could do it without > actually needing a sniffer running, if you already own the system.. Just > intercept the calls with your own functions.. There are plenty of ways... and this one is a valid one. The point I was expressing is that in order to make this way work, there is a lot of work involved because it's not a 1 or two step process. I cant think of a single example where, from me to you, I can send some form of data to your uncomprimised (by me) box, and if it respond to me. It won't work. And chances are the packet may not even make it- because somewhere along the line someone is going to say "hmmm... that's not a normal option. That ID doesn't match the CRC or other error checking method..." > So, I'd have to say 'completely pointless' is a improper term to use here.. > Because it is in fact, a method that has been used against some of the most > well known 'white hats' out there.. to bypass their IDS systems, and live > silently on their systems. Maybe completly pointless was a harsh phrase... It's fun to think about, and if you come up with something worthwile, please, by all means, let me know. I'd be more than happy to help with POC or anything on making it actually work. > > > >
This archive was generated by hypermail 2b30 : Thu Oct 17 2002 - 06:17:53 PDT