Merge remote-tracking branch 'upstream/master'

cats/ncat.md

@@ -0,0 +1,23 @@
+# Ncat Usage
+
+`ncat` similar to the venerable `netcat`, is a command-line or shell application that can be used for a wide variety of exploitation matters including transferring files, establishing remote shells and more! The official ncat site is http://nmap.org/ncat/.
+
+The examples below are mostly copied from the http://nmap.org/book/ncat-man-examples.html page or http://www.irongeek.com/i.php?page=videos/ncat-nmap-netcat and are not a complete listing of all the examples.
+
+## Commands
+| Command  | Description / Importance |
+| -------- | ------------------------ |
+| `ncat example.org 8080` | Connect to example.org on TCP port 8080. |
+| `ncat -l 8080` | Listen for connections on TCP port 8080. |
+| `ncat --sh-exec "ncat example.org 80" -l 8080 --keep-open` | Redirect TCP port 8080 on the local machine to host on port 80. |
+| `ncat --exec "/bin/bash" -l 8081 --keep-open` | Bind to TCP port 8081 and attach /bin/bash for the world to access freely. |
+| `ncat --exec "/bin/bash" --max-conns 3 --allow \`<br>`192.168.0.0/24 -l 8081 --keep-open` | Bind a shell to TCP port 8081, limit access to hosts on a local network, and limit the maximum number of simultaneous connections to 3. |
+| `ncat -l --proxy-type http localhost 8888` | Create an HTTP proxy server on localhost port 8888. |
+| `Server: ncat ClientIP 9899 < inputfile`<br>`Client: ncat -l 9899 > outputfile` | Send a file over TCP port 9899 from Server to Client. Server "pushes" the file to the Client. |
+| `Server: ncat -l 9899 < inputfile`<br>`Client: ncat ServerIP 9899 > outputfile` | Transfer in the other direction, turning Ncat into a "one file" server. Client "pulls" file from the Server. |
+| `echo -e "GET / HTTP/1.0\n\n"`&#124;`ncat google.com 80` | Retrieve the HTML source code of the web server at google.com on TCP port 80. |
+| `ncat -t example.org 23` | Connect to example.org's telnet server on TCP port 23. |
+| `Server: ncat -l 74 --udp`<br>`Client: ncat --udp localhost 74 < inputfile` | Transfer file from client to server over UDP. |
+| `Server: ncat -l 74 --chat`<br>`Client1: ncat localhost 74`<br>`Client2: ncat localhost 74`| Simple chat. |
+| `Server: ncat -l --ssl 74 --send-only < inputfile`<br>`Client: ncat localhost 74 --ssl > outputfile` | Transfer file from server to client using SSL encryption. | 
+| `ncat -l localhost 80 --sh-exec "ncat google.com 80 -o text.txt -x hex.txt"` | Ncat relay |

cats/socat.md

@@ -0,0 +1,31 @@
+# socat Usage
+
+`socat` or SOcket CAT, similar to the venerable `netcat`, is a command-line or shell application that can be used for a wide variety of exploitation matters including transferring files, establishing remote shells, SSL transport, IPv6 networking and more! The official socat site is http://www.dest-unreach.org/socat/.
+
+An important piece to understand about `socat` is that the format of the command is: `socat [options] <address> <address>` where `<address>` is in a special format. Check out the docs here http://www.dest-unreach.org/socat/doc/socat.html#ADDRESS_TYPES for more information. 
+
+The examples below are mostly copied from the http://www.dest-unreach.org/socat/doc/socat.html#EXAMPLES page or http://stuff.mit.edu/afs/sipb/machine/penguin-lust/src/socat-1.7.1.2/EXAMPLES and are not a complete listing of all the examples.
+
+## Commands
+| Command  | Description / Importance |
+| -------- | ------------------------ |
+| `socat - TCP4:www.domain.org:80` | Transfers data between STDIO (-) and a TCP4 connection to port 80 of host www.domain.org. This example results in an interactive connection similar to telnet or netcat. The stdin terminal parameters are not changed, so you may close the relay with ^D or abort it with ^C. |
+| `socat -d -d READLINE,history=$HOME/.http_history \`<br>`TCP4:www.domain.org:www,crnl` | This is similar to the previous example, but you can edit the current line in a bash like manner (READLINE) and use the history file .http_history; socat prints messages about progress (-d -d). The port is specified by service name (www), and correct network line termination characters (crnl) instead of NL are used. |
+| `socat TCP4-LISTEN:www TCP4:www.domain.org:www` | Installs a simple TCP port forwarder. With TCP4-LISTEN it listens on local port "www" until a connection comes in, accepts it, then connects to the remote host (TCP4) and starts data transfer. It will not accept a second connection. |
+| `socat -d -d -lmlocal2 TCP4-LISTEN:80,bind=myaddr1, \`<br>`su=nobody,fork,range=10.0.0.0/8,reuseaddr  \`<br>`TCP4:www.domain.org:80,bind=myaddr2` | TCP port forwarder, each side bound to another local IP address (bind). This example handles an almost arbitrary number of parallel or consecutive connections by fork'ing a new process after each accept() . It provides a little security by su'ing to user nobody after forking; it only permits connections from the private 10 network (range); due to reuseaddr, it allows immediate restart after master process's termination, even if some child sockets are not completely shut down. With -lmlocal2, socat logs to stderr until successfully reaching the accept loop. Further logging is directed to syslog with facility local2. |
+| `socat TCP4-LISTEN:5555,fork,tcpwrap=script \`<br>`EXEC:/bin/myscript,chroot=/home/sandbox,su-d=sandbox,pty,stderr` | A simple server that accepts connections (TCP4-LISTEN) and fork's a new child process for each connection; every child acts as single relay. The client must match the rules for daemon process name "script" in /etc/hosts.allow and /etc/hosts.deny, otherwise it is refused access (see "man 5 hosts_access"). For EXEC'uting the program, the child process chroot's to /home/sandbox, su's to user sandbox, and then starts the program /home/sandbox/bin/myscript. Socat and myscript communicate via a pseudo tty (pty); myscript's stderr is redirected to stdout, so its error messages are transferred via socat to the connected client. |
+| `socat EXEC:"mail.sh target@domain.com",fdin=3,fdout=4 \`<br>`TCP4:mail.relay.org:25,crnl,bind=alias1.server.org,mss=512` | mail.sh is a shell script, distributed with socat, that implements a simple SMTP client. It is programmed to "speak" SMTP on its FDs 3 (in) and 4 (out). The fdin and fdout options tell socat to use these FDs for communication with the program. Because mail.sh inherits stdin and stdout while socat does not use them, the script can read a mail body from stdin. Socat makes alias1 your local source address (bind), cares for correct network line termination (crnl) and sends at most 512 data bytes per packet (mss). |
+| `socat -,raw,echo=0,escape=0x0f /dev/ttyS0,raw,echo=0,crnl` | Opens an interactive connection via the serial line, e.g. for talking with a modem. Raw and echo set the console's and ttyS0's terminal parameters to practicable values, crnl converts to correct newline characters. Escape allows to terminate the socat process with character control-O. Consider using READLINE instead of the first address. |
+| `socat UNIX-LISTEN:/tmp/.X11-unix/X1,fork \`<br>`SOCKS4:host.victim.org:127.0.0.1:6000,socksuser=nobody,sourceport=20` | With UNIX-LISTEN, socat opens a listening UNIX domain socket /tmp/.X11-unix/X1. This path corresponds to local XWindow display :1 on your machine, so XWindow client connections to DISPLAY=:1 are accepted. Socat then speaks with the SOCKS4 server host.victim.org that might permit sourceport 20 based connections due to an FTP related weakness in its static IP filters. Socat pretends to be invoked by socksuser nobody, and requests to be connected to loopback port 6000 (only weak sockd configurations will allow this). So we get a connection to the victims XWindow server and, if it does not require MIT cookies or Kerberos authentication, we can start work. Please note that there can only be one connection at a time, because TCP can establish only one session with a given set of addresses and ports. |
+| `socat -u /tmp/readdata,seek-end=0,ignoreeof -` | This is an example for unidirectional data transfer (-u). Socat transfers data from file /tmp/readdata (implicit address GOPEN), starting at its current end (seek-end=0 lets socat start reading at current end of file; use seek=0 or no seek option to first read the existing data) in a "tail -f" like mode (ignoreeof). The "file" might also be a listening UNIX domain socket (do not use a seek option then). | 
+| `(sleep 5; echo PASSWORD; sleep 5; echo ls; sleep 1)` &#124; <br>`socat - EXEC:'ssh -l user server',pty,setsid,ctty` | EXEC'utes an ssh session to server. Uses a pty for communication between socat and ssh, makes it ssh's controlling tty (ctty), and makes this pty the owner of a new process group (setsid), so ssh accepts the password from socat. |
+| `socat -u TCP4-LISTEN:3334,reuseaddr,fork \`<br>`OPEN:/tmp/in.log,creat,append` | Implements a simple network based message collector. For each client connecting to port 3334, a new child process is generated (option fork). All data sent by the clients are appended to the file /tmp/in.log. If the file does not exist, socat creates it. Option reuseaddr allows immediate restart of the server process. |
+| `socat READLINE,noecho='[Pp]assword:' \`<br>`EXEC:'ftp ftp.server.com',pty,setsid,ctty` | Wraps a command line history (READLINE) around the EXEC'uted ftp client utility. This allows editing and reuse of FTP commands for relatively comfortable browsing through the ftp directory hierarchy. The password is echoed! pty is required to have ftp issue a prompt. Nevertheless, there may occur some confusion with the password and FTP prompts. |
+| `socat TCP4-LISTEN:2022,reuseaddr,fork \`<br>`PROXY:proxy:www.domain.org:22,proxyport=3128,proxyauth=user:pass` | Starts a forwarder that accepts connections on port 2022, and directs them through the proxy daemon listening on port 3128 (proxyport) on host proxy, using the CONNECT method, where they are authenticated as "user" with "pass" (proxyauth). The proxy should establish connections to host www.domain.org on port 22 then. |
+| `socat - SSL:server:4443,cafile=server.crt,cert=client.pem` | An OpenSSL client that tries to establish a secure connection to an SSL server. Option cafile specifies a file that contains trust certificates: we trust the server only when it presents one of these certificates and proofs that it owns the related private key. Otherwise the connection is terminated. With cert a file containing the client certificate and the associated private key is specified. This is required in case the server wishes a client authentication; many Internet servers do not. The first address ('-') can be replaced by almost any other socat address. | 
+| `socat SSL-LISTEN:4443,reuseaddr,pf=ip4,fork,\`<br>`cert=server.pem,cafile=client.crt PIPE` | An OpenSSL server that accepts TCP connections, presents the certificate from the file server.pem and forces the client to present a certificate that is verified against cafile.crt. The second address ('PIPE') can be replaced by almost any other socat address. For instructions on generating and distributing OpenSSL keys and certificates see the additional socat document socat-openssl.txt. |
+| `socat tcp-l:7777,reuseaddr,fork system:'filan -i 0 -s >&2',nofork` | Listens for incoming TCP connections on port 7777. For each accepted connection, invokes a shell. This shell has its stdin and stdout directly connected to the TCP socket (nofork). The shell starts filan and lets it print the socket addresses to stderr (your terminal window). |
+| `socat - tcp:www.blackhat.org:31337,readbytes=1000` | Connects to an unknown service and prevents being flooded. |
+| `socat TCP:host2:4443 TUN:192.168.255.1/24,up` | Establishes one side of a virtual (but not private!) network with host2 where a similar process might run, with UDP-L and tun address 192.168.255.2. They can reach each other using the addresses 192.168.255.1 and 192.168.255.2. Note that streaming eg. via TCP or SSL does not guarantee to retain packet boundaries and may thus cause packet loss. |
+| `socat TCP-LISTEN:80,reuseaddr,fork,su=nobody \`<br>`TCP:www.dmz.mydomain.org:80` | Relay TCP port 80 from everywhere (internet, intranet, dmz) through your firewall to your DMZ webserver (like plug-gw) listen on port 80; whenever a connection is made, fork a new process (parent process keeps accepting connections), su to nobody, and connect to  www.dmz.mydomain.org on port 80. Attention: this is a substitute for a reverse proxy without providing application level security. |
+| `socat -lm -d -d TCP-LISTEN:25,bind=fw.dmz.mydomain.org, \`<br>`fork,su=nobody,range=smtp.dmz.mydomain.org/32 \`<br>`TCP:smtp.intra.mydomain.org:25` | Relay mail from your DMZ server through your firewall. Accept connections only on dmz interface and allow connections only from smtp.dmz.mydomain.org. The advantages over plug-gw and other relays are: * you can bind to an IP address (even an alias), therefore enhance security * in your OS you can create several IP aliases and bind another socat daemon to each, making several application servers addressable * lots of options, like switching user, chroot, IP performance tuning * no need for inetd. |

navigation.md

@@ -57,7 +57,9 @@
 
 [Cats]()
 
+  * [ncat](cats/ncat.md)
   * [netcat](cats/netcat.md)
+  * [socat](cats/socat.md)
   
 [Metasploit]()