Title: Black Ops 2004 LayerOne
1Black Ops 2004_at_ LayerOne
2Introduction
- Who am I?
- Senior Security Consultant, Avaya Enterprise
Security Practice - Author of Paketto Keiretsu, a collection of
advanced TCP/IP manipulation tools - Speaker at Black Hat Briefings
- Black Ops of TCP/IP series
- Gateway Cryptography w/ OpenSSH
- Protocol Geek
3Whats On The Plate for Today?
- / char descrip256 Youll see /
4What is DNS
- DNS Domain Name System
- Mechanism for translating human-readable names
into machine routable addresses - Like 411 for the Internet
- As 411 usually but not always yields simple phone
numbers, DNS usually but not always yields IP
addresses - A Given name, find IP
- MX Given name, find Mail
- PTR Given IP, find name
- TXT Given name, find stuff
5Useful Traits of DNS(Very Very Abridged)
- Hierarchical
- .com says where to find addresses in
.doxpara.com, and .doxpara.com says where to find
addresses in foo.doxpara.com - Recursive vs. Iterative Lookups
- Iterative Lookup Ask a server a question, it
tells you where to go to find out the answer - Recursive Lookup Ask a server, it goes out and
finds out the answer for you, and tells you - It queries the hierarchywhich you may control
- Caching
- Responses contain a TTL Time To Live within
which future requests dont require another
message to be sent
6Primary Research Areas for DNS
- Exploitation
- 1999-2000 were filled with exploits against BIND,
the most common DNS server - Not terribly vulnerable now
- DNS Spoofing
- Returning false addresses hijack peoples
outgoing net connections - DNS Tunneling
7DNS Tunneling 1
- How
- Client - Server
- Whats the information for BATCH-OF-ENCODED-DATA.d
oxpara.com? - Server - Client
- The information? Why, its HERES-THAT-DATA-YOU-W
ERE-LOOKING-FOR - Why?
- DNS is extremely permeable it will route
through architectures where often nothing else
will - Captive portals for Wireless Internet
- More -)
8Starting SimpleDNS Tunneling 0
- Who?
- NSTX most popular
- Creates a virtual network device that routes IP
(actually, Ethernet frames) over DNS - Linux Only
- Rumors of various botnets / malware using DNS as
a covert channel
9DNS Tunneling2Entering Userspace
- Starting Simple
- NSTX requires kernel cooperation to get at IP
- Lets make something that doesnt require the
kernel, but still allows remote networking - Remote Networking Im on this network, but all
my traffic is routed through that network over
there preferably securely - Normally done with VPNs (also kernel level)
- SSH Dynamic Forwarding allows secure remote
networking over a single TCP port (Poor Mans
VPN) - So lets start with SSH over DNS
10DNS Tunneling3Problems
- DNS is not TCP
- TCP moves bytestreams, DNS moves records
- Blocks of data
- TCP lets either side speak first, while in DNS,
the server can only talk if the client asks
something - TCP is 8 bit clean, while DNS can only move a
limited set of characters in each direction
(Base64) - This seems so familiar
11DNS Tunneling4Mini-HTTP
- The semantics of DNS are surprisingly similar to
those of HTTP - Many tools have been written with the lets
tunnel everything over HTTP methodology because
it gets through firewalls easier (see first
point) - Those tools that support small message sizes
(like GNU httptunnel) can be quickly modified to
use DNS as an alternate transport - Must use separate streams for upstream vs.
downstream, since downstream reflects all data
from upstream (similar to HTTP, but on a per
packet basis) - But DNS has a feature HTTP servers dont
12DNS Tunneling5Recursive Redux
- Recursive lookup Ask another host to iterate
through the hierarchy to find your answer - Why, its as if every web server was also a web
proxy... - Simple Trick Bounce your traffic off any DNS
server (like, for instance, a captive portals
DNS for free WiFi) - But theres better
13DNS Tunneling6Set em up
- Some DNS servers are dual hosted
- External interface is sending names out
- Internal interface is bringing names in
- Two interfaces because one is behind the firewall
and one is in front - Subdomain Delegation
- It is possible to claim that foo.doxpara.com is
hosted at an arbitrary name server with an
arbitrary IP address - even if you yourself cant route to that
address - someone else can
14DNS Tunneling7and knock em down
- Incoming SSH to Protected Networks via Recursive
DNS - 1. Wrap SSHD in dns-ized httptunnel
- 2. Request that remote DNS daemon look up a
subdomain of a domain you control. Tell that DNS
itll find the answer it seeks at the internal
server with the SSHD-DNS. - 3. SSHD-DNS receives forwarded request, responds
to it. Remote DNS daemon forwards that response
back to you. - 4. Continue with normal SSH over DNS semantics.
- Note This is actually a bad thing
15Changing the Gameplan
- Most tricks require a DNS server under the
requesters control - The client and the final server conspire against
the recursive server in the middle - But what if there is no DNS server under the
clients control? - What can a client do with queries alone?
- Can two clients communicate with eachother
through a DNS server?
16DNS Cache Modulation0
- DNS stores the results of queries, along with a
TTL (Time To Live) - Well known Information Leakage If someone else
looked up a site first, the TTL is different. - Example
- root_at_bsd dig _at_129.210.8.1 mail.layerone.info
sleep 100 dig _at_129.210.8.1 mail.layerone.info - First Reply mail.layerone.info. 4H IN A
66.33.213.202 - Second Reply mail.layerone.info. 3h58m19s
IN A 66.33.213.202 - Destructive If nobody else made a particular
query, then the probe becomes the standard bearer
for max seconds. - Not well known Two hosts can communicate with
eachother through the state change introduced by
a particular query - Possibly the lowest bandwidth channel available,
at 1 bit per query
17DNS Cache Modulation1
- Temporal Bit Mapping
- The sender requests a low traffic, preferably low
TTL name from the server. - The receiver requests the same name, and sees it
at some decremented TTL value. It thus knows at
approximately what time the cache entry will
expire. - Within some sender window after expiration, the
sender either does (1) or does not (0) issue
another request for the same name - Within some receiver window, the receiver
checks the name after the window expiration. IF
the TTL is max, then the bit was 0. IF the TTL
is not max, then the bit was 1. - Capacity 1 bit per Max TTL period (slowwww)
18DNS Cache Modulation2
- Spatial Bit Mapping
- Spread the load across multiple names, probably
each retrieved off a wildcard server - Wildcard 00000001.doxpara.com still resolves
- Bits are set within a setting window
- Bits are destructively read within a reading
window, using an identical TTL strategy. - Next series of bits may be sent when TTL of last
sent request by the sender expires. - Capacity 1 bit per name per Max TTL period
(slow)
19DNS Cache Modulation3
- Bidirectionality
- Simply use two separate channels, or timeshare
one channel - Its just a shared medium
- Adaptability
- Anything that can be changed by one and seen by
another can be used to send data - Web Counters
- IP ID counters in IP Stacks
- Whether a car was washed
- Did it increment or not? Were there sharp
spikes between 601 and 602? - You can always send a bit can we send more?
20History of DNS Storage
- Long history of storing data in DNS
- Means
- TXT records
- AXFR Zone Transfer (can be arbitrarily large, but
doesnt work from almost any restricted network
since its TCP) - Downsides
- Very inefficient packet size (w/o AXFR) is
locked below 512 bytes, and you only get a little
more than half of the packet filled with a
payload - DNS can get really slow, especially under load
- Upsides
- Everyone has a DNS server, and it caches
21KDNS0
- What do we have?
- A Very Dynamic DNS server
- A Desire to Send More Than A Bit
- Fine, Ill go host a name on a server
- A challenge to send something new
- What do we get?
22KDNS1
- Voice over DNS TXT w/ Streaming Audio
- Speex codec supports Voice compression at 2kbps
(best public codec) - Ends up (with headers) being about 356
bytes/second - We can traffic 356 bytes per second through even
extremely slow DNS servers - Power to the Caching People
- Use a TTL of WINDOW seconds (20s)
- All listeners behind the same DNS server will
split the same stream
23KDNS2
- Server HOWTO
- .server.com
- TTLWINDOW
- TXT (or MX) 1.0s or 0.5s of audio
- latest.server.com
- CNAME to ..server.com
- TTL0
- This may be broken by resolvers with minimum TTL
requirements (implemented to fight Dynamic DNS
server loads)
24KDNS3
- Client HOWTO
- Retrieve latest.server.com, learn
..server.com - Retrieve audio samples from .ser
ver.com up through .server.com - Prefer to start playing at a packet that has
spent some time decrementing in the cache
binary search for oldest sample within the window - Add random jitter for the start sample this
way, everyones at a different point in the
stream, and if the lead looker drops, someone
else will be next up to be first in line
25KDNS4
- Alternate Implementation Proxy-Friendly HTTP
Streaming - Abandon DNS entirely simply distribute 3-10s
chunks of audio over HTTP and let proxy servers
share them out - Requires client cooperation, and greatly
increases latency, but solves the (bandwidth)
problem that proxies dont cache streams - Proxies dont support TTLs, though a server
side script would need to monitor that - HTTP of course supports much higher bandwidth!
26Crossroads
- Everything weve done with DNS is slow and low
bandwidth? - DNS servers store little data, and may return it
relatively slowly - Cant we go any faster? Is there no DNS
solution with capacity? - Many hands make light work
- There are many many many DNS servers
- And almost all of them cache.
27DomainCast0
- The basic concept
- Normal DNS operation Talk to your own server it
retrieves data on demand from the official server
upstream - Domaincast DNS operation Talk to servers with
different blocks preloaded into their cache each
of those blocks refers to the location of other
cached blocks. Upstream server has actually
preloaded data (through directed queries) into
all of the servers. - This is possible. This is not necessarily a good
idea. Dont try this at home.
28DomainCast1
- Sidestepping Limited Resources
- Capacity
- 20K/server 80 records _at_ 256bytes
- 700MB Knoppix, a full Linux distribution
- 700MB / 20K 35,000 servers required
- Number of DNS servers detected in a single class
A 140,000 (More on this later) - Speed
- 1Kb/s 35,000 35MB/s
- Would require upload of 3.5MB/s
- 50 packet / formatting overhead 17MB/s
- Not going to achieve peak bandwidth (itd shred
reliability) but not going to get 1k/s either
29DomainCast2
- Packet Formats
- Request ..server.com
- Reply Either TXT or MX
- TXT Base64 Representation of Fixed Size Struct
(describing file size, byte offset, data, and
other servers) - MX Can also represent data as mail server
addresses - Requires dots every 64 characters
- Responses are reordered randomly must sort by
precedence - Some headaches with extra information being
volunteered - MX may stress BIND servers more (triggers search
tree)
30DomainCast3
- Basic Mode All packets retrieved from master
server, provide linked list pointers to same host - 0.file.server.com first block, here for second
- 256.file.server.com second block, here for
third - Etc.
31Domaincast4Population via Brute Force
- Simplest Approach
- Find enough servers that recurse
- DNS servers dont move rapidly - Scan amortizes
well across many populations - Plan out whos going to store which blocks
- Populate servers with data, references to planned
other servers - Easy to validate caching, though not easy to fix
a broken reference - Can populate out of order 64 populating,
verifying streams
32Domaincast50Reverse Serial Propagation
- The problem To populate the first server, you
need the address of the second server. But to
populate the second, you need the addr of the
third. What to do? - Answer Populate backwards. The last server
points nowhere. The second to last points to the
last. The third to last points to the second to
last. - Multi-server last server can equal last server
group. - Server groups may be larger than packet capacity
to list servers just include a random set
33Domaincast51 Reverse Serial Propagation
- Can be quickly and statelessly deployed
- Scan networks with generic recursive probe
- For each incoming request seeking to service the
probe, return whatever(TTL0) and probe with an
actual block request - If a block request comes back from the recurser,
populate the server - If the population packet drops, the upstream
should retransmit - Move back through the file after each server
group fills up - Can be much slower to populate!
34Large Scale DNS Scanning0
- Modding the scanrand codebase
- Basic scanrand concept One half spews traffic,
the other sees what comes back. Little to no
communication between the two halves fast! - Scanrand manages TCP statelessness is a bit of a
novelty to it. DNS is built on UDP, raw packet
manipulation isnt even necessary (it was useful,
though). - Reflection Stateless operation depends on
sending packets out and forgetting, only to have
the necessary data returned back in the response
packet - TCP barely reflects back 48 bits worth of data
- DNS reflects back whatever was in the query
thousands of bits if you want em! - Crypto signatures can be embedded in the
reflection
35Large Scale DNS Scanning1
- Floodable DNS Queries implemented by miname
- Is anyone there, recursive or not?
- Many hosts that dont support recursion will at
least provide a NXDOMAIN, but not all will - We need a generic query that appears to almost
always work - 1.0.0.127.in-addr.arpa PTR - 127.0.0.1
localhost - Everyone is localhost ?
- Will you recurse back to me?
- BIG_COOKIE.server.com
36Large Scale DNS Scanning2
- Returned Results
- Direct You requested, they responded.
- Forward Lookup You requested, they requested
back to you, you responded. - Often not the server that you asked that asks you
- Reverse Lookup You requestedand someone
wondered who you were asking such questions
37Large Scale DNS Scanning3
- More on Reverse Auditing
- Not being too secretive
- root_at_bsd host 64.81.64.164
- 164.64.81.64.IN-ADDR.ARPA domain name pointer
mail.dan.at.doxpara.com - L0phts Antisniff project locate sniffers and
IDSs by watching reverse DNS traffic on the LAN - Miname w/ Co-opted Servers Watch sniffers and
IDSs across the entire internet - TTL0 on PTR replies means they continually look
you up when you pass by them - Hard, but not impossible, to associate reverse
lookup with node scanned to attract - Temporally associated w/ scan
- Multiple scans, out of order, should provide
required correlation - Traceroutes may help too we know whos looking
us up
38Rendering The Flood
- How much data could it be?
- root_at_fire root ls -l dns.log -rw-r--r-- 1
root root 360215644 May 28 1242 dns.log - How are we going to visualize this?
- 3D space could use the tools we used to
visualize the complexity of arbitrary data
39Phentropy w/ OpenQVIS
403D Viz0
- 3D Space provides a potentially valuable
perspective on extremely complex datasets - Volume tools have gotten more mature
- Volsuite Free, Open Source, Full Color, Cross
Platform, Fast - Video games New Absurdly High Speed Graphics
Chipsets
413D Viz1
- Volumetric Texture Based
- Stacks of transparent photos
- Arbitrary complexity data it all gets blurred
in - Limits positional accuracy
- Totally static you cant animate the population
- Particle Vertex Based
- Dots! Dots everywhere!
- Arbitrary positional accuracy floating point
coordinates can be zoomed into - Limits number of particles
- Very easy to make dynamic
- Dynamic particles can express higher dimensional
data
423D Viz2
- Dimensions
- Static XYZ, Color
- Dynamic
- Shape
- Direction
- Color Shift
- Trajectory Shift
- Brightness / Flare
- Surprising aspect of dynamics Motion away from
source point appears to bolster memory /
perception of that point
433D Viz3
- Under Development As yet unnamed Generic 3D
Plotter - Coordinates are streamed in, perhaps with
information about how to render each particle - A more generic version of the Spinning Cube of
Potential Doom - Parallel development ?
44Conclusion
- Stuff Cool
- More Stuff Soon