1HUNT(1) General Commands Manual HUNT(1)
2
3
4
6 hunt - Network security auditing tool.
7
9 hunt [-V] [-v] [-i interface]
10
12 This manual page documents briefly the hunt command. This manual page
13 was written for the Debian GNU/Linux distribution because the original
14 program does not have a manual page. Instead, it has documentation in
15 the GNU Info format; see below.
16
18 Please make sure you KNOW what you are doing before using hunt. It is
19 recommended that you should test how it behaves on some test connec‐
20 tions and then use it wisely.
21
23 Hunt is a program for intruding into a connection, watching it and
24 resetting it. It has several features, which I didn't find in any prod‐
25 uct like Juggernaut or T-sight that inspired me in my development. I
26 found Juggernaut not flexible enough for further development so I
27 started from scratch (see FEATURES and DESIGN OVERVIEW). Note that
28 hunt is operating on Ethernet and is best used for connections which
29 can be watched through it. However, it is possible to do something even
30 for hosts on another segments or hosts that are on switched ports. The
31 hunt doesn't distinguish between local network connections and connec‐
32 tions going to/from Internet. It can handle all connections it sees.
33
34 Connection hijacking is aimed primarily at the telnet or rlogin traffic
35 but it can be used for another traffic too. The reset, watching, arp,
36 ... features are common to all connections.
37
39 Connection Management
40 * Setting what connections you are interested in.
41 * Detecting an ongoing connection (not only SYN started).
42 * Normal active hijacking with the detection of the ACK storm.
43 * ARP spoofed/Normal hijacking with the detection of successful
44 ARP spoof.
45 * Synchronization of the true client with the server after
46 hijacking (so that the connection don't have to be reset).
47 * Resetting connection.
48 * Watching connection.
49
50 Daemons
51 * Reset daemon for automatic connection resetting. * ARP
52 spoof/relayer daemon for ARP spoofing of hosts with the ability
53 to relay all packets from spoofed hosts. * MAC discovery daemon
54 for collecting MAC addresses. * Sniff daemon for logging TCP
55 traffic with the ability to search for a particular string.
56
57 Host Resolving
58 * Deferred host resolving through dedicated DNS helper servers.
59
60 Packet Engine
61 * Extensible packet engine for watching TCP, UDP, ICMP and ARP
62 traffic. * Collecting TCP connections with sequence numbers and
63 the ACK storm detection.
64
65 Misc * Determining which hosts are up.
66
67 Switched Environment
68 * Hosts on switched ports can be spoofed, sniffed and hijacked
69 too.
70
72 -V Print Version
73 -v Verbose (print pids of created threads)
74 -i interface Listen on this interface. Default is eth0
75
77 Let me explain some technical issues which I use in hunt and which are
78 essential for understanding how it works and what you should expect.
79 The important terms are IP spoofing, ARP spoofing and ACK storm. Even
80 if you are familiar with them, you can get some new information.
81
82 IP spoofing
83 You set the packet source address to the IP address of the host
84 you pretend to be.
85
86 ARP spoofing
87 You set the packet source hardware address (source MAC address)
88 to the address of the host you pretend to be.
89
90 Simple Active Attack against TCP connections - It is a well known type
91 of attack in which you send a packet with spoofed IP addresses
92 and possibly also with spoofed ARP addresses (true MAC addresses
93 of client and server - not fake ones as explained further). In
94 this way, you can force a command to the stream but you are
95 likely to receive the ACK storm (as explained further) unless
96 the original client host of the connection is running Linux.
97
98 ARP spoofing
99 I use this term also for forcing the remote host to think that
100 the host I want to be has a different MAC address so the remote
101 host sends replies to that MAC address and the original client
102 host is not able to receive them (but hunt is watching carefully
103 and handles all consequences) (Explaining how to force a host on
104 the network to think that the other host has a different MAC I
105 leave as an exercise - I encourage you to read the source code).
106 Please note that I use the term ARP spoofing instead of the term
107 ARP forcing or something like that. So don't be confused, if I
108 say ARP spoofing, I mean using some MAC address of a host or
109 just some fake MAC address. Note that ARP spoofing (with my
110 meaning to force some MAC) doesn't work on Solaris2.5 because it
111 has expiration timers on ARP entries so you can't easily force
112 Solaris to drop an ARP entry. The entry usually expires after
113 20min or less (but you have a chance to force it and hunt sup‐
114 ports this mode). The expiration timers on Solaris are set by:
115
116 ndd -set /dev/ip ip_ire_flush_interval 60000 /* 1 min */
117 ndd -set /dev/arp arp_cleanup_interval 60 /* 1 min */
118
119 I encourage you to ask your netadmin to set the above values on
120 all Solaris machines. The Win95/NT4sp3, Linux2.0, OSF1 V4.0, HP-
121 UX10.20 are not protected in this way so you can easily use the
122 described technique on them (actually, they have timers, but
123 they are not operating like in Solaris; in fact, only Solaris is
124 the exception). Actually, hunt uses this technique such that it
125 wants to force a fake MAC of the server to the client and a fake
126 MAC of the client to the server. Then both the server and the
127 client are sending packets to that faked MACs (and hunt can of
128 course handle them). However, it is sufficient that only one
129 host has a fake MAC of the other host. The ACK storm can't
130 occur in this situation either. So you can use this technique
131 even if one end is Solaris and the other isn't. You will just
132 succeed in the other host and that is enough. So the only prob‐
133 lem is when the connection is between two Solaris machines. How‐
134 ever, if there is any root connection ongoing you can easily
135 push the commands suggested above without ARP spoofing to the
136 connection and alter the expiration timers of the ARP cache.
137
138 ACK Storm
139 The ACK storm is caused by majority of TCP stacks (!!! Linux2.0
140 is an exception !!!). Let's imagine that you send some data to
141 an ongoing connection to the server (as if sent by the client -
142 with expected seq. numbers, ... ). The server responds with the
143 acknowledgment of the data you sent but this acknowledgment is
144 received by the original client too. But from the original
145 client point of view, the server has acknowledged data that
146 doesn't exist on the client. So something strange occurred and
147 the original client sends the "right" sequence number with ACK
148 to the server. But the TCP rules say that it is required to
149 generate an immediate acknowledgment when an out-of-order seg‐
150 ment is received. This ACK should not be delayed. So the server
151 sends the acknowledgment of non-existent data to the client
152 again. And the client responses, ... Only if the source host of
153 the connection is Linux then the ACK storm doesn't occur. Note
154 that if you use ARP spoofing (forcing) then the ACK storm can't
155 come because one or both ends will send packets with fake MACs
156 and those packets are received by hunt rather than by the other
157 host.
158
159 Connection Reset
160 With a single properly constructed packet you can reset the con‐
161 nection (RST flag in TCP header). Of course, you have to know
162 the sequence number but it is not a problem for hunt which is
163 watching all the time. You can reset server, client, or both.
164 When you reset only one end the other end is reset when it tries
165 to send data to the first host which will response with RST
166 because of the connection reset on it.
167
168 Connection sniffing/watching
169 The simplest thing you can do is to silently sit in you chair
170 and watch hunt output about any connection which you choose from
171 the list.
172
173 Connection Synchronization
174 Well, that's one of the main features of hunt. If you put some
175 data to the TCP stream (through simple active attack or ARP
176 spoofing), you desynchronize the stream from the server/original
177 client point of view. After some work done on that connection
178 you can just reset it or you can try to synchronize both origi‐
179 nal ends again. That is not an easy task. The user on the client
180 is prompted to type some chars and some chars are sent to the
181 client and server. The main goal of all stuff is to synchronize
182 the sequence numbers on both client and server again.
183
184 Switch/Segment traffic rerouting
185 With ARP spoofing you can even force switch so that it will send
186 you the traffic for hosts on another segment/switched port. This
187 is because a switch will think that the MAC belongs to your
188 port. Be careful if your switch has some security policy and
189 MACs have been explicitly set up on a per port basis - but in
190 fact I don't ever see such a configuration on "ordinary" net‐
191 work.
192
193 ARP-relay daemon
194 Don't be confused. I use this term for hunt daemon which is
195 responsible for inserting packets to the network (rerouting) of
196 all data it receives from ARP spoofed hosts.
197
198 Switched environment
199 Well, the hunt is now capable of watching and hijacking hosts
200 that are on switched ports. In common you can't watch the hosts
201 traffic on switched ports but if you first ARP spoof them (with
202 ARP spoof daemon menu) you are able to look at the connections
203 that are between that hosts. First you do arp spoof and the
204 hosts will send you the traffic and from that time you can list
205 the connections between them, then you can watch and hijack
206 them. It is commonly accepted that the switches protect your
207 connections again inside intruders and spoofers. Well, that is
208 still true for carefully setuped switches. The switches that are
209 plugged to the LAN without any port security configuration are
210 useless in the job to protect your LAN.
211
213 The development model is based on a packet engine (hunt.c) which runs
214 in its own thread and captures packets from the network. The packet
215 engine collects information of TCP connections/starting/termination,
216 sequence numbers, and MAC addresses. It collects the MACs and seq.
217 numbers from the server point of view and separate MACs and seq. num‐
218 bers from the client point of view. So it is prepared for hijacking.
219 This information (seq. num., MAC,
220
221 Modules can register functions with the packet engine which are then
222 invoked when new packets are received. A module function determines if
223 the module is interested in a packet or not and can place the packet in
224 a module specific list of packets. A module function can also send
225 some packet to the network if it is desirable to do it very fast. The
226 module (usually in some other thread so it needs to be scheduled to be
227 run) then gets packets from the list and analyzes them. In this way,
228 you can easily develop modules which perform various activities.
229
230 Packets to be sent as a response to the network are described by struc‐
231 tures so you don't have to care about some default fields or checksums.
232 At this time, functions for TCP, ICMP and ARP traffic are already pre‐
233 pared. (UDP is missing because I don't use it in any module)
234
235 A separate set of daemons is used for host resolving (DNS). That is
236 because the gethostbyname/gethostbyname_r function is protected by
237 mutex (As far as I know - it was so two years ago - I didn't try it
238 now) so you can't run it truly parallel in a multithreaded environment.
239 Therefore, the commonly used workaround is to fire up some helper dae‐
240 mons through fork which will run gethostbyname.
241
243 Well, the user environment isn't graphical but I believe that you will
244 like it.
245
246 In the title of all menus is some status information about hunt.
247 First, there is an indication with which menu you are working. Second,
248 the number of packets received by hunt is shown. Hunt pre-allocates
249 some buffers for packets; the status of free and allocated buffers is
250 displayed as the third value. The number of free buffers is low for a
251 high loaded network or the ACK storm or if you have poor hardware. In
252 my case, for example, the numbers 63/64 were normally indicated meaning
253 that only one buffer was used, but after the ACK storm, I have some‐
254 thing like 322/323. Note that the buffers once allocated are not freed.
255 The low number of free buffers can also mean some bug in hunt but I
256 think I carefully debugged all modules to this kind of bug. The last
257 indicator reports which daemons (actually threads) are running. They
258 are: R - reset daemon, Y - arp relayer, S - sniffer, M - MAC discov‐
259 erer. If you switch on the verbose option you get additional informa‐
260 tion about how many packets were dropped - they were fragments (see the
261 bugs) or were malformed, and how many packets belong to other protocols
262 than TCP, UDP, ICMP and ARP. In the prompt for user input is indicator
263 that will tell you through '*' char that hunt added new connection(s)
264 to the connection list since last connection listening.
265
266 General interface
267 In all menus the x key works as escape. The network mask is
268 denoted by the ip_address/mask notation where mask is the number
269 of 1's on the left side of the network mask. For example,
270 0.0.0.0/0 means everything and 192.168.32.10/32 means only that
271 host.
272
273 For most modules is used:
274 l) list items
275 a) add item
276 m) modify item
277 d) delete item
278 They will be referred in this text as l) a) m) d)
279
280 List/Watch/Reset connection
281 You can obtain the list of connections tracked by the hunt
282 packet engine. Which connections are tracked is specified in
283 the options menu. You can interactively watch or reset these
284 connections. You can also perform hijacking on them (next two
285 menu items).
286
287 ARP/Simple hijack
288 ARP/Simple hijack offers you an interactive interface for the
289 insertion of data to the selected connection. You can perform
290 ARP spoofing for both connection ends, for only one end or you
291 can not to do it at all. If you don't do ARP spoofing then you
292 probably receive the ACK storm after typing the first char.
293 When you do ARP spoofing, it is checked if it succeeds. If not,
294 you are prompted if you want to wait until it succeeds (you can
295 interrupt this waiting through CTRL-C of course). After insert‐
296 ing some data to the connection you type CTRL-] and then you can
297 synchronize or reset the connection. If you choose synchroniza‐
298 tion, the user is prompted to type some chars and after he does
299 so the connection will be in the synchronous state. You can
300 interrupt the synchronization process with CTRL-C and then you
301 can reset the connection. Note that CTRL-C is used widely for
302 interrupting an ongoing process. The CTRL-] (like telnet) is
303 used for finishing the interactive insertion of data to the con‐
304 nection. The ARP/Simple hijack doesn't automatically reset the
305 connection after it detects the ACK storm so you have to do it
306 yourself. Note also that ARP/Simple hijack works with the ARP
307 relayer (as described further) so that other connections are not
308 affected. Normally, if you ARP spoof two servers then the
309 ARP/Simple hijack handles only one selected connection between
310 these two hosts but other connections between these two hosts
311 look like they freeze. If you start the ARP relayer, then these
312 other connections are handled and rerouted through. So other
313 connections from one spoofed host to the other are not affected
314 at all. It is recommended to run ARP relayer if you do ARP
315 hijacking of two servers. Note that if you ARP spoof (force)
316 some client MAC to the server then only connections going from
317 the server to that client are affected. Other connections from
318 the server to other machines are untouched.
319
320 Simple hijack
321 Simple hijack allows you to insert a command to the data stream
322 of the connection. When you insert the command, hunt waits for
323 it to complete up to a certain timeout and if the ACK storm
324 doesn't occur, you are prompted for the next command. After
325 that, you can synchronize or reset the connection. Note that
326 you can use the interactive interface to simple hijack when you
327 use ARP/simple hijack without ARP spoofing but if you use full
328 interactive interface of ARP/simple hijack without ARP spoofing
329 you are likely to get the ACK storm immediately after typing the
330 first char. So this mode of hijacking is useful when you have to
331 deal with the ACK storm because it sends your data to the con‐
332 nection in a single packet. When the ACK storm is in progress it
333 is very hard to deliver other packets from hunt to the server as
334 the network and server are congested.
335
337 I call them daemons but they are actually threads. All daemons can be
338 started and stooped. Don't be surprised when you insert or modify some
339 rule in a daemon and it does nothing. The daemon is not running - you
340 have to start it. All daemons are by default stopped even though you
341 can alter the configuration. Common commands in the daemons menu are:
342
343 s) start the daemon
344 k) stop the daemon
345 l) list configuration items
346 a) add config. item
347 m) modify config. item
348 d) delete config. item
349
350 Reset daemon
351 This daemon can be used to perform automatic resets of ongoing
352 connections that hunt can see. You can describe which connec‐
353 tions should be terminated by giving src/dst host/mask and
354 src/dst ports. The SYN flag off means that all specified connec‐
355 tions should be terminated (even ongoing). The SYN flag on means
356 that only newly started connections are reset. So the connec‐
357 tions that are in progress are not affected. Don't forget to
358 start the daemon.
359
360 ARP daemon
361 Here you can do ARP spoofing of hosts. You enter src and dst
362 addresses and desired srcMAC. The dst is then forced to think
363 that src has srcMAC. You can use some fake MAC or better MAC of
364 host that is currently down. You just want that the hosts will
365 send you all the data (so you can even look at packets that are
366 on a different segment or switched port that you will not nor‐
367 mally see) The ARP module looks carefully for packets which will
368 break ARP spoofing of hosts and handle them but you can even
369 specify the refresh interval for ARP spoofing but it is not nec‐
370 essary to do it. Set the refresh interval only if you are expe‐
371 rienced with some bad or strange behavior of spoofed hosts.
372 Also there is the possibility to test the hosts for successful
373 spoof with the ability to force that spoof - it is recommended
374 to test the ARP spoof if something looks like it is wrong or the
375 computer doesn't send the traffic to the hunt. The force option
376 is handful if the first spoofing packets are discarded with
377 switch so if you are running hunt against hosts on switched
378 ports you can try to run the force mode by example for 10s and
379 then break it with CTRL-C if the spoof continues to fail. The
380 ARP relayer daemon is used to perform ARP relaying of ARP
381 spoofed connections. When you insert some ARP spoof of hosts the
382 ARP spoofing is performed immediately even if the relayer isn't
383 running!!!. But if the ARP spoofing succeeds, the connections
384 will look like they freeze. For rerouting (not IP routing !)
385 these connections through your hunt you need to start the ARP
386 relayer. The relayer works well with ARP/simple hijack so once
387 you have hosts ARP spoofed with ARP relaying you can easily do
388 ARP/simple hijack which will detect that the hosts are already
389 ARP spoofed and takes over the connection immediately. With this
390 technique you can easily become man in the middle from the
391 beginning of the connection even though your host with hunt
392 isn't an IP gateway. I encourage you to write other application
393 specific protocol handlers for the man in the middle attack as
394 it is really simple with this framework.
395
396 Sniff daemon
397 The purpose of the sniff daemon is to log specified packets.
398 The sniff daemon can also search for a simple pattern (string)
399 in the data stream (see the bugs section). You can specify which
400 connection you are interested in, where to search (src, dst,
401 both), what do you want to search, how many bytes you want to
402 log, from what direction (src, dst, both) and to what file
403 should the daemon write. All logged files are stored in the
404 .sniff directory. The default file name for logging is composed
405 of the host and port na,m0es(.asInnetwh-elionpetsioonrsassubhmeexnunuymo.u). can set
406 how to log new lines (
407
408 MAC discovery daemon
409 This daemon is used to collect MAC addresses corresponding to
410 the specified IP range. You can enter the time after which the
411 daemon will try collecting again (default is 5min).
412
413 Host up menu
414 The host up module determines which hosts are up (with TCP/IP
415 stack). You just specify the IP range and that space is then
416 searched for running hosts. It is capable to determine which
417 hosts have network interface in promiscuous mode. The promiscu‐
418 ous mode usually shows that the host is running some kind of
419 sniffer/network analyzer.
420
421 Options menu
422 In the options menu you can tune different things:
423
424 l) a) m) d)
425 List/Add/Mod/Del Connection Policy Entry
426 First of all you can select which connections should be tracked.
427 The default setting is to look at telnet connections from all
428 hosts but you can adjust this behavior by the specification of
429 src/dst address/mask src/dst port pairs. With commands: l) a) m)
430 d) you set what you are interested in.
431
432 c) Connection Listening Properties
433 You can set whether the sequence numbers and MACs of ongoing
434 connections will be displayed during connection listening.
435
436 h) Host Resolving
437 You can turn on resolving of hosts to their names. As the
438 resolving is deferred you don't get the names of hosts immedi‐
439 ately. Just try to list connections several times and you will
440 see the hosts names. (I used this deferred approach because I
441 didn't want any delay of interface that the resolving can
442 cause).
443
444 r) Reset ACK Storm Timeout
445 This timeout is used in simple hijack to automatically reset the
446 connection after the ACK storm is detected. Note that you can
447 receive the ACK storm even in arp/simple hijack in case you
448 don't perform ACK spoofing of any host.
449
450 s) Simple Hijack Timeout For Next cmd
451 Simple hijack has not an interactive connection interface. That
452 means you write the whole command which will be inserted into
453 the connection data stream. If no data is transferred through
454 the connection up to this timeout, you are prompted for the next
455 command.
456
457 q) ARP Request/Reply Packets
458 Number of request or reply packets hunt will send when it is
459 doing arp spoofing.
460
461 t) ARP Request Spoof Through Request
462 Option whether hunt will send ARP spoof request or ARP spoof
463 reply when it receives broadcasted ARP request which will break
464 ARP spoof.
465
466 w) Switched Environment
467 Some optimization for switched environment. It works perfectly
468 for non switched environment also.
469
470 y) ARP Spoof With My MAC
471 Set the originating MAC address of sent spoofed ARP to my (hunt)
472 ethernet MAC - sometimes helps in switched environment.
473
474 e) Learn MAC From IP Traffic
475 You can enable that MAC addresses will be learned from all IP
476 traffic not just from ARP.
477
478 p) Number Of Printed Lines Per Page In Listening
479 Self explanatory
480
481 v) Verbose On/Off
482 Self explanatory
483
485 HUNT program requirements:
486 * Linux >= 2.2
487 * Glibc with linuxthreads
488 * Ethernet
489
490 Tested hosts:
491 Linux 2.0, Linux 2.1, Linux 2.2, Solaris 2.5.1, NT4sp3/4, Win95, OSF
492 V4.0D, HPUX 10.20, IRIX 6.2
493
494 Tested network equipment:
495 BayNetworks 28115, 28200, 300 switches 3Com SuperStack II 3000, 1000
496 switches
497
499 Please note the already known truth that telnet and similar programs
500 which send passwords in clear text are vulnerable to the described
501 attacks. Programs using one time passwords are also easily attacked and
502 in fact they are useless if someone can run a program like hunt. Only
503 full encrypted traffic isn't vulnerable to these attacks but note that
504 you can become a man in the middle if you use ARP spoofing (forcing)
505 without the ACK storm and you can try to do something. Also unconfig‐
506 ured switch doesn't protect you from sniffing or hijacking. It is nec‐
507 essary to carefully configure port security on the switches in order to
508 protect the computers on the switched ports.
509
510 Detecting attacks isn't an easy task. For ARP spoofing there are tools
511 which can detect it. The ACK storm is detectable by some sophisticated
512 network analyzers (you can detect the pattern of the ACK storm or the
513 statistics of ACKs without data). If you run hunt on your network you
514 can detect the ACK storm because the hunt can detect the ACK storm pat‐
515 tern.
516
518 Make sure you are running hunt on idle machine with sufficient power (I
519 used PII-233 with 128MB RAM) and without any other packet analyzer
520 because if you use advanced features like arp spoofing or hijacking
521 hunt needs to reply fast with it's own packets inserted into the traf‐
522 fic on the network.
523
525 This software can be found at http://www.gncz.cz/kra/index.html
526 or at
527 ftp://ftp.gncz.cz/pub/linux/hunt/
528
530 * some structures are poorly locked through mutexes
531 * if you watch connection then some escape sequences from that connec‐
532 tion can influent your terminal. Note that your terminal is named
533 "Linux" ("xterm" - if you run it from X, ...) but the escape sequences
534 are for the client side terminal which may or may not be Linux so you
535 can get some mess.
536 * sniff is not capable to search for a pattern which crosses the packet
537 boundary. That means it can't search for a pattern of the user typed
538 input as this input is usually transferred with 1B data long packets.
539 * hunt doesn't support defragmentation so the IP fragments have to be
540 dropped.
541
543 Please send bug descriptions, patches, suggestions, new modules or suc‐
544 cessful stories to kra@gncz.cz
545
547 I would like to thank Sven Ubik < ubik@fsid.cvut.cz > for his invalu‐
548 able input and feedback.
549
551 Note that this software was written only for my fun in my free time and
552 it was a great exercise of TCP/IP protocols. I am now familiar with
553 seq. numbers, ACKs, timeouts, MACs, checksums, ... to the finest level.
554 As I have some pretty good background this "hunt" challenge made me
555 think that I hadn't known TCP/IP as great as I had thought. You are
556 welcome to read the source code and to try to modify it or write your
557 own modules.
558
560 This manpage was converted from internal documentation by Jon Marler <
561 jmarler@debian.org > for the Debian GNU/Linux operating system.
562
563
564
565 HUNT(1)