Applied Black Op Networking on Windows XP Dan Kaminsky, CISSP Dox. Para Research http: //www. doxpara. com
Overview n Paketto Keiretsu n n n The “Packet System” A suite of only slightly interrelated network tools that nonetheless manage to work together in peculiar ways 1. 0 Unveiled: October 2002, Black Hat Asia 2. 0 Unveiled: February 2003, Black Hat Windows What’s New? n n Welcome to Black Hat Windows Libpaketto SSL vs. IDS Much, much more
Scanrand n High Speed TCP Scanner and Network Tracer n Most well known statistic: n 65, 536 Addresses Scanned on 80/tcp n 8, 000 Replies Received n Time Elapsed: n 4 Seconds Experiment in Secure Stateless Manipulation of Stateful Networks n Performance wasn’t actually the goal
Secure Stateless Operation n “Find a Mirror. Recognize Yourself. ” n Find components of your outgoing messages that by nature of the protocol being used, will be reflected back to you. Embed a signature that only you could generate, irrevocably linked to the security-sensitive information you are being provided. n HTTP Cookies n Drivers Licenses
TCP Reflectors n n Scans begin with a TCP SYN Components of reply known and controlled by sender: n n n Source IP and Destination IP Source Port and Destination Port Initial Sequence Number (SEQ#) Source IP, Destination IP, and Destination Port are fixed Leaves Source Port and SEQ# n 48 bits worth of reflected capacity
Scanrand’s Reflectors n 1. x: Inverse SYN Cookies in the SEQ# n HMAC-SHA 1 truncated to 32 bits in the outgoing SEQ n n n Valid reponses – SYN|ACK (Up) or RST|ACK (Down) – return the SEQ# in the ACK# We HMAC all that we know the legitimate party must reflect – including the IP’s and Ports we couldn’t meaningfully munge Coming in 2. x: Timestamps in the Port # n 1. x uses absolute latency from beginning scan – limitation! n n n Bandwidth limitation, strange modes of packet handling Firewalls have trouble with multiple connections from the same port to the same host/port We can tap that – 16 bits provides 65 K “timeslots” n 1 ms resolution gives us 65 s window n Stamp authenticated by seed
Basic Features Port and Range Parsing: 1. 2. 3 -4. 5 -6, 8 -50: 22, 80 n Traceroute n Port Aliases: quick, squick, known n Bandwidth Limitation n Read Targets From A File n New in 2. x n Single-Threaded Mode w/ SR_NONBLOCK n API – everything trivially embeddable n
Basic Demo 1: Scan n n n # Quick scan of local network bash-2. 05 a# scanrand 10. 0. 1. 1 -254: quick UP: 10. 0. 1. 38: 80 [01] 0. 003 s UP: 10. 0. 1. 110: 443 [01] 0. 017 s UP: 10. 0. 1. 254: 443 [01] 0. 021 s UP: 10. 0. 1. 57: 445 [01] 0. 024 s UP: 10. 0. 1. 59: 445 [01] 0. 024 s UP: 10. 0. 1. 38: 22 [01] 0. 047 s UP: 10. 0. 1. 110: 22 [01] 0. 058 s UP: 10. 0. 1. 110: 23 [01] 0. 058 s UP: 10. 0. 1. 254: 22 [01] 0. 077 s UP: 10. 0. 1. 254: 23 [01] 0. 077 s UP: 10. 0. 1. 25: 135 [01] 0. 088 s
Basic Demo 2: Traceroute n n n n bash-2. 05 a# scanrand -b 2 m -l 1 -13 www. slashdot. org 002 = 63. 251. 53. 219|80 [02] 0. 018 s( 001 = 64. 81. 64. 1|80 [01] 0. 031 s( 003 = 63. 251. 63. 79|80 [03] 0. 044 s( 004 = 63. 211. 143. 17|80 [04] 0. 066 s( 005 = 209. 244. 193|80 [05] 0. 084 s( 006 = 208. 172. 147. 201|80 [08] 0. 099 s( 007 = 208. 172. 146. 104|80 [06] 0. 119 s( 008 = 208. 172. 156. 157|80 [08] 0. 140 s( 009 = 208. 172. 156. 198|80 [08] 0. 167 s( 010 = 66. 35. 194. 196|80 [09] 0. 187 s( 011 = 66. 35. 194. 58|80 [09] 0. 208 s( 012 = 66. 35. 212. 174|80 [10] 0. 229 s( UP: 66. 35. 250. 150: 80 [12] 0. 241 s 10. 0. 1. 11 10. 0. 1. 11 -> -> -> 66. 35. 250. 150 66. 35. 250. 150 ) ) )
Hopcount Desync n n n n root@arachnadox: ~# scanrand -b 1 k -e local. doxpara. com: 80, 21, 443, 465, 139, 8000, 31337 UP: 64. 81. 64. 164: 80 [11] 0. 477 s DOWN: 64. 81. 64. 164: 21 [12] 0. 478 s UP: 64. 81. 64. 164: 443 [11] 0. 478 s DOWN: 64. 81. 64. 164: 465 [12] 0. 478 s DOWN: 64. 81. 64. 164: 139 [22] 0. 488 s DOWN: 64. 81. 64. 164: 8000 [22] 0. 570 s DOWN: 64. 81. 64. 164: 31337 [22] 0. 636 s What’s going on: The host is genuinely 11 or 12 hops away. All of the up ports reflect that, but only a few of the downed ports. The rest are showing double the remote distance. This is due to the a PIX firewall interspersed between myself and the target. It’s (too) quickly reflecting the SYN I sent to it right back to me as a RST|ACK, without resetting values like the TTL. Thus, the same source value decrements twice across the network – 22 = 11*2 – and we can detect the filter.
ACK/RST Analysis n n n n n root@arachnadox: ~/talk# scanrand -D -vv www. cisco. com: 80 root@arachnadox: ~/talk# www. cisco. com: 80 Stat|=====IP_Address==|Port=|Hops|==Time==|=======Details======| SENT: 198. 133. 219. 25: 80 [00] 0. 000 s Sent 40 on eth 0: IP: i=192. 168. 11. 29 ->198. 133. 219. 25 v=4 hl=5 s=0 id=216 o=64 ttl=216 pay=20 ttl=216 TCP: p=8621 ->80, s/a=2785760401 -> 2785760401 o=5 f=16 w=4096 u=0 optl=0 Got 60 on eth 0: IP: i=198. 133. 219. 25 ->192. 168. 11. 29 v=4 hl=5 s=0 id=216 o=0 ttl=189 pay=20 ttl=189 TCP: p=80 ->8621, s/a=2785760401 -> 2785760401 o=5 f=4 w=4096 u=0 optl=0 DSCO: 198. 133. 219. 25: 80 [14] 0. 204 s What’s going on: This time, we’re intentionally sending a completely bogus packet – an ACK utterly disassociated from any known stream. (Since it’s disassociated, nothing prevents us from using an Inverse SYN Cookie. ) Standard operating procedure is to respond with a RST, since it’s usually from some rather broken remote host. But notice – the incoming RST has a TTL of 189. The TTL range from around 129 to 216 rarely sees legitimate traffic – programmers usually start from powers of two. We, however, didn’t. Also note the duplicated IPID.
Expected Behavior n TCP Repairs Broken Connections n n If a packet is dropped, it will retry “Hello? … Hellllo? … … … Hello? ” <CLICK> n n n Discovered by Franck Veysset et al. n n How many Hellos? How long inbetween them? It varies from person to person, and from TCP/IP stack to TCP/IP stack RING is their tool Can we do this with Scanrand? n n Scanrand uses the kernel to RST incoming replies, so they stop coming Usually this is good – cut off the flood Well now we want the flood…but we don’t want to interface with some firewall rules. Solution: Use a different IP. But have the kernel serve the MAC!
Temporal Fingerprinting Demo n root@bsd: ~# arp -s 10. 0. 1. 190 00: e 0: 18: 02: 91: 9 f pub root@bsd: ~# n root@bsd: ~# arp -an | grep 10. 0. 1. 190 root@bsd: ~# ? (10. 0. 1. 190) at 0: e 0: 18: 2: 91: 9 f permanent published [ ethernet] root@bsd: ~# scanrand -i 10. 0. 1. 190 -t 0 -b 100 k 10. 0. 1. 1 -254: 139 root@bsd: ~# (OUTPUT SORTED) UP: 10. 0. 1. 12: 139 [01] 0. 235 s UP: 10. 0. 1. 12: 139 [01] 3. 191 s UP: 10. 0. 1. 12: 139 [01] 9. 109 s (+3+6) UP: 10. 0. 1. 36: 139 [01] 0. 715 s UP: 10. 0. 1. 36: 139 [01] 3. 624 s UP: 10. 0. 1. 36: 139 [01] 9. 639 s (+3+6) UP: 10. 0. 1. 38: 139 [01] 0. 755 s UP: 10. 0. 1. 38: 139 [01] 4. 560 s UP: 10. 0. 1. 38: 139 [01] 10. 560 s UP: 10. 0. 1. 38: 139 [01] 22. 758 s UP: 10. 0. 1. 38: 139 [01] 46. 756 s (+4+6+12+24) n n n n n
What About Traceroute? n Traceroute’s as stateless and fast as port scanning n Traceroute provides active route metrics by issuing commands to the network infrastructure itself n Where are we n What’s going on n What could we possibly try n Did it work? n What stunts can we pull?
Parasitic Traceroute n n n n bash-2. 05 a# paratrace -b 1 m www. slashdot. org Waiting to detect attachable TCP connection to host/net: www. slashdot. org 66. 35. 250. 150: 80/32 1 -16 002 = 63. 251. 53. 219|80 [02] 5. 170 s( 10. 0. 1. 11 -> 66. 35. 250. 150 001 = 64. 81. 64. 1|80 [01] 5. 171 s( 10. 0. 1. 11 -> 66. 35. 250. 150 003 = 63. 251. 63. 14|80 [03] 5. 195 s( 10. 0. 1. 11 -> 66. 35. 250. 150 UP: 66. 35. 250. 150: 80 [12] 5. 208 s 004 = 63. 211. 143. 17|80 [04] 5. 219 s( 10. 0. 1. 11 -> 66. 35. 250. 150 005 = 209. 244. 193|80 [05] 5. 235 s( 10. 0. 1. 11 -> 66. 35. 250. 150 006 = 208. 172. 147. 201|80 [08] 5. 273 s( 10. 0. 1. 11 -> 66. 35. 250. 150 007 = 208. 172. 146. 104|80 [06] 5. 277 s( 10. 0. 1. 11 -> 66. 35. 250. 150 008 = 208. 172. 156. 157|80 [08] 5. 314 s( 10. 0. 1. 11 -> 66. 35. 250. 150 009 = 208. 172. 156. 198|80 [08] 5. 315 s( 10. 0. 1. 11 -> 66. 35. 250. 150 010 = 66. 35. 194. 196|80 [09] 5. 337 s( 10. 0. 1. 11 -> 66. 35. 250. 150 011 = 66. 35. 194. 58|80 [09] 5. 356 s( 10. 0. 1. 11 -> 66. 35. 250. 150 012 = 66. 35. 212. 174|80 [10] 5. 379 s( 10. 0. 1. 11 -> 66. 35. 250. 150 ) ) ) Traceroute is a Layer 3 Process – given a message, repeat it any number of times with a different number of hops through the network it’s allowed to take. TCP is a Layer 4 protocol, capable of recognizing and silently dropping repeated packets. So we can always safely trace at Layer 3 without interfering with communications in TCP’s Layer 4, thus getting a more accurate view of a given session through potentially stateful routers and other devices.
Other Potential Uses n Peer To Peer Networks n Path optimization – n hosts can communicate with eachother and determine not just latency but network complexity separating them n While similar IP space works well for direct matches, as soon as you traverse a single autonomous network it’s hard to realize your neighbors n Custom protocols could allow high resolution timestamps to be used to further measure state n TCP Timestamps may also be extensible for this purpose
Lib. Paketto Cross-Platform TCP/IP Manipulation Library n Easy to use – built for cross-disclipinary integration n n Scan. Viz
API Demo 1 #include "libpaketto. h" int main(int argc, char **argv) { pk_scanrand(“ 10. 0. 1. 11: 80, 22”, NULL, NULL); } What’s going on: No initializations – this scans 10. 0. 1. 11 and collects the responses. Not particularly tweakable.
API Demo 2 #include "libpaketto. h" pcap_handler main(int argc, char **argv) { struct scanrand_config *conf = pk_build_sr_conf(NULL); conf->verbose=1; conf->bandwidth="10 k"; pk_scanrand(argv[1], NULL, conf, NULL); } What’s going on: Now we can actually tweak the method by which this scan will operate. Given the conf structure, we can switch in traceroutes, bandwidth limiters, and much more. But we’re still just running scanrand…
API Demo 3 #include "libpaketto. h" pcap_handler jump_for_joy(FILE *stream, struct pcap_pkthdr *pkthdr, char *packet); int main(int argc, char **argv) { struct scanrand_config *conf = pk_build_sr_conf(NULL); conf->verbose=0; conf->bandwidth="10 k"; pk_scanrand(argv[1], NULL, conf, jump_for_joy, stdout); } pcap_handler jump_for_joy(FILE *stream, struct pcap_pkthdr *pkthdr, char *packet) { fprintf(stream, "Whee, we got a %i byte packet!n", pkthdr->caplen); } What’s going on: Instead of just running the standard scanrand reporter, now we’re running a user provided callback. Note, this callback isn’t called directly – first, the packet is verified using a callback specific in conf->fullscan_verifier. Only if the verifier is satisfied does the programmer’s function need to worry about parsing the packet. But then, why should the programmer have to suffer through that?
API Demo 4 #include "libpaketto. h" pcap_handler jump_for_joy(FILE *stream, struct pcap_pkthdr *pkthdr, char *packet); int main(int argc, char **argv) { struct scanrand_config *conf = pk_build_sr_conf(NULL); conf->verbose=0; conf->ttlrange="1 -20"; conf->bandwidth="10 k"; pk_scanrand(argv[1], NULL, conf, jump_for_joy, stdout); } pcap_handler jump_for_joy(FILE *stream, struct pcap_pkthdr *pkthdr, char *packet){ struct frame x, ic; pk_parse_layers(packet, pkthdr->caplen, &x, 2, DLT_EN 10 MB, 0); fprintf(stream, "Whee, we got a %i byte packet from %sn", pkthdr->caplen, inet_ntoa(x. ip>ip_src)); } What’s going on: Pk_parse_layers takes an arbitrary packet and configures a set of libnet structures to overlay upon it a manageable and modifiable packet structure. It’s quite feasible to modify such a parsed packet, and (after pk_recalc_checksums is run) resend it out the very interface it came in on. Of course, that can create certain reflection bugs…
API Demo 5 #include "libpaketto. h" pcap_handler jump_for_joy(FILE *stream, struct pcap_pkthdr *pkthdr, char *packet); int main(int argc, char **argv) { struct scanrand_config *conf = pk_build_sr_conf(NULL); conf->ttlrange="1 -20"; pk_scanrand(argv[1], NULL, conf, jump_for_joy, stdout); } pcap_handler jump_for_joy(FILE *stream, struct pcap_pkthdr *pkthdr, char *packet) { struct frame x, ic; pk_parse_layers(packet, pkthdr->caplen, &x, 2, DLT_EN 10 MB, 0); if(x. icmp && pk_parse_icmp(&x, &ic)){ fprintf(stream, "Trace to %s stopped at %sn", inet_ntoa(x. ip->ip_src), inet_ntoa(ic. ip>ip_src)); } else if(x. tcp) { fprintf(stream, "Response from %s, flag vals %in", inet_ntoa(x. ip->ip_src), x. tcp>th_flags); } } What’s going on: ICMP errors contain large swaths of the errors that spawned them – if only something existed to read them! Pk_parse_icmp will take a source “master frame” and fill into a destination frame what can be gleaned from the ICMP payload. This lets us run stateless traceroutes quite trivially.
Phentropy n How random is random? “Eyeballing the numbers“ n Statistical tests a la Diehard n n Visualization of entropy can be a powerful tool "Management buy in" -- undeniable results n "You can show a system to be buggy, but not bug free“ n n Zalewski showed “Strange Attractors” effectively visualize many forms of entropy
Open. QVIS n n n Genuinely revolutionary volumetric renderer Uses GPU resources to gain order of magnitude improvements in 3 D volume rendering speeds Trivial to program for n n n Stream your matrix to disk, write a trivial metafile Open Source Phentropy n n n 1. x: Exclusively Open. QVIS 2. x: Received patch for Pov. RAY 3. x: Mmmmm…mayascript
Visualization n n 1: Select arbitrary data stream 2: Choose arbitrary character size(byte, dword, etc). 3: Read four "characters" as integers 4: Calculate three differences between the four values(A, B, C, D) n n n Yes, these are first order differentials 5: Treat the first value as X, second as Y, third as Z. Plot a point. 6: Return to Step 3
Extracting Information n n n 1) Select data stream whose past we have a strange attractor graph against. Use same basic “settings” as before. 2) Read three characters as integers(A, B, C). 3) Calculate the two differences between these three values. (X, Y) 4) X and Y are fixed, leaving one dimension of freedom – Z. Draw a line. 5) Wherever the line intersects with an attractor, at some point there has been a collision at this difference in the past. 6) Add the difference to C. This is the predicted value of D.
SSL vs. IDS: The Eternal Conflict n SSL Annoys Me. n n IDS Annoys Me. n n Certificate compromise is extraordinarily damaging – all past data lost, all future data lost, attacker only needs to passively monitor or sniff “We’re under attack!” “That’s nice, dear. ” I respect those who have faith in both n The conflict between the two annoys me most!
Some Choice IDS monitors the network traffic between the trusted and the untrusted, watching for attacks n SSL encrypts the network traffic between the trusted and the untrusted, blinding all watchers except for the presumably vulnerable endpoint n Choice: Suppress passive and suffer active, or suppress active and suffer passive. n Ouch. n
Auditing SSL n n n Like most PKI systems, SSL uses asymmetric crypto to securely transmit a small amount of data for symmetric cryptosystems The amount is small, but not minimal The negotiated master secret is segmented into no less than four and possibly up to six independent crypto keys n "Very very bad if master secret gets compromised -- all is lost!" n n No, all is lost if the certificate is lost : -) Master secret is not atomic
Selective Security Centralization for SSLEncrypted Traffic n Master Secret serves six keys: n n n Two handle encryption from client to server and vice versa Two handle authentication from client to server and vice versa Two handle initialization vectors from client to server and vice versa n n n 3 DES-CBC These keys are completely independent Selective Centralized Monitoring of SSL-Encrypted Traffic n n Since we have independent keys for independent traffic, we can transfer just the encryption key from the client to the server to the IDS -- it'll pick up the traffic from the insecure side of the network, without being able to intercept presumably secure (or at least mandatorily unshareable) content. IDS doesn't need to do RSA -- just pick up keys on an encrypted channel Key transfer occurs before data transfer -- can disauthorize traffic IV may introduce interesting capability -- read traffic *after* highly sensitive exchange (authentication credentials)
Alternative Approaches n Certificate Transfer n IDS gets a copy of the cert n Violates 1 st Law of Private Keys: Thou Shalt Not Transport Thy Private Key Adds RSA decryption load to IDS, which is already scrounging for cycles n ssldump can be pressed into service today to support this for SSL 3 n n Attack: Switch to SSL 2
Alternative Approaches(2) n Mix IDS w/ Inline SSL Accelerators n IDS lives between accel and server farm n IDS’s are famously Do. Sable – use hubbed net Servers never see cryptography (can’t make any decisions based on it) n Issues with HTTP rewriting n Puts plaintext on a wire n
Alternative Approaches(3) n Plaintext Forwarding n “I got this message from a user…” n n Optionally: “Should I respond? ” Adds latency if each message needs to be authenticated Relatively high bandwidth Doesn’t require interfacing with crypto engine, or even web server n n n Can be built into web applications, which are necessarily passed the web request of the client Totally immune to dissynchrony Can be even more selective about what traffic to expose / verify
Questions What’s needed? n What’s unneeded? n
Скачать презентацию Applied Black Op Networking on Windows XP Dan
042e463dc86a3b5c1bde0a3eedf8b5fb.ppt