230 likes | 250 Views
Tactics to Discover “Passive” Monitoring Devices. Mudge@atstake.com. The Problem at Hand. Local ether segments behave like party-line phone systems. Without encryption there are no secrets. A. C. E. G. B. D. F. H. A-B : CDEFGH can listen in A-H : BCDEFG can listen in Etc. etc.
E N D
Tactics to Discover “Passive”Monitoring Devices Mudge@atstake.com
The Problem at Hand Local ether segments behave like party-line phone systems Without encryption there are no secrets A C E G B D F H A-B : CDEFGH can listen in A-H : BCDEFG can listen in Etc. etc.
Ether header payload Ether header payload Read a packet from the network Is the dest ether header my MAC address? Make a copy of the packet and hand it to the OS stack How Systems Know What to Listen To … Systems are courteous largely for performance. Hardware filtering at the NIC hands up only the packets the system is supposed to receive. Promiscuous mode tells the NIC that all packets should be handed to the OS stack. Not just the ones with the matching MAC destination address. Network Interface Card decision flow no yes
Source Address type Application Transport Network Link Ether and IP Headers 6 bytes 6 bytes 2 bytes Ether Destination Address 4 4 8 16 IP vers len TOS Total length (bytes) 16 3 13 Telnet, SMTP, etc identification flags fragment offset TCP, UDP 8 8 16 IP, ICMP TTL protocol checksum 32 Device Driver, Interface card Source IP Address 4 layers of TCP/IP protocol suite 32 Destination IP Address
The Disconnect Application Presentation Session Transport Network Data Physical
DNS MethodDefinition • The Domain Naming System maps IP addresses to names and vice-versa. • DNS allows hierarchical grouping of domain • DNS is a necessity for human convenience Q: Who is foo.bar.baz? A: foo.bar.baz is 10.10.12.132 (follow up by initiating TCP connection to port 23) % telnet foo.bar.baz Trying 10.10.12.132 … Connected to foo.bar.baz.
Who is 10.0.0.5? Sniffer 192.168.1.10 10.0.0.6 10.0.0.5 Src 10.0.0.5 -> Dst 10.0.0.6 Bogus System 1 Bogus System 2 DNS Method 1Sniffing the Sniffer • Spoofed packets are sent out on the local network • The network is sniffed looking for reverse DNS lookups on spoofed packet • Any systems asking about the fictitious systems is in promiscuous mode
Net 10 DNS Server Sniffer router 192.168.1.10 Whois 10.0.0.5? Net 192.168.1 10.0.0.6 10.0.0.5 Src 10.0.0.5 -> Dst 10.0.0.6 Bogus System 1 Bogus System 2 DNS Method 2Queries to DNS Server • The DNS server is under our control • Spoofed packets with addresses handled by the DNS server are sent out on the local network • Any requests that the DNS server receives for the spoofed machines are from machines in promiscuous mode
DNS MethodPros and Cons Pros Cons • Can work across multiple networks • Names of machines are very telling and as such, many malicious sniffers will do the reverse lookups • Does not saturate the local network • High reliability – minimal false positives • Sniffing systems do not have to perform reverse lookups • Sniffing systems can do batch reverse lookups later on – this defeats method 1 but not method 2
192.168.1.10 192.168.1.10 08:00:20:10:22:e0 66:66:66:66:66:66 Ether TricksDefinition Ether tricks work by intentionally mis-mapping layer 2 and layer 3 addresses !=
Ether Tricks 1Linux Classic When in promiscuous mode the NIC does not filter the ether address. The kernel must filter the ether address on its own. Normal behavior for non-promiscuous mode ICMP – Echo Request Correct ether address Correct IP address ICMP – Echo Reply
Ether Tricks 1linux (cont) Normal behavior for non-promiscuous mode ICMP – Echo Request In-correct ether address Correct IP address No response as NIC did not pass the packet to the stack
Ether Tricks 1linux (cont) Older linux behavior for promiscuous mode ICMP – Echo Request In-correct ether address Correct IP address ICMP – Echo Reply NIC had to pass all traffic to OS. OS forgot to check the MAC address and only looked at IP
Ether Tricks 2BSD Style Problems Older BSD behavior for promiscuous mode ICMP – Echo Request In-correct ether address Broadcast IP address ICMP – Echo Reply NIC had to pass all traffic to OS. OS forgot to check the MAC address and only looked at IP (took a different path for broadcast)
Ether Tricks 3Microsoft Shortcut 6 bytes Ether Address What the NIC filters on 4 bytes Word What many MS software drivers check when in promisc ff:ff:ff:ff:00:00|IP|ICMP echo request Equivalent to be ff:ff:ff:ff:ff:ff on many promisc NT systems
Ether TricksPros and Cons Cons Pros • High reliability, low false positives • Limited to local ether segment • Dependent upon particular OS/Kernel “nuances”
Machine Latencydefined Hardware filtering • Discards packets not addressed to correct MAC address • Handled by on-card logic • Minimal impact on system performance as few interrupts • Kernel not called in to process unless really needed • Match criteria == MAC, broadcast, multicast Software filtering • All packets must be copied and handed over to OS • On-card logic bypassed • Severe impact on system performance due to maximum interrupts • Kernel must process packets • Malicious sniffing often happens in user space – context shift from Kernel to User space is expensive
Machine Latencyexample A C B A – ether: 08:00:20:ac:1e:e2 IP: 192.168.1.10 B – ether: 08:00:20:ac:22:16 IP: 192.168.1.12 C – ether: 08:00:20:ac:23:e4 IP: 192.168.1.14
Machine Latencyexample 1 – ICMP Echo Request Ether Src: 08:00:20:ac:1e:e2 Ether Dst: 08:00:20:ac:23:e4 IP Source: 192.168.1.10 IP Dest: 192.168.1.14 Latency == 2 ms 1 A C 2 B 2 – ICMP Echo Request Ether Src: 08:00:20:ac:1e:e2 Ether Dst: 08:00:20:ac:22:16 IP Source: 192.168.1.10 IP Dest: 192.168.1.12 Latency == 3 ms A – ether: 08:00:20:ac:1e:e2 IP: 192.168.1.10 B – ether: 08:00:20:ac:22:16 IP: 192.168.1.12 C – ether: 08:00:20:ac:23:e4 IP: 192.168.1.14
Machine Latencyexample 1 – ICMP Echo Request Ether Src: 08:00:20:ac:1e:e2 Ether Dst: 08:00:20:ac:23:e4 IP Source: 192.168.1.10 IP Dest: 192.168.1.14 Latency == 4 ms 1 A C 2 3 2 – ICMP Echo Request Ether Src: 08:00:20:ac:1e:e2 Ether Dst: 08:00:20:ac:22:16 IP Source: 192.168.1.10 IP Dest: 192.168.1.12 Latency == 300 ms 3 – ICMP Echo Request Ether Src: 66:66:66:66:66:67 Ether Dst: 66:66:66:66:66:66 IP Source: 192.168.1.30 IP Dest: 192.168.1.33 B A – ether: 08:00:20:ac:1e:e2 IP: 192.168.1.10 B – ether: 08:00:20:ac:22:16 IP: 192.168.1.12 C – ether: 08:00:20:ac:23:e4 IP: 192.168.1.14
Machine LatencyMethods for increasing end-node processing • Fake entire three way handshake • Fake connections to well known sniffed ports • Use “legitimate” ether addresses that still have no physical presence • Fake huge numbers of sessions • Fake huge numbers of SYN recv’d states The trick is to make the sniffing application process as much as possible in user space
Machine LatencyPros and Cons Pros • Cross platform • Often times crashes sniffing programs • Confined to local segment • High accuracy in watching deltas for a particular machine over time Cons • Limited to local ether segment • Assumptions must be made about systems response under load • Network and regular machine load assumptions must be made • Network congestion
Spotting the curious • Create fictitious connections to a real machine • Use a ‘trap’ account • Watch and log on the legitimate machine for anyone attempting to log on with the ‘trap’ account