Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
×
Security

Black Ops of TCP/IP: Paketto Keiretsu 1.0 Release 319

Effugas writes "After pushing OpenSSH to perform feats of secure tunneling far beyond what I ever expected it could do, it became clear that some genuinely useful modes of network operation were simply inaccessable without either replacing or manipulating core network protocols. Since the basic infrastructure of the Internet isn't likely to change any time soon, that left...creative manipulation and reconstruction of the Lingua Reseaux: TCP/IP. Taking advantage of expectations, pitting layers against eachother, finding new uses for old options and data fields -- instead of simply unleashing the latest incarnation of some "Ping of Death", could such work unveil hidden functionality within existing networks? As I discussed at Black Hat 2002 and the inimitable Defcon X, the answer is yes. And now, proof of this is ready. BSD Licensed (in deference to the very source of TCP/IP), The Paketto Keiretsu, Version 1.0, is a collection of five interwoven "proof of concepts" that explore, extract, and expose previously untapped capacities embedded deep within networks and their stacks, at Layers 2 through 4. The five -- scanrand, minewt, lc ( linkcat ), paratrace, and the OpenQVIS cross-disciplinary-a-go-go phentropy -- demonstrate Stateless TCP Scanning, Inverse SYN Cookies, Guerrila Multicast, Parasitic Tracerouting, Ethernet Trailer Cryptography, and quite a bit more. (For details, stop by DoxPara Research or check out the latest slides. The academic paper is coming "soon".) In terms of actual usefulness, scanrand is no nmap, but it's still interesting: During an authorized test inside a multinational corporation's class B, scanrand detected 8300 web servers across 65,536 addresses. Time elapsed: approximately 4 seconds."
This discussion has been archived. No new comments can be posted.

Black Ops of TCP/IP: Paketto Keiretsu 1.0 Release

Comments Filter:
  • Please be nice (Score:5, Informative)

    by thalakan ( 14668 ) <jspence@@@lightconsulting...com> on Monday November 18, 2002 @07:22PM (#4702110) Homepage
    Hi - www.doxpara.com is temporarily pointed at shaitan.lightconsulting.com, a quad Xeon hosted at Via.net in Palo Alto. Please be nice to my server so I don't have to drive over there and fix it...
  • Re:hey (Score:0, Informative)

    by Second_Derivative ( 257815 ) on Monday November 18, 2002 @07:24PM (#4702131)
    Buzzwords mainly, but basically some bloke picked over the specs for TCP/IP, put together some tools that do really pathological things with packets and take advantage of what various TCP/IP implementations expect and use that to agressively map networks.

    Uh... in other words, nothing new whatsoever. NMAP's been doing this for ages, this is just more of the same. At least that's what it looks like, the submitter did an absolutely lousy job of actually getting to the point (what the fuck does "Paketto Keiretsu" actually DO!?)
  • Re:What language? (Score:4, Informative)

    by jlittle ( 122165 ) <jlittle.cis@stanford@edu> on Monday November 18, 2002 @07:26PM (#4702144) Homepage
    keiretsu = corportation/firm in japanese
    packetto = loan worn (usually in katakana) meaning packet.

    ie.. Packet Company in Japanese
  • by Wanker ( 17907 ) on Monday November 18, 2002 @07:43PM (#4702285)
    I don't quite follow what scanrand does that a normal SYN-based scanner does not except that it is broken into two parts so that potentially a different system could be used to receive the packets sent by the first system. Why would this be useful?

    I guess he refers to embedding a code in each packet sent out to validate that only "real" packets are accepted by the receiver as "Inverse SYN Cookie". I don't understand why this is important, tho.

    The "paratrace" program is quite interesting-- from the README:

    paratrace

    Paratrace traces the path between a client and a server, much like "traceroute", but with a major twist: Rather than iterate the TTLs of UDP, ICMP, or even TCP SYN packets, paratrace attaches itself to an existing, stateful-firewall-approved TCP flow, statelessly releasing as many TCP Keepalive messages as the software estimates the remote host is hop-distant. The resultant ICMP Time Exceeded replies are analyzed, with their original hop count "tattooed" in the IPID field copied into the returned packets by so many helpful routers. Through this process, paratrace can trace a route without modulating a single byte of TCP/Layer 4, and thus delivers fully valid (if occasionally redundant) segments at Layer 4 -- segments generated by another processe ntirely.


    Nutshell summary: this uses an existing open TCP connection to run a traceroute through a firewall that would otherwise tell you to take off. I could certainly see this being useful.

    Some good background reading on O'Reilly's Safari online books site if your TCP/IP internals are a bit rusty:

    Internet Core Protocols: The Definitive Guide [oreilly.com]

    TCP/IP Illustrated, Volume 1: The Protocols [oreilly.com]
  • by Effugas ( 2378 ) on Monday November 18, 2002 @08:02PM (#4702410) Homepage
    SCANRAND
    ========
    Really, really fast port scanner, that can also trace network paths. Port scanning is simply the act of asking a machine if you can start up a conversation with a certain port of its, and marking down "yes" or "no" depending on the response. Normally, there's lots of overhead as you keep track of who you sent requests to and thus who you're expected responses from. Overhead, or "state", makes things slow. So scanrand is stateless -- right when you start up, it splits in two. One half asks everyone, "Heh! What are you hosting!" The other half picks up responses, "Hmmm, some guy just said he has a web server."

    Now, there's a problem: If someone knows I'm not keeping track of who I'm scanning, they can just throw fake responses back at me. But TCP lets me embed a little signature with every connection request -- the "Sequence Number". This number will be returned to me when I get a valid response from a host that I scanned. So I take the IP and the port of the machine I scan, encrypt it into the sequence, and send off the request. When I get the response back, I look at the ACKnowledgement, compare it to the IP and port of the machine that's talking to me, and immediately know whether I ever scanned this guy in the first place.

    So, that's why I get to scan really fast. Mind you, it's the least impressive part of Paketto in raw technical terms -- but it's definitely useful as hell.

    MINEWT
    ======
    What if you could just run a program, and a router showed up on your network? I don't mean physically, but I also don't mean "having anything visibly related to the computer hosting it". It'd be virtual, with its own separate IP addresses and it's own MAC addresses too. It'd be portable to any machine on the LAN, maybe it'd be fast, but it'd definitely be amazingly flexible -- no chips to make, no wires to crimp. Run this software, and there's something new on your net.

    That's what minewt is -- a new router that just shows up and works. Now, it happens to do some funky things -- Guerilla Multicast involves taking what your local network sees as a broadcast or multicast address and attaches it to what the outside world sees as just another IP of a single host. So the single host communication goes out, but once the packet returns, it's flooded to a host of happy listeners. (Such is the theory.) MAC Address Translation is also slightly cool -- NAT is all about using a Layer 4 TCP/UDP port to figure out which Layer 3 IP address (the 10.*'s an 192.168.*'s all us Linksys folk live behind) an incoming packet from the internet is really supposed to be going to.

    It ain't your gateway that downloaded all those MP3's, even if that's the IP address on that flow of music.

    Well, there's also this tech called ARP -- the Address Resolution Protocol. Your local network doesn't have a clue about IP addresses -- it just has these unique factory assigned bitstrings that uniquely identify everyone. ARP is used to translate the Layer 3 IP -- 10.* or whatever -- to the MAC address the factory assigned.

    NAT goes from L4(Port) to L3(IP). ARP goes from L3(IP) to L2(MAC).

    MAT -- MAC Address Translation -- just combines the two. L4(Port) leads to the combination L3(IP)/L2(MAC).

    End result? Multiple hosts can share the same IP address. Cool.

    LC [LINKCAT]
    ============
    I've got a wire. I want to talk on it -- but I can't, I've got all these sockets and programs and limitations in the way. Or at least, I had them.

    1) Execute lc -m00 and start typing hex. Whatever hex bytes I type show up on the ether.
    3) Profit.

    Or,

    1) Execute lc -l00 and start watching everything on the network go by in hex. ANything I like, I can copy, then run lc -m00 and paste back onto the wire once again.
    3) Profit.

    lc has a really interesting mode that's based on the fact that you can actually put data in a frame *after* IP is done with it -- it's called an ethernet trailer, and happens all the time when you try to send a packet smaller than the minimum legal length for ethernet. Well, as long as we can throw data after our packet, lets put crypto in it -- lets sign our frame! Basic support for SHA-1 HMAC's is provided.

    PARATRACE
    =========
    Alright, this is kinda neat. You've got a connection to some host, right? You want to know how your packets are getting there. But if you use normal traceroute, you're gonna start up a whole new connection. Paratrace gets around that -- you see, TCP lets you repeat packets; actually, by repeat, it's more like "The network can break and accidentally cause packets that were assumed to have been dropped to mysteriously come back to life; we handle this screwup just fine." So instead of spawning a whole new connection for our traces, we run our traceroute -- which is entirely a Layer 3 IP hack -- using a legitimate Layer 4 TCP packet. When the data eventually gets there, it's mostly ignored -- oh, the network screwed up again.

    If there's a stateful firewall in the way, well, it's looking at Layer 4 data, which is 100% valid.

    PHENTROPY
    =========
    See a cloud? Might be random. See a bunch of triangles? That ain't random. See the Borg Cube? Yeah, that's the FreeBSD kernel. This is an extension of Michel Zalewski's excellent Phase Space Analysis of TCP/IP Sequence Numbers, done with an incredibly interesting tool called OpenQVIS. Those images render *fast*, folks. 15-45fps fast.

    Terribly sorry I didn't do a writeup like this to begin with; hopefully the Keiretsu makes a bit more sense now.
  • Clarification (Score:5, Informative)

    by dew ( 3680 ) <david@week l y .org> on Monday November 18, 2002 @08:10PM (#4702465) Homepage Journal
    Dan enjoys being witty with words. A "keiretsu" is a conglomeration of not-100%-related business units under a single roof. Mitsubishi makes cars and huge boats, Yamaha makes motorcycles and electronic synthesizers, etc.

    The Paketto Keirestu is a conglomeration of program units that do really bastardized and interesting things with packet manipulation and flow. It's a catchy little title, I thought, but that's MHO. ;) Dan, for those curious, is (AFAIK) not proficient in Japanese. =)

    -david
  • by ryanr ( 30917 ) <ryan@thievco.com> on Monday November 18, 2002 @08:34PM (#4702597) Homepage Journal
    I guess he refers to embedding a code in each packet sent out to validate that only "real" packets are accepted by the receiver as "Inverse SYN Cookie". I don't understand why this is important, tho.

    With a traditional scanner, the scanner either has to maintain state (i.e. don't accept a reply to my scan request if I haven't sent it yet, nor if it doesn't match my sequence number, etc..) or it will be subject to the scanee spoofing replies. For example, if you figure out that I'm scanning you, then you can just start generating SYN-ACK packets and lie to me.

    By using inverse SYN cookies, the scanee can't reply until/unless it gets the actual SYN packet, and the scanner doesn't have to maintain any state, and can just blast full-speed.
  • by Effugas ( 2378 ) on Monday November 18, 2002 @08:38PM (#4702626) Homepage
    Yeah, that'll be fixed when Google picks the link up off my home page. Anyway, it's the next story after Paketto.

    --Dan
  • Re:not possible (Score:4, Informative)

    by Effugas ( 2378 ) on Monday November 18, 2002 @08:43PM (#4702657) Homepage
    Scan requires one socket.

    Kernel has no idea what's going on, it RSTs anything it gets (which is fine by me).

    --Dan
  • Fun with errors? (Score:5, Informative)

    by LostCluster ( 625375 ) on Monday November 18, 2002 @09:25PM (#4702889)
    Maybe it's too early for anybody to make sense of this thing... but here's what I've got so far: It seems that the great advance here is based on using the IP protocol all by itself in situations where conventionally we use TCP wrapping IP. (Remember class, we had a discussion on leaky abstractions [slashdot.org] recently where we remembered that TCP is what we use when we want to forget that IP exists.) By taking advantage of obscure parts of the IP protocol that we don't usually concern ourselves with, he's been able to use intentionally wayward packets to learn about the network. For example, sending an IP packet with a hopelessly short time to live to take advantage of the fact that whomever has the packet when it when it times out is supposed to send back a packet indicating that error. Turns out most routers do, so he collects that information and gets a traceroute that can go into places where a traditonal traceroute meets with a firewall. And that brings up the potentially dangerous side of things. This flies below our radars, it stays below our firewalls. His packets never go higher than the IP layer of our OSI model stack. (Remember that 7-layer thing that we all had to memorize in networking classes...) I'm not quite sure yet what poking around there gets them other than network topology info, but I kinda get the feeling that if there is something destructive that can be done, we're gonna get blindsided with it.
  • by Effugas ( 2378 ) on Monday November 18, 2002 @09:38PM (#4702949) Homepage
    a) Testing was completed on FreeBSD and Linux. We're trying to get Solaris up; I just got a patch for OpenBSD. Win32 is...hmmm. Theoretically possible.

    b) Docs were added at last minute; I've yet to write a true manual.

    c) The code's tiny and mostly self contained, but I understand your worries. Contact me privately and I'll give you a bit of my history.

    --Dan
  • Re:So what is it? (Score:3, Informative)

    by LostCluster ( 625375 ) on Monday November 18, 2002 @09:44PM (#4702983)
    No, this doesn't work on the horizontal edges of your port range. This works below your TCP and UDP ports. It sends messages that don't quite make it that far up there in order to just see what happens.

    If you don't know what the OSI Networking Model is yet I suggest you go look it up... [google.com]
  • Re:Fun with errors? (Score:2, Informative)

    by Penguin Follower ( 576525 ) <scrose1978@gma[ ]com ['il.' in gap]> on Monday November 18, 2002 @10:22PM (#4703147) Journal
    "I'm not quite sure yet what poking around there gets them other than network topology info, but I kinda get the feeling that if there is something destructive that can be done, we're gonna get blindsided with it."

    Ditto... You're not the only one worried about it!
  • by CoolVibe ( 11466 ) on Monday November 18, 2002 @10:54PM (#4703273) Journal
    I compiled the paketto keiretsu and toyed with it. (I'm still trying to get Qvis to compile so I can generate some cool graphs). Anyway, all the tools there can be rate-limited. Try the -b option.

    As for your worries about hyperspeed scanning, well, it's quite bandwith intensive. I guess network operators would notice if someone was scanning the entire internet this way. 2^16 hosts scanned in 4 seconds at full throttle means that 2^32 hosts takes 2^16 times longer. If the network was being satrurated for that amount of time, network operators _WILL_ notice.

  • Re:...wha? (Score:4, Informative)

    by m1a1 ( 622864 ) on Monday November 18, 2002 @11:20PM (#4703363)
    I'll try and hook you up here. Seeing as most of the replies to this I have checked were ridiculous. Basically what these guys are looking at is new ways to use the lower parts of the OSI model.

    The networking model is divided into seven layers. These guys are looking at mainly levels 2-4. These layers are: 2) Data Link, 3) Network, 4) Transport. It looks like most of this focuses on the Network and Transport Layer, where TCP/IP live (reverse respectively). There are basic things you can do with tcp/ip values and protocols, such as trace route, ping, etc. They are finding new things. An example of the typical tcp/ip function is the traceroute. You send a packet with TTL(Time to Live) set to 1. Whoever it hits tells you it died. Then you do 2. Slowly you find your way to the destination, tracing each hop along the way. They are finding new, similar uses for tcp/ip.
  • kieretsu (Score:1, Informative)

    by Anonymous Coward on Monday November 18, 2002 @11:37PM (#4703448)
    a kieretsu is actually a little more than just the word for corporation. it's a structure whereby multiple companies own stock in each other in a ring formation. so A owns stock in B which owns stock in C which owns stock in A. good and bad theories on the purpose. some think it's a useful way of monitoring performance because companys are watching other companies (but are in turn being watched etc...) which is more efficient than individual shareholders watching companies. others thinks its a way for managers to remain entrenched (i won't vote to fire you if you don't vote to fire me). not sure what any of tha that has to do with packet scanning/mangling tools.
  • Re:Odd links (Score:3, Informative)

    by CoolVibe ( 11466 ) on Monday November 18, 2002 @11:38PM (#4703450) Journal
    safety scissors - Cut
    Elmer's glue - Paste
  • by Anonymous Coward on Tuesday November 19, 2002 @01:01AM (#4703775)
    64K IP range in 4 seconds...
    so a 1Gbps Ethernet has ~1.5Mpps @ minimum size (64-byte).

    It will take ~0.044 seconds to transmit your 64K 'SYN' packets. (Hope your routers don't drop any due to congestion :)
    Now wait some reasonable time for the last of the responses to trickle in: ~200ms.
    8300 responses: ~0.006s.

    So the time would be:
    0.044+0.200+0.006 = ~250ms.

    Now, assume you have 100T. This is x10 for the send/receive time, the same for the latency, so ~700ms.

    So the network in question had ~30Mbps of bandwidth available.

    seems possible.
  • TCP traceroute (Score:3, Informative)

    by Animats ( 122034 ) on Tuesday November 19, 2002 @02:04AM (#4704024) Homepage
    Yes, with this you can do traceroutes through firewalls that block ICMP, but pass TCP. That could actually be useful.

    TCP Traceroute is useful enough that it's already been implemented by somebody else. [toren.net] GPL, and for Linux, with an RPM available, even.

  • by Anonymous Coward on Tuesday November 19, 2002 @03:53AM (#4704366)
    People interested in this might also be interested in, "Covert Channels in the TCP/IP Protocol Suite" [firstmonday.org].
  • by jericho4.0 ( 565125 ) on Tuesday November 19, 2002 @04:12AM (#4704419)
    He has come up with some very novel and bright ways to do several old things. The tools aren't blackhat or whitehat by themselves, but have one big blackhat advantage in that the're not going to be detected by anyone yet. They all have interesting uses in network admin or debuging.

    I haven't tried them so I'm probably missing things.The tools are;

    1) a _very_ fast portscanner. It lets you find computers and services on a given network.

    2) a virtual router. Lets multiple hosts share the same IP address.

    3) a pipe to ethernet thingy, lets you type directly out onto the network. You'ld be quite the 31337 hacker if you used this one regulary.

    4) a silent traceroute that'll let you probe behind a NAT firewall. wow. That's kinda nasty.

    5) and the coolest one of the bunch, a program that renders the randomness of a remote-machines packets into 3D space. Cool.

  • by Kynde ( 324134 ) <kynde@[ ].fi ['iki' in gap]> on Tuesday November 19, 2002 @06:59AM (#4704810)
    As for your worries about hyperspeed scanning, well, it's quite bandwith intensive. I guess network operators would notice if someone was scanning the entire internet this way.

    Err... it's the reverse SYN that makes the Keiretsu port scanner interesting. Still it's not one bit stealthier than an nmap doing the ordinary SYN scanning.

    For example banks record every incoming TCP SYN packet that leaver a socket half-open (i.e. for which the responded SYN ACK is never acked in return) and their alarms sound when they start receiving TCP SYN packets for "suspicious" port numbers, for a bank webserver that is pretty much anything outside 80. Well, not alarms, but they do usually take action if there are more of such packets (indicating a pattern, e.g. a scan).

    Then again, port scanning in an environment where it may get logged indicates that some basic things have been forgotten. Attacking a bank on an IP level and looking for open ports is like trying to score J.Lopez, theoretically possible but pointless in practice.
  • by Rolo Tomasi ( 538414 ) on Tuesday November 19, 2002 @10:03AM (#4705711) Homepage Journal
    Alright, after a bit of fiddling, I got it to work. If anyone's interested, here's how I did it:
    1. ./configure
    2. dos2unix libtomcrypt/makefile (this makefile is totally fscked ... and it's in CR+LF format, so you have to convert it first)
    3. vi libtomcrypt/makefile
      1. :13s/rs/rc/
      2. :5s/O6/O2/
      3. :41,46s/zlib\///g
    4. make clean && make
    5. ranlib libtomcrypt/libtomcrypt.a
    6. make clean && make
  • Re:kieretsu (Score:3, Informative)

    by Effugas ( 2378 ) on Tuesday November 19, 2002 @10:11AM (#4705755) Homepage
    Well, it's a bit more complex than that. Scanrand was branched to form Paratrace. Linkcat's -f/-F flags output integers suitable for graphing by Phentropy. Minewt gets its ass kicked by scanrand, and will eventually support the ethernet crypto of linkcat.

    --Dan

FORTRAN is not a flower but a weed -- it is hardy, occasionally blooms, and grows in every computer. -- A.J. Perlis

Working...