Transcript Applied Black Op Networking on Windows XP

Applied Black Op
Networking on
Windows XP
Dan Kaminsky, CISSP
DoxPara Research
http://www.doxpara.com
Overview

Paketto Keiretsu





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?




Welcome to Black Hat Windows
Libpaketto
SSL vs. IDS
Much, much more
Scanrand

High Speed TCP Scanner and Network Tracer

Most well known statistic:
65,536 Addresses Scanned on 80/tcp
 8,000 Replies Received
 Time Elapsed: 4 Seconds


Experiment in Secure Stateless Manipulation of
Stateful Networks

Performance wasn’t actually the goal
Secure Stateless Operation

“Find a Mirror. Recognize Yourself.”

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.
HTTP Cookies
 Drivers Licenses

TCP Reflectors


Scans begin with a TCP SYN
Components of reply known and controlled by sender:





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#

48 bits worth of reflected capacity
Scanrand’s Reflectors

1.x: Inverse SYN Cookies in the SEQ#

HMAC-SHA1 truncated to 32 bits in the outgoing SEQ



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 #

1.x uses absolute latency from beginning scan – limitation!



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 65K “timeslots”

1ms resolution gives us 65s window

Stamp authenticated by seed
Basic Features






Port and Range Parsing: 1.2.3-4.5-6,8-50:22,80
Traceroute
Port Aliases: quick, squick, known
Bandwidth Limitation
Read Targets From A File
New in 2.x
Single-Threaded Mode w/ SR_NONBLOCK
 API – everything trivially embeddable

Basic Demo 1: Scan













# Quick scan of local network
bash-2.05a# scanrand 10.0.1.1-254:quick
UP:
10.0.1.38:80
[01]
0.003s
UP:
10.0.1.110:443
[01]
0.017s
UP:
10.0.1.254:443
[01]
0.021s
UP:
10.0.1.57:445
[01]
0.024s
UP:
10.0.1.59:445
[01]
0.024s
UP:
10.0.1.38:22
[01]
0.047s
UP:
10.0.1.110:22
[01]
0.058s
UP:
10.0.1.110:23
[01]
0.058s
UP:
10.0.1.254:22
[01]
0.077s
UP:
10.0.1.254:23
[01]
0.077s
UP:
10.0.1.25:135
[01]
0.088s
Basic Demo 2: Traceroute














bash-2.05a# scanrand -b2m -l1-13 www.slashdot.org
002 =
63.251.53.219|80
[02]
0.018s(
001 =
64.81.64.1|80
[01]
0.031s(
003 =
63.251.63.79|80
[03]
0.044s(
004 =
63.211.143.17|80
[04]
0.066s(
005 =
209.244.14.193|80
[05]
0.084s(
006 = 208.172.147.201|80
[08]
0.099s(
007 = 208.172.146.104|80
[06]
0.119s(
008 = 208.172.156.157|80
[08]
0.140s(
009 = 208.172.156.198|80
[08]
0.167s(
010 =
66.35.194.196|80
[09]
0.187s(
011 =
66.35.194.58|80
[09]
0.208s(
012 =
66.35.212.174|80
[10]
0.229s(
UP:
66.35.250.150:80
[12]
0.241s
10.0.1.11
10.0.1.11
10.0.1.11
10.0.1.11
10.0.1.11
10.0.1.11
10.0.1.11
10.0.1.11
10.0.1.11
10.0.1.11
10.0.1.11
10.0.1.11
->
->
->
->
->
->
->
->
->
->
->
->
66.35.250.150
66.35.250.150
66.35.250.150
66.35.250.150
66.35.250.150
66.35.250.150
66.35.250.150
66.35.250.150
66.35.250.150
66.35.250.150
66.35.250.150
66.35.250.150
)
)
)
)
)
)
)
)
)
)
)
)
Hopcount Desync








root@arachnadox:~# scanrand -b1k -e
local.doxpara.com:80,21,443,465,139,8000,31337
UP:
64.81.64.164:80
[11]
0.477s
DOWN:
64.81.64.164:21
[12]
0.478s
UP:
64.81.64.164:443
[11]
0.478s
DOWN:
64.81.64.164:465
[12]
0.478s
DOWN:
64.81.64.164:139
[22]
0.488s
DOWN:
64.81.64.164:8000 [22]
0.570s
DOWN:
64.81.64.164:31337 [22]
0.636s
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










root@arachnadox:~/talk# scanrand -D -vv www.cisco.com:80
Stat|=====IP_Address==|Port=|Hops|==Time==|=============Details============|
SENT:
198.133.219.25:80
[00]
0.000s
Sent 40 on eth0:
IP: i=192.168.11.29->198.133.219.25 v=4 hl=5 s=0 id=216 o=64 ttl=216 pay=20
TCP: p=8621->80, s/a=2785760401 -> 2785760401 o=5 f=16 w=4096 u=0 optl=0
Got 60 on eth0:
IP: i=198.133.219.25->192.168.11.29 v=4 hl=5 s=0 id=216 o=0 ttl=189 pay=20
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.204s
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

TCP Repairs Broken Connections


If a packet is dropped, it will retry
“Hello? … Hellllo? … … … Hello?” <CLICK>



Discovered by Franck Veysset et al.


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?




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

root@bsd:~# arp -s 10.0.1.190 00:e0:18:02:91:9f pub

root@bsd:~# arp -an | grep 10.0.1.190
? (10.0.1.190) at 0:e0:18:2:91:9f permanent published [ethernet]
root@bsd:~# scanrand -i 10.0.1.190 -t0 -b100k 10.0.1.1-254:139
(OUTPUT SORTED)
UP:
10.0.1.12:139
[01]
0.235s
UP:
10.0.1.12:139
[01]
3.191s
UP:
10.0.1.12:139
[01]
9.109s
(+3+6)
UP:
10.0.1.36:139
[01]
0.715s
UP:
10.0.1.36:139
[01]
3.624s
UP:
10.0.1.36:139
[01]
9.639s
(+3+6)
UP:
10.0.1.38:139
[01]
0.755s
UP:
10.0.1.38:139
[01]
4.560s
UP:
10.0.1.38:139
[01] 10.560s
UP:
10.0.1.38:139
[01] 22.758s
UP:
10.0.1.38:139
[01] 46.756s
(+4+6+12+24)

















What About Traceroute?

Traceroute’s as stateless and fast as port
scanning

Traceroute provides active route metrics by issuing
commands to the network infrastructure itself
Where are we
 What’s going on
 What could we possibly try
 Did it work?


What stunts can we pull?
Parasitic Traceroute
















bash-2.05a# paratrace -b1m 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.170s(
10.0.1.11 -> 66.35.250.150
001 =
64.81.64.1|80
[01]
5.171s(
10.0.1.11 -> 66.35.250.150
003 =
63.251.63.14|80
[03]
5.195s(
10.0.1.11 -> 66.35.250.150
UP:
66.35.250.150:80
[12]
5.208s
004 =
63.211.143.17|80
[04]
5.219s(
10.0.1.11 -> 66.35.250.150
005 =
209.244.14.193|80
[05]
5.235s(
10.0.1.11 -> 66.35.250.150
006 = 208.172.147.201|80
[08]
5.273s(
10.0.1.11 -> 66.35.250.150
007 = 208.172.146.104|80
[06]
5.277s(
10.0.1.11 -> 66.35.250.150
008 = 208.172.156.157|80
[08]
5.314s(
10.0.1.11 -> 66.35.250.150
009 = 208.172.156.198|80
[08]
5.315s(
10.0.1.11 -> 66.35.250.150
010 =
66.35.194.196|80
[09]
5.337s(
10.0.1.11 -> 66.35.250.150
011 =
66.35.194.58|80
[09]
5.356s(
10.0.1.11 -> 66.35.250.150
012 =
66.35.212.174|80
[10]
5.379s(
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

Peer To Peer Networks

Path optimization – n hosts can communicate with
eachother and determine not just latency but
network complexity separating them


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
Custom protocols could allow high resolution
timestamps to be used to further measure state

TCP Timestamps may also be extensible for this purpose
LibPaketto


Cross-Platform TCP/IP Manipulation Library
Easy to use – built for cross-disclipinary
integration

ScanViz
API Demo1
#include "libpaketto.h"
int main(int argc, char **argv)
{
pk_scanrand(“10.0.1.11:80,22”, NULL, NULL, NULL,
NULL);
}
What’s going on:
No initializations – this scans 10.0.1.11 and collects the responses. Not
particularly tweakable.
API Demo2
#include "libpaketto.h"
pcap_handler main(int argc, char **argv)
{
struct scanrand_config *conf = pk_build_sr_conf(NULL);
conf->verbose=1;
conf->bandwidth="10k";
pk_scanrand(argv[1], NULL, conf, NULL, 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 Demo3
#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="10k";
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 Demo4
#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="10k";
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_EN10MB, 0);
fprintf(stream, "Whee, we got a %i byte packet from %s\n", 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 Demo5
#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_EN10MB, 0);
if(x.icmp && pk_parse_icmp(&x, &ic)){
fprintf(stream, "Trace to %s stopped at %s\n", inet_ntoa(x.ip->ip_src), inet_ntoa(ic.ip>ip_src));
} else if(x.tcp) {
fprintf(stream, "Response from %s, flag vals %i\n", 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

How random is random?
“Eyeballing the numbers“
 Statistical tests a la Diehard


Visualization of entropy can be a powerful tool
"Management buy in" -- undeniable results
 "You can show a system to be buggy, but not bug
free“


Zalewski showed “Strange Attractors”
effectively visualize many forms of entropy
OpenQVIS



Genuinely revolutionary volumetric renderer
Uses GPU resources to gain order of magnitude
improvements in 3D volume rendering speeds
Trivial to program for



Stream your matrix to disk, write a trivial metafile
Open Source
Phentropy



1.x: Exclusively OpenQVIS
2.x: Received patch for PovRAY
3.x: Mmmmm…mayascript
Visualization




1: Select arbitrary data stream
2: Choose arbitrary character size(byte, dword, etc).
3: Read four "characters" as integers
4: Calculate the three differences between the four
values(A,B,C,D)



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






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

SSL Annoys Me.


IDS Annoys Me.


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

The conflict between the two annoys me most!
Some Choice




IDS monitors the network traffic between the
trusted and the untrusted, watching for attacks
SSL encrypts the network traffic between the
trusted and the untrusted, blinding all watchers
except for the presumably vulnerable endpoint
Choice: Suppress passive and suffer active, or
suppress active and suffer passive.
Ouch.
Auditing SSL



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

"Very very bad if master secret gets compromised -- all is
lost!"


No, all is lost if the certificate is lost :-)
Master secret is not atomic
Selective Security Centralization for SSLEncrypted Traffic

Master Secret serves six keys:



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



3DES-CBC
These keys are completely independent
Selective Centralized Monitoring of SSL-Encrypted Traffic




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

Certificate Transfer

IDS gets a copy of the cert

Violates 1st Law of Private Keys: Thou Shalt Not
Transport Thy Private Key
Adds RSA decryption load to IDS, which is already
scrounging for cycles
 ssldump can be pressed into service today to
support this for SSL3


Attack: Switch to SSL2
Alternative Approaches(2)

Mix IDS w/ Inline SSL Accelerators

IDS lives between accel and server farm

IDS’s are famously DoSable – use hubbed net
Servers never see cryptography (can’t make any
decisions based on it)
 Issues with HTTP rewriting
 Puts plaintext on a wire

Alternative Approaches(3)

Plaintext Forwarding

“I got this message from a user…”




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



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?
What’s unneeded?