On Monday 08 September 2003 12:44 am, rikona wrote: > Hello Bryan, > > Sunday, September 7, 2003, 6:53:13 PM, you wrote: > > BP> On Sunday 07 September 2003 08:18 pm, rikona wrote: > >> Agreed that there will be intermediate routers. Let's say, for > >> simplicity, there's your comp A, with the virus trying to spoof. > >> This is connected to intermediate router B (directly on the net, > >> NOT within any ISP), which in turn goes to victim computer C. Comp > >> A is sending on spoof IP and listening on spoof IP. > > BP> The problem is that you are connecting to router B with an IP > originating from BP> Net C (target computer). > > Perhaps I'm beginning to see where we are not communicating. Let me > add to the above comp D. Comp D is actually the 'spoof' address, but > in my scenario comp D does not get involved. I'm connecting from A, > trying to look like it's from address D instead, but using the > perfectly legitimate address of comp C (the target computer).
Let me repeat this back to you to make sure that I am getting it correctly. You are suggesting that I connect to my local ISP router (router B) from IP A but spoofing IP D and trying to connect to IP C. So, actual traffic would appear to originate from IP D and be destined for IP C. Somehow, I have managed to compromise router B and convince it that IP A is actually IP D and that traffic to IP C should be sent and returned to IP A as IP D. All of these except C are local so router B is the authoritative source of routing tables. Sound about right? > Router B > gets the packets from "address D" (spoofed) and to address C. Suppose > router B caches the return direction back to A, in preparation for a > reply back to A from C, instead of handing it over to still another > router for the return. This would seem to be more efficient. Assuming that IP A and IP D are both internal addresses for router B, I think that this is very much what would happen. Again, this ignores the possible fallback router to B and any error correction or intrusion detection systems that would pull router B offline and hand off to any other router. This also ignores the possibility of any type of load balancer that would actually swap traffic intermittently between different actual hardware devices seamless to the user. So, for instance, we assume a very small ISP that only operates single instances of network devices. For the record, I am not aware of any production systems set up this way. My own company was using a fairly small setup, maybe 10,000+ users on an intranet system. We had staggered tiers of devices for fallback purposes and we had to compare among them for routing tables to make sure that the tables stayed correct. So, updates get pushed to the main router and separately to the backup router. Comparisons are made between the two to make sure they stay in sync and if there is an anomaly, you either request an immediate update from say, DHCP or DNS, or you have some fallback plan. > > BP> When the request comes in from Computer/Net Range A, spoofing > BP> IP/Net range C, I am going to pass the request to routers on net > BP> range C, > > The link from B to C is legitimate and would be handled as any other > traffic, in my scenario. It looks as though D would have to be in the > range of B to work, though, if I am understanding you correctly. This > might only work by using the return cache of the first router, B. > Anything beyond B is just like normal legitimate traffic. I would say that A and D would have to be local to B in order for this to work. As soon as you start talking any external range to B, routing table updates would be useless since traffic would be passed to another source for actual routing instructions. So, I have managed to completely obfuscate my actual IP address but all traffic is still internal to a local net range. I have, perhaps made it harder to trace the actual source, but since routing tables have to match to MAC addresses at some level, the ISP, who has access to the router and log files, would still be able to figure out who I am provided that they have someone competent tracking it. Assuming that their router was compromised in the first place, this may not be the case. > > BP> Router B does not store routing tables for internal traffic on a > BP> foreign net range. > > Let us suppose address A and D are 'internal' to router B. Would B > cache the (incorrect) route back to A, based on what it receives, or > would it do a lookup? Caching would seem to be more efficient. It would seem that you are speaking here as if each packet request contains routing instructions for the return packet. While it is true that each packet contains a source and destination address, that address takes the form of an IP address, not specific hardware level routing instructions that update the router. That means that routing instructions are actually a separate animal, we would need to spoof the address by tricking DHCP or DNS into triggering an update of the routing tables by assigning a different MAC address to that IP. Then the router gets updated and directs traffic back to us instead of the true owner. This is not contained within the packet itself, but would remain cached until updated or until some process triggers the router to change the table. http://www.onlamp.com/pub/a/bsd/2001/03/14/FreeBSD_Basics.html?page=1 > > BP> I can spoof IP's on my local network all day long, does me no good > BP> if external servers never buy the spoof or send traffic back to > BP> me. > > Let us assume that the spoof address in in our 'local' range. Would > the replies come back to the wrong computer because the router cached > the wrong 'wire'? Yes. Not sure what this buys you except perhaps a little more time. Because all the the traffic is local, the ISP can still find you, they just have to look a little harder. > > BP> I would expect that they stay cached for quite a while, it makes > BP> sense to only update when you receive an authoritative source > BP> update and otherwise, keep the tables the same. > > It was this cache idea that generated the scenario. Depends on what is > cached - the actual return path (incorrect) or a brand new lookup > path. Again, if we are talking about dynamic updates contained within packet requests, this is incorrect. If we are talking about routing table updates generated by some authoritative source, DHCP, etc., caching would appear to be the most sensible feature and still fairly secure. > > >> I was thinking more along the lines of the zombies that the virus > >> writer already has under his control. A good hacker might have 5000 > >> machines to use as he wishes, with the list constantly changing. A > >> single, known open relay will get blocked quickly. > > BP> This does happen and is used for DDOS attacks on sites but I still > BP> don't see what we have been talking about with spoofing IP's > BP> having any bearing on zombie machines. > > It doesn't, directly - it was addressing the side comment of how much > intelligence a virus needed to have, and the issue of using a single > blocked open proxy. Slightly different topic. :-) It would appear to me that the bar has been set quite high. If you stop to think about how much more intelligent we are compared to viruses (biological or otherwise), and the concepts we are discussing are fairly difficult to get even among us (see our own communication difficulties concerning the details), I think that we demonstrate quite clearly how much more difficult it would be to make a virus self-aware of its place and what it has to do to spoof. If you add in that the virus must be efficient and is better able to survive if it is smaller, I think that you demonstrate that any virus this complex would probably not scale for propagation. > > I appreciate your patience in going through this. I might learn more > about network security too. Thanks. Actually, I think that I am learning a bit as well, it has been a while since I have talked about these kinds of things, my Cisco router configuration days are about 6 years old, come to think of it. I specifically wanted to get away from the REALLY techno-geek kind of stuff which is why I went into software QA rather than sticking with network admin and configuration stuff. Actually, it has been so long since I have done any of this stuff, you should probably take everything I say with a grain of salt. Things may have improved drastically since I did any of this. -- Bryan Phinney Software Test Engineer
Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
