initial push of all stuff :)
[oweals/thc-archive.git] / Papers / fw-backd.htm
diff --git a/Papers/fw-backd.htm b/Papers/fw-backd.htm
new file mode 100644 (file)
index 0000000..a3c537c
--- /dev/null
@@ -0,0 +1,383 @@
+<HTML>\r
+<HEAD>\r
+<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">\r
+<TITLE>Placing Backdoors Through Firewalls\r
+</TITLE>\r
+</HEAD>\r
+<BODY BGCOLOR="#FFFFFF">\r
+<center>\r
+<h1>\r
+---[  Placing Backdoors Through Firewalls  ]---\r
+<br>\r
+v1.5\r
+</h1>\r
+<br><br>\r
+<table border=3 cellpadding=7 cellspacing=3>\r
+<tr><td>Author: <I><a href="mailto:vh@reptile.rug.ac.be">van Hauser</a> / THC</I><br>\r
+</td></tr>\r
+</table>\r
+</center>\r
+<br><br><br>\r
+----[  Introduction\r
+<p>\r
+This article describes possible backdoors through different firewall\r
+architectures. However, the material can also be applied to other\r
+environments to describe how hackers (you?) cover their access to a system.\r
+<p>\r
+Hackers often want to retain access to systems they have penetrated\r
+even in the face of obstacles such as new firewalls and patched\r
+vulnerabilities.  To accomplish this the attackers must install a\r
+backdoor which a) does it's job and b) is not easily detectable. The\r
+kind of backdoor needed depends on the firewall architecture used.\r
+<p>\r
+As a gimmick and proof-of-concept, a nice backdoor for any kind of\r
+intrusion is included, so have fun.\r
+<p>\r
+<br><br><br>\r
+----[  Firewall Architectures\r
+<p>\r
+There are two basic firewall architectures and each has an enhanced version.\r
+<p>\r
+Packet Filters:<ul><ul>\r
+This is a host or router which checks each packet against an\r
+allow/deny ruletable before routing it through the correct\r
+interface. There are very simple ones which can only filter\r
+from the origin host, destination host and destination port, as\r
+well as good ones which can also decide based on incoming interface,\r
+source port, day/time and some tcp or ip flags.<br>\r
+This could be a simple router, f.e. any Cisco, or a Linux\r
+machine with firewalling activated (ipfwadm).\r
+</ul></ul><p>\r
+Stateful Filters:\r
+<ul><ul>       This is the enhanced version of a packet filter. It\r
+still does the same checking against a rule table and only\r
+routes if permitted, but it also keeps track of the state\r
+information such as TCP sequence numbers.  Some pay attention\r
+to application protocols which allows tricks such as only\r
+opening ports to the interiour network for ftp-data channels\r
+which were specified in a permitted ftp session.  These\r
+filters can (more or less) get UDP packets (f.e. for DNS and\r
+RPC) securely through the firewall. (Thats because UDP is a\r
+stateless protocol. And it's more difficult for RPC services.)<br>\r
+This could be a great OpenBSD machine with the ip-filter software,\r
+a Cisco Pix, Watchguard, or the (in)famous Checkpoint FW-1.\r
+</ul></ul><p>\r
+Proxies / Circuit Level Gateways:\r
+<ul><ul>       A proxy as a firewall host is simply\r
+any server which has no routing activated and instead has\r
+proxy software installe.  <br>Examples of proxy servers which may\r
+be used are squid for WWW, a sendmail relay configuration\r
+and/or just a sockd.\r
+</ul></ul><p>\r
+Application Gateways:\r
+<ul><ul>        This is the enhanced version of a proxy. Like a proxy, for every\r
+application which should get through the firewall a software must\r
+be installed and running to proxy it. However, the application\r
+gateway is smart and checks every request and answer, f.e. that\r
+an outgoing ftp only may download data but not upload any, and that\r
+the data has got no virus, no buffer overflows are generated in\r
+answers etc. One can argue that squid is an application\r
+gateway, because it does many sanity checks and let you filter\r
+stuff but it was not programmed for the installation in a secure\r
+environment and still has/had security bugs.<br>\r
+A good example for a freeware kit for this kind is the TIS firewall\r
+toolkit (fwtk).\r
+</ul></ul><p>\r
+Most firewalls that vendors sell on the market are hybrid firwalls,\r
+which means they've got more than just one type implemented; for\r
+example the IBM Firewall is a simple packet filter with socks and a\r
+few proxies.  I won't discuss which firewall product is the best,\r
+because this is not a how-to-by-a-firewall paper, but I will say this:\r
+application gateways are by far the most secure firewalls,\r
+although money, speed, special protocols, open network policies,\r
+stupidity, marketing hype and bad management might rule them out.\r
+\r
+\r
+\r
+<br><br><br>\r
+----[  Getting in\r
+<p>\r
+Before we talk about what backdoors are the best for which firewall\r
+architecture we should shed a light on how to get through a firewall\r
+the first time. Note that getting through a firewall is not a plug-n-play\r
+thing for script-kiddies, this has to be carefully planned and done.\r
+<p>\r
+The four main possibilities:\r
+<p>\r
+Insider: \r
+<ul><ul>        There's someone inside the company (you, girl/boy-friend, chummer)\r
+        who installs the backdoor. This is the easiest way of course.\r
+</ul></ul><p>\r
+Vulnerable Services: \r
+<ul><ul>        Nearly all networks offer some kind of services,\r
+        such as incoming email, WWW, or DNS. These may be on the\r
+        firewall host itself, a host in the DMZ (here: the zone in front\r
+       of the firewall, often not protected by a firewall) or on an internal\r
+        machine. If an attacker can find a hole in one of those services,\r
+        he's got good chances to get in.  You'd laugh if you'd see how many\r
+        "firewalls" run sendmail for mail relaying ...\r
+</ul></ul><p>\r
+Vulnerable External Server: \r
+<ul><ul>        People behind a firewall sometimes work on\r
+        external machines.  If an attacker can hack these, he can\r
+        cause serious mischief such as the many X attacks if the\r
+        victim uses it via an X-relay or sshd.  The attacker could\r
+        also send fake ftp answers\r
+        to overflow a buffer in the ftp client software, replace a gif\r
+        picture on a web server with one which crashs netscape and\r
+        executes a command (I never checked if this actually works, it\r
+        crashs, yeah, but I didn't look through this if this is really\r
+        an exploitable overflow).  There are many possibilities with\r
+        this but it needs some knowledge about the company. However,\r
+        an external web server of the company is usually a good start.\r
+        Some firewalls are configured to allow incoming telnet from\r
+        some machines, so anyone can sniff these and get it. This is\r
+        particulary true for the US, where academic environments and\r
+        industry/military work close together.\r
+</ul></ul><p>\r
+Hijacking Connections:\r
+<ul><ul>        Many companies think that if they allow incoming telnet with\r
+        some kind of secure authentication like SecureID (secure algo?, he)\r
+        they are safe. Anyone can hijack these after the authentication and\r
+        get in ... Another way of using hijacked connections is to modify\r
+        replies in the protocol implementation to generate a buffer\r
+        overflow (f.e. with X).\r
+</ul></ul><p>\r
+Trojans:\r
+<ul><ul>        Many things can be done with a trojan horse.\r
+        This could be a gzip file which generates a buffer overflow\r
+        (well, needs an old gzip to be installed), a tar file which\r
+        tampers f.e. ~/.logout to execute something, or an executable\r
+        or source code which was modified to get the hacker in somehow.\r
+        To get someone running this, mail spoofing could be used or\r
+        replacing originals on an external server which internal employees\r
+        access to update their software regulary (ftp xfer files and www\r
+        logs can be checked to get to know which files these are).\r
+</ul></ul><p>\r
+\r
+\r
+<br><br><br>\r
+----[  Placing the Backdoors\r
+<p>\r
+An intelligent hacker will not try to put the backdoors on machines in\r
+the firewall segment, because these machines are usually monitored and\r
+checked regulary. It's the internal machines which are usually unprotected\r
+and without much administration and security checks.\r
+<p>\r
+I will now talk about some ideas of backdoors which could be implemented.\r
+Note that programs which will/would run on an stateful filter will of course\r
+work with a normal packet filter too, same for the proxy. Ideas for an\r
+application gateway backdoor will work for any architecture.<br>\r
+Some of them are "active" and others "passive". "Active" backdoors are those\r
+which can be used by a hacker anytime he wishes, a "passive" one triggers\r
+itself by time/event so an attacker has to wait for this to happen.\r
+<p>\r
+Packet Filters:\r
+<ul><ul>        It's hard to find a backdoor which gets through this one but does\r
+        not work for any other. The few ones which comes into my mind<br>\r
+        is a) the ack-telnet. It works like a normal telnet/telnetd except\r
+        it does not work with the normal tcp handshake/protocol but uses\r
+        TCP ACK packets only. Because they look like they belong to an\r
+        already established (and allowed) connection, they are permitted.\r
+        This can be easily coded with the spoofit.h of Coder's Spoofit\r
+        project (<A HREF="http://reptile.rug.ac.be/~coder">http://reptile.rug.ac.be/~coder</A>).<br>\r
+        b) Loki from Phrack 49/51 could be used too to establish a tunnel\r
+        with icmp echo/reply packets. But some coding would be needed to\r
+        to be done.<br>\r
+        c) daemonshell-udp is a backdoor shell via UDP<br>\r
+           (<A HREF="http://www.thc.org">http://www.thc.org</A>  look for thc-uht1.tgz)<br>\r
+        d) Last but not least, most "firewall systems" with only a screening\r
+        router/firewall let any incoming tcp connection from the source port\r
+        20 to a highport (>1023) through to allow the (non-passive) ftp\r
+        protocol to work. "netcat -p 20 target port-of-bindshell" is the\r
+        fastest solution for this one.\r
+</ul></ul><p>\r
+Stateful Filters:\r
+<ul><ul>        Here a hacker must use programs which initiates the connection from\r
+        the secure network to his external 0wned server.\r
+        There are many out there which could be used:<br>\r
+        active:<ul>\r
+                tunnel from Phrack 52.<br>\r
+                 ssh with the -R option (much better than tunnel ... it's\r
+                 a legtimitate program on a computer and it encrypts the\r
+                 datastream).\r
+</ul>\r
+        passive:<ul>\r
+                netcat compiled with the execute option and run with a\r
+                 time option to connect to the hacker machine (<A HREF="ftp://ftp.avian.org">ftp.avian.org</A>).<br>\r
+                 reverse_shell from the thc-uht1.tgz package (see above) does the same.\r
+</ul></ul><p>\r
+Proxies / Circuit Level Gateways:\r
+<ul><ul>        If socks is used on the firewall, someone can use all those stuff\r
+        for the stateful filter and "socksify" them. (<A HREF="www.socks.net.com">www.socks.nec.com</A>)\r
+        For more advanced tools you'd should take a look at the application\r
+        gateway section.\r
+</ul></ul><p>\r
+Application Gateways:\r
+<ul><ul>        Now we get down to the interesting stuff. These beasts can be\r
+        intelligent so some brain is needed.<br>\r
+        active:<ul>\r
+                (re-)placing a cgi-script on the webserver of the company,\r
+                 which allows remote access. This is unlikely because it's\r
+                 rare that the webserver is in the network, not monitored/\r
+                 checked/audited and accessible from the internet. I hope\r
+                 nobody needs an example on such a thing ;-)<br>\r
+                 (re-placing) a service/binary on the firewall. This is\r
+                 dangerous because those are audited regulary and sometimes\r
+                 even sniffed on permanent ...<br>\r
+                 Loading a loadable module into the firewall kernel wich\r
+                 hides itself and gives access to it's master. The best\r
+                 solution for an active backdoor but still dangerous.\r
+</ul>\r
+        passive:<ul>\r
+                E@mail - an email account/mailer/reader is configured in a\r
+                 way to extract hidden commands in an email (X-Headers with\r
+                 weird stuff) and send them back with output if wanted/needed.<br>\r
+                 WWW - this is hard stuff. A daemon on an internal machine\r
+                 does http requests to the internet, but the requests are\r
+                 in real the answers of commands which were issued by a\r
+                 rogue www server in a http reply. This nice and easy beast\r
+                 is presented below (-><A HREF="#example">Backdoor Example: The Reverse WWW Shell</A>)<br>\r
+                 DNS - same concept as above but with dns queries and\r
+                 replies. Disadvantage is that it can not carry much data.\r
+                 (<A HREF="http://www.icon.co.za/~wosp/wosp.dns-tunnel.tar.gz">http://www.icon.co.za/~wosp/wosp.dns-tunnel.tar.gz</A>, this\r
+                 example needs still much coding to be any effective)\r
+</ul>\r
+</ul></ul><p>\r
+\r
+<br><br><br><A NAME="example"></A>\r
+----[  Backdoor Example: The Reverse WWW Shell\r
+<p>\r
+This backdoor should work through any firewall which has got the security\r
+policy to allow users to surf the WWW (World Wide Waste) for information\r
+for the sake and profit of the company.<br>\r
+For a better understanding take a look at the following picture and try\r
+to remember it onwards in the text:\r
+<pre>\r
+ +--------+                    +------------+              +-------------+\r
+ |internal|--------------------|  FIREWALL  |--------------|server owned |\r
+ |  host  |  internal network  +------------+   internet   |by the hacker|\r
+ +--------+                                                +-------------+\r
+   SLAVE                                                        MASTER\r
+</pre>\r
+Well, a program is run on the internal host, which spawns a child every day\r
+at a special time. For the firewall, this child acts like a user, using his\r
+netscape client to surf on the internet. In reality, this child executes\r
+a local shell and connects to the www server owned by the hacker on the\r
+internet via a legitimate looking http request and sends it ready signal.\r
+The legitimate looking answer of the www server owned by the hacker are\r
+in reality the commands the child will execute on it's machine it the\r
+local shell. All traffic will be converted (I'll not call this "encrypted",\r
+I'm not Micro$oft) in a Base64 like structure and given as a value for\r
+a cgi-string to prevent caching.\r
+<pre>\r
+Example of a connection:\r
+\r
+Slave\r
+GET /cgi-bin/order?M5mAejTgZdgYOdgIO0BqFfVYTgjFLdgxEdb1He7krj HTTP/1.0\r
+\r
+Master replies with\r
+g5mAlfbknz\r
+</pre><p>\r
+The GET of the internal host (SLAVE) is just the command prompt of the\r
+shell, the answer is an encoded "ls" command from the hacker on the\r
+external server (MASTER).\r
+Some gimmicks:<p>\r
+The SLAVE tries to connect daily at a specified time to the MASTER if\r
+wanted; the child is spawned because if the shell hangs for whatever\r
+reason you can check & fix the next day; if an administrator sees connects\r
+to the hacker's server and connects to it himself he will just see a\r
+broken webserver because there's a Token (Password) in the encoded\r
+cgi GET request; WWW Proxies (f.e. squid) are supported; program masks\r
+it's name in the process listing ...\r
+<p>\r
+Best of all: master & slave program are just one 260-lines perl file ...\r
+Usage is simple: edit rwwwshell.pl for the correct values,\r
+execute  "rwwwshell.pl slave" on the SLAVE, and just run "rwwwshell.pl"\r
+on the MASTER just before it's time that the slave tries to connect.\r
+<p>\r
+Well, why coding it in perl? a) it was very fast to code, b) it's highly\r
+portable and c) I like it.\r
+If you want to use it on a system which hasn't got perl installed, search\r
+for a similar machine with perl install, get the a3 compiler from the perl\r
+CPAN archives and compile it to a binary. Transfer this to your target\r
+machine and run that one.\r
+<p>\r
+The code for this nice and easy tool is appended in the section THE CODE\r
+after my last words. If you've got updates/ideas/critics for it drop me an\r
+email. If you think this text or program is lame, write me at root@localhost.\r
+Check out <A HREF="http://www.thc.org">http://www.thc.org</A> for updates.\r
+<br><br><br>\r
+----[  The Source\r
+<p>\r
+Grab it here ...<p>\r
+<ul><A HREF="../releases/rwwwshell-2.0.pl.gz">rwwwshell v2.0</A></ul>\r
+\r
+\r
+<br><br><br>\r
+----[  Security\r
+<p>\r
+\r
+Now it's an interesting question how to secure a firewall to deny/detect\r
+this. It should be clear that you need a tight application gateway firewall\r
+with a strict policy. email should be put on a centralized mail server,\r
+and DNS resolving only done on the WWW/FTP proxies and access to WWW only\r
+prior proxy authentication. However, this is not enough. An attacker can\r
+tamper the mailreader to execute the commands extracted from the crypted\r
+X-Headers or implement the http authentication into the reverse www-shell\r
+(it's simple). Also checking the DNS and WWW logs/caches regulary with good\r
+tools can be defeated by switching the external servers every 3-20 calls\r
+or use aliases.\r
+<p>\r
+A secure solution would be to set up a second network which is\r
+connected to the internet, and the real one kept seperated - but tell\r
+this the employees ...\r
+A good firewall is a big improvement, and also an Intrusion Detection\r
+Systems can help. But nothing can stop a dedicated attacker.\r
+<p>\r
+\r
+<PRE>\r
+\r
+----[  Last Words\r
+\r
+Have fun hacking/securing the systems ...\r
+Greets to all guys who like + know me ;-) and especially to those good\r
+chummers I've got, you know who you are.\r
+\r
+Ciao...\r
+                van Hauser / [THC] - The Hacker's Choice\r
+\r
+\r
+For further interesting discussions you can email me at\r
+<A HREF="mailto:vh@reptile.rug.be">vh@reptile.rug.ac.be</A> with my public pgp key blow:\r
+\r
+Type Bits/KeyID    Date       User ID\r
+pub  2048/CDD6A571 1998/04/27 van Hauser / THC <vh@reptile.rug.ac.be>\r
+\r
+-----BEGIN PGP PUBLIC KEY BLOCK-----\r
+Version: 2.6.3i\r
+\r
+mQENAzVE0A4AAAEIAOzKPhKBDFDyeTvMKQ1xx6781tEdIYgrkrsUEL6VoJ8H8CIU\r
+SeXDuCVu3JlMKITD6nPMFJ/DT0iKHgnHUZGdCQEk/b1YHUYOcig1DPGsg3WeTX7L\r
+XL1M4DwqDvPz5QUQ+U+VHuNOUzgxfcjhHsjJj2qorVZ/T5x4k3U960CMJ11eOVNC\r
+meD/+c6a2FfLZJG0sJ/kIZ9HUkY/dvXDInOJaalQc1mYjkvfcPsSzas4ddiXiDyc\r
+QcKX+HAXIdmT7bjq5+JS6yspnBvIZC55tB7ci2axTjwpkdzJBZIkCoBlWsDXNwyq\r
+s70Lo3H9dcaNt4ubz5OMVIvJHFMCEtIGS83WpXEABRG0J3ZhbiBIYXVzZXIgLyBU\r
+SEMgPHZoQHJlcHRpbGUucnVnLmFjLmJlPokAlQMFEDVE0D7Kb9wCOxiMfQEBvpAD\r
+/3UCDgJs1CNg/zpLhRuUBlYsZ1kimb9cbB/ufL1I4lYM5WMyw+YfGN0p02oY4pVn\r
+CQN6ca5OsqeXHWfn7LxBT3lXEPCckd+vb9LPPCzuDPS/zYNOkUXgUQdPo69B04dl\r
+C9C1YXcZjplYso2q3NYnuc0lu7WVD0qT52snNUDkd19ciQEVAwUQNUTQDhLSBkvN\r
+1qVxAQGRTwgA05OmurXHVByFcvDaBRMhX6pKbTiVKh8HdJa8IdvuqHOcYFZ2L+xZ\r
+PAQy2WCqeakvss9Xn9I28/PQZ+6TmqWUmG0qgxe5MwkaXWxszKwRsQ8hH+bcppsZ\r
+2/Q3BxSfPege4PPwFWsajnymsnmhdVvvrt69grzJDm+iMK0WR33+RvtgjUj+i22X\r
+lpt5hLHufDatQzukMu4R84M1tbGnUCNF0wICrU4U503yCA4DT/1eMoDXI0BQXmM/\r
+Ygk9bO2Icy+lw1WPodrWmg4TJhdIgxuYlNLIu6TyqDYxjA/c525cBbdqwoE+YvUI\r
+o7CN/bJN0bKg1Y/BMTHEK3mpRLLWxVMRYw==\r
+=MdzX\r
+-----END PGP PUBLIC KEY BLOCK-----\r
+</PRE>\r
+\r
+----[  THE END\r
+</BODY>\r
+</HTML>\r
+\r