added unreleased README
[oweals/thc-archive.git] / Papers / fw-backd.htm
1 <HTML>\r
2 <HEAD>\r
3 <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">\r
4 <TITLE>Placing Backdoors Through Firewalls\r
5 </TITLE>\r
6 </HEAD>\r
7 <BODY BGCOLOR="#FFFFFF">\r
8 <center>\r
9 <h1>\r
10 ---[  Placing Backdoors Through Firewalls  ]---\r
11 <br>\r
12 v1.5\r
13 </h1>\r
14 <br><br>\r
15 <table border=3 cellpadding=7 cellspacing=3>\r
16 <tr><td>Author: <I><a href="mailto:vh@reptile.rug.ac.be">van Hauser</a> / THC</I><br>\r
17 </td></tr>\r
18 </table>\r
19 </center>\r
20 <br><br><br>\r
21 ----[  Introduction\r
22 <p>\r
23 This article describes possible backdoors through different firewall\r
24 architectures. However, the material can also be applied to other\r
25 environments to describe how hackers (you?) cover their access to a system.\r
26 <p>\r
27 Hackers often want to retain access to systems they have penetrated\r
28 even in the face of obstacles such as new firewalls and patched\r
29 vulnerabilities.  To accomplish this the attackers must install a\r
30 backdoor which a) does it's job and b) is not easily detectable. The\r
31 kind of backdoor needed depends on the firewall architecture used.\r
32 <p>\r
33 As a gimmick and proof-of-concept, a nice backdoor for any kind of\r
34 intrusion is included, so have fun.\r
35 <p>\r
36 <br><br><br>\r
37 ----[  Firewall Architectures\r
38 <p>\r
39 There are two basic firewall architectures and each has an enhanced version.\r
40 <p>\r
41 Packet Filters:<ul><ul>\r
42 This is a host or router which checks each packet against an\r
43 allow/deny ruletable before routing it through the correct\r
44 interface. There are very simple ones which can only filter\r
45 from the origin host, destination host and destination port, as\r
46 well as good ones which can also decide based on incoming interface,\r
47 source port, day/time and some tcp or ip flags.<br>\r
48 This could be a simple router, f.e. any Cisco, or a Linux\r
49 machine with firewalling activated (ipfwadm).\r
50 </ul></ul><p>\r
51 Stateful Filters:\r
52 <ul><ul>        This is the enhanced version of a packet filter. It\r
53 still does the same checking against a rule table and only\r
54 routes if permitted, but it also keeps track of the state\r
55 information such as TCP sequence numbers.  Some pay attention\r
56 to application protocols which allows tricks such as only\r
57 opening ports to the interiour network for ftp-data channels\r
58 which were specified in a permitted ftp session.  These\r
59 filters can (more or less) get UDP packets (f.e. for DNS and\r
60 RPC) securely through the firewall. (Thats because UDP is a\r
61 stateless protocol. And it's more difficult for RPC services.)<br>\r
62 This could be a great OpenBSD machine with the ip-filter software,\r
63 a Cisco Pix, Watchguard, or the (in)famous Checkpoint FW-1.\r
64 </ul></ul><p>\r
65 Proxies / Circuit Level Gateways:\r
66 <ul><ul>        A proxy as a firewall host is simply\r
67 any server which has no routing activated and instead has\r
68 proxy software installe.  <br>Examples of proxy servers which may\r
69 be used are squid for WWW, a sendmail relay configuration\r
70 and/or just a sockd.\r
71 </ul></ul><p>\r
72 Application Gateways:\r
73 <ul><ul>        This is the enhanced version of a proxy. Like a proxy, for every\r
74 application which should get through the firewall a software must\r
75 be installed and running to proxy it. However, the application\r
76 gateway is smart and checks every request and answer, f.e. that\r
77 an outgoing ftp only may download data but not upload any, and that\r
78 the data has got no virus, no buffer overflows are generated in\r
79 answers etc. One can argue that squid is an application\r
80 gateway, because it does many sanity checks and let you filter\r
81 stuff but it was not programmed for the installation in a secure\r
82 environment and still has/had security bugs.<br>\r
83 A good example for a freeware kit for this kind is the TIS firewall\r
84 toolkit (fwtk).\r
85 </ul></ul><p>\r
86 Most firewalls that vendors sell on the market are hybrid firwalls,\r
87 which means they've got more than just one type implemented; for\r
88 example the IBM Firewall is a simple packet filter with socks and a\r
89 few proxies.  I won't discuss which firewall product is the best,\r
90 because this is not a how-to-by-a-firewall paper, but I will say this:\r
91 application gateways are by far the most secure firewalls,\r
92 although money, speed, special protocols, open network policies,\r
93 stupidity, marketing hype and bad management might rule them out.\r
94 \r
95 \r
96 \r
97 <br><br><br>\r
98 ----[  Getting in\r
99 <p>\r
100 Before we talk about what backdoors are the best for which firewall\r
101 architecture we should shed a light on how to get through a firewall\r
102 the first time. Note that getting through a firewall is not a plug-n-play\r
103 thing for script-kiddies, this has to be carefully planned and done.\r
104 <p>\r
105 The four main possibilities:\r
106 <p>\r
107 Insider: \r
108 <ul><ul>        There's someone inside the company (you, girl/boy-friend, chummer)\r
109         who installs the backdoor. This is the easiest way of course.\r
110 </ul></ul><p>\r
111 Vulnerable Services: \r
112 <ul><ul>        Nearly all networks offer some kind of services,\r
113         such as incoming email, WWW, or DNS. These may be on the\r
114         firewall host itself, a host in the DMZ (here: the zone in front\r
115         of the firewall, often not protected by a firewall) or on an internal\r
116         machine. If an attacker can find a hole in one of those services,\r
117         he's got good chances to get in.  You'd laugh if you'd see how many\r
118         "firewalls" run sendmail for mail relaying ...\r
119 </ul></ul><p>\r
120 Vulnerable External Server: \r
121 <ul><ul>        People behind a firewall sometimes work on\r
122         external machines.  If an attacker can hack these, he can\r
123         cause serious mischief such as the many X attacks if the\r
124         victim uses it via an X-relay or sshd.  The attacker could\r
125         also send fake ftp answers\r
126         to overflow a buffer in the ftp client software, replace a gif\r
127         picture on a web server with one which crashs netscape and\r
128         executes a command (I never checked if this actually works, it\r
129         crashs, yeah, but I didn't look through this if this is really\r
130         an exploitable overflow).  There are many possibilities with\r
131         this but it needs some knowledge about the company. However,\r
132         an external web server of the company is usually a good start.\r
133         Some firewalls are configured to allow incoming telnet from\r
134         some machines, so anyone can sniff these and get it. This is\r
135         particulary true for the US, where academic environments and\r
136         industry/military work close together.\r
137 </ul></ul><p>\r
138 Hijacking Connections:\r
139 <ul><ul>        Many companies think that if they allow incoming telnet with\r
140         some kind of secure authentication like SecureID (secure algo?, he)\r
141         they are safe. Anyone can hijack these after the authentication and\r
142         get in ... Another way of using hijacked connections is to modify\r
143         replies in the protocol implementation to generate a buffer\r
144         overflow (f.e. with X).\r
145 </ul></ul><p>\r
146 Trojans:\r
147 <ul><ul>        Many things can be done with a trojan horse.\r
148         This could be a gzip file which generates a buffer overflow\r
149         (well, needs an old gzip to be installed), a tar file which\r
150         tampers f.e. ~/.logout to execute something, or an executable\r
151         or source code which was modified to get the hacker in somehow.\r
152         To get someone running this, mail spoofing could be used or\r
153         replacing originals on an external server which internal employees\r
154         access to update their software regulary (ftp xfer files and www\r
155         logs can be checked to get to know which files these are).\r
156 </ul></ul><p>\r
157 \r
158 \r
159 <br><br><br>\r
160 ----[  Placing the Backdoors\r
161 <p>\r
162 An intelligent hacker will not try to put the backdoors on machines in\r
163 the firewall segment, because these machines are usually monitored and\r
164 checked regulary. It's the internal machines which are usually unprotected\r
165 and without much administration and security checks.\r
166 <p>\r
167 I will now talk about some ideas of backdoors which could be implemented.\r
168 Note that programs which will/would run on an stateful filter will of course\r
169 work with a normal packet filter too, same for the proxy. Ideas for an\r
170 application gateway backdoor will work for any architecture.<br>\r
171 Some of them are "active" and others "passive". "Active" backdoors are those\r
172 which can be used by a hacker anytime he wishes, a "passive" one triggers\r
173 itself by time/event so an attacker has to wait for this to happen.\r
174 <p>\r
175 Packet Filters:\r
176 <ul><ul>        It's hard to find a backdoor which gets through this one but does\r
177         not work for any other. The few ones which comes into my mind<br>\r
178         is a) the ack-telnet. It works like a normal telnet/telnetd except\r
179         it does not work with the normal tcp handshake/protocol but uses\r
180         TCP ACK packets only. Because they look like they belong to an\r
181         already established (and allowed) connection, they are permitted.\r
182         This can be easily coded with the spoofit.h of Coder's Spoofit\r
183         project (<A HREF="http://reptile.rug.ac.be/~coder">http://reptile.rug.ac.be/~coder</A>).<br>\r
184         b) Loki from Phrack 49/51 could be used too to establish a tunnel\r
185         with icmp echo/reply packets. But some coding would be needed to\r
186         to be done.<br>\r
187         c) daemonshell-udp is a backdoor shell via UDP<br>\r
188            (<A HREF="http://www.thc.org">http://www.thc.org</A>  look for thc-uht1.tgz)<br>\r
189         d) Last but not least, most "firewall systems" with only a screening\r
190         router/firewall let any incoming tcp connection from the source port\r
191         20 to a highport (>1023) through to allow the (non-passive) ftp\r
192         protocol to work. "netcat -p 20 target port-of-bindshell" is the\r
193         fastest solution for this one.\r
194 </ul></ul><p>\r
195 Stateful Filters:\r
196 <ul><ul>        Here a hacker must use programs which initiates the connection from\r
197         the secure network to his external 0wned server.\r
198         There are many out there which could be used:<br>\r
199         active:<ul>\r
200                  tunnel from Phrack 52.<br>\r
201                  ssh with the -R option (much better than tunnel ... it's\r
202                  a legtimitate program on a computer and it encrypts the\r
203                  datastream).\r
204 </ul>\r
205         passive:<ul>\r
206                  netcat compiled with the execute option and run with a\r
207                  time option to connect to the hacker machine (<A HREF="ftp://ftp.avian.org">ftp.avian.org</A>).<br>\r
208                  reverse_shell from the thc-uht1.tgz package (see above) does the same.\r
209 </ul></ul><p>\r
210 Proxies / Circuit Level Gateways:\r
211 <ul><ul>        If socks is used on the firewall, someone can use all those stuff\r
212         for the stateful filter and "socksify" them. (<A HREF="www.socks.net.com">www.socks.nec.com</A>)\r
213         For more advanced tools you'd should take a look at the application\r
214         gateway section.\r
215 </ul></ul><p>\r
216 Application Gateways:\r
217 <ul><ul>        Now we get down to the interesting stuff. These beasts can be\r
218         intelligent so some brain is needed.<br>\r
219         active:<ul>\r
220                  (re-)placing a cgi-script on the webserver of the company,\r
221                  which allows remote access. This is unlikely because it's\r
222                  rare that the webserver is in the network, not monitored/\r
223                  checked/audited and accessible from the internet. I hope\r
224                  nobody needs an example on such a thing ;-)<br>\r
225                  (re-placing) a service/binary on the firewall. This is\r
226                  dangerous because those are audited regulary and sometimes\r
227                  even sniffed on permanent ...<br>\r
228                  Loading a loadable module into the firewall kernel wich\r
229                  hides itself and gives access to it's master. The best\r
230                  solution for an active backdoor but still dangerous.\r
231 </ul>\r
232         passive:<ul>\r
233                  E@mail - an email account/mailer/reader is configured in a\r
234                  way to extract hidden commands in an email (X-Headers with\r
235                  weird stuff) and send them back with output if wanted/needed.<br>\r
236                  WWW - this is hard stuff. A daemon on an internal machine\r
237                  does http requests to the internet, but the requests are\r
238                  in real the answers of commands which were issued by a\r
239                  rogue www server in a http reply. This nice and easy beast\r
240                  is presented below (-><A HREF="#example">Backdoor Example: The Reverse WWW Shell</A>)<br>\r
241                  DNS - same concept as above but with dns queries and\r
242                  replies. Disadvantage is that it can not carry much data.\r
243                  (<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
244                  example needs still much coding to be any effective)\r
245 </ul>\r
246 </ul></ul><p>\r
247 \r
248 <br><br><br><A NAME="example"></A>\r
249 ----[  Backdoor Example: The Reverse WWW Shell\r
250 <p>\r
251 This backdoor should work through any firewall which has got the security\r
252 policy to allow users to surf the WWW (World Wide Waste) for information\r
253 for the sake and profit of the company.<br>\r
254 For a better understanding take a look at the following picture and try\r
255 to remember it onwards in the text:\r
256 <pre>\r
257  +--------+                    +------------+              +-------------+\r
258  |internal|--------------------|  FIREWALL  |--------------|server owned |\r
259  |  host  |  internal network  +------------+   internet   |by the hacker|\r
260  +--------+                                                +-------------+\r
261    SLAVE                                                        MASTER\r
262 </pre>\r
263 Well, a program is run on the internal host, which spawns a child every day\r
264 at a special time. For the firewall, this child acts like a user, using his\r
265 netscape client to surf on the internet. In reality, this child executes\r
266 a local shell and connects to the www server owned by the hacker on the\r
267 internet via a legitimate looking http request and sends it ready signal.\r
268 The legitimate looking answer of the www server owned by the hacker are\r
269 in reality the commands the child will execute on it's machine it the\r
270 local shell. All traffic will be converted (I'll not call this "encrypted",\r
271 I'm not Micro$oft) in a Base64 like structure and given as a value for\r
272 a cgi-string to prevent caching.\r
273 <pre>\r
274 Example of a connection:\r
275 \r
276 Slave\r
277 GET /cgi-bin/order?M5mAejTgZdgYOdgIO0BqFfVYTgjFLdgxEdb1He7krj HTTP/1.0\r
278 \r
279 Master replies with\r
280 g5mAlfbknz\r
281 </pre><p>\r
282 The GET of the internal host (SLAVE) is just the command prompt of the\r
283 shell, the answer is an encoded "ls" command from the hacker on the\r
284 external server (MASTER).\r
285 Some gimmicks:<p>\r
286 The SLAVE tries to connect daily at a specified time to the MASTER if\r
287 wanted; the child is spawned because if the shell hangs for whatever\r
288 reason you can check & fix the next day; if an administrator sees connects\r
289 to the hacker's server and connects to it himself he will just see a\r
290 broken webserver because there's a Token (Password) in the encoded\r
291 cgi GET request; WWW Proxies (f.e. squid) are supported; program masks\r
292 it's name in the process listing ...\r
293 <p>\r
294 Best of all: master & slave program are just one 260-lines perl file ...\r
295 Usage is simple: edit rwwwshell.pl for the correct values,\r
296 execute  "rwwwshell.pl slave" on the SLAVE, and just run "rwwwshell.pl"\r
297 on the MASTER just before it's time that the slave tries to connect.\r
298 <p>\r
299 Well, why coding it in perl? a) it was very fast to code, b) it's highly\r
300 portable and c) I like it.\r
301 If you want to use it on a system which hasn't got perl installed, search\r
302 for a similar machine with perl install, get the a3 compiler from the perl\r
303 CPAN archives and compile it to a binary. Transfer this to your target\r
304 machine and run that one.\r
305 <p>\r
306 The code for this nice and easy tool is appended in the section THE CODE\r
307 after my last words. If you've got updates/ideas/critics for it drop me an\r
308 email. If you think this text or program is lame, write me at root@localhost.\r
309 Check out <A HREF="http://www.thc.org">http://www.thc.org</A> for updates.\r
310 <br><br><br>\r
311 ----[  The Source\r
312 <p>\r
313 Grab it here ...<p>\r
314 <ul><A HREF="../releases/rwwwshell-2.0.pl.gz">rwwwshell v2.0</A></ul>\r
315 \r
316 \r
317 <br><br><br>\r
318 ----[  Security\r
319 <p>\r
320 \r
321 Now it's an interesting question how to secure a firewall to deny/detect\r
322 this. It should be clear that you need a tight application gateway firewall\r
323 with a strict policy. email should be put on a centralized mail server,\r
324 and DNS resolving only done on the WWW/FTP proxies and access to WWW only\r
325 prior proxy authentication. However, this is not enough. An attacker can\r
326 tamper the mailreader to execute the commands extracted from the crypted\r
327 X-Headers or implement the http authentication into the reverse www-shell\r
328 (it's simple). Also checking the DNS and WWW logs/caches regulary with good\r
329 tools can be defeated by switching the external servers every 3-20 calls\r
330 or use aliases.\r
331 <p>\r
332 A secure solution would be to set up a second network which is\r
333 connected to the internet, and the real one kept seperated - but tell\r
334 this the employees ...\r
335 A good firewall is a big improvement, and also an Intrusion Detection\r
336 Systems can help. But nothing can stop a dedicated attacker.\r
337 <p>\r
338 \r
339 <PRE>\r
340 \r
341 ----[  Last Words\r
342 \r
343 Have fun hacking/securing the systems ...\r
344 Greets to all guys who like + know me ;-) and especially to those good\r
345 chummers I've got, you know who you are.\r
346 \r
347 Ciao...\r
348                 van Hauser / [THC] - The Hacker's Choice\r
349 \r
350 \r
351 For further interesting discussions you can email me at\r
352 <A HREF="mailto:vh@reptile.rug.be">vh@reptile.rug.ac.be</A> with my public pgp key blow:\r
353 \r
354 Type Bits/KeyID    Date       User ID\r
355 pub  2048/CDD6A571 1998/04/27 van Hauser / THC <vh@reptile.rug.ac.be>\r
356 \r
357 -----BEGIN PGP PUBLIC KEY BLOCK-----\r
358 Version: 2.6.3i\r
359 \r
360 mQENAzVE0A4AAAEIAOzKPhKBDFDyeTvMKQ1xx6781tEdIYgrkrsUEL6VoJ8H8CIU\r
361 SeXDuCVu3JlMKITD6nPMFJ/DT0iKHgnHUZGdCQEk/b1YHUYOcig1DPGsg3WeTX7L\r
362 XL1M4DwqDvPz5QUQ+U+VHuNOUzgxfcjhHsjJj2qorVZ/T5x4k3U960CMJ11eOVNC\r
363 meD/+c6a2FfLZJG0sJ/kIZ9HUkY/dvXDInOJaalQc1mYjkvfcPsSzas4ddiXiDyc\r
364 QcKX+HAXIdmT7bjq5+JS6yspnBvIZC55tB7ci2axTjwpkdzJBZIkCoBlWsDXNwyq\r
365 s70Lo3H9dcaNt4ubz5OMVIvJHFMCEtIGS83WpXEABRG0J3ZhbiBIYXVzZXIgLyBU\r
366 SEMgPHZoQHJlcHRpbGUucnVnLmFjLmJlPokAlQMFEDVE0D7Kb9wCOxiMfQEBvpAD\r
367 /3UCDgJs1CNg/zpLhRuUBlYsZ1kimb9cbB/ufL1I4lYM5WMyw+YfGN0p02oY4pVn\r
368 CQN6ca5OsqeXHWfn7LxBT3lXEPCckd+vb9LPPCzuDPS/zYNOkUXgUQdPo69B04dl\r
369 C9C1YXcZjplYso2q3NYnuc0lu7WVD0qT52snNUDkd19ciQEVAwUQNUTQDhLSBkvN\r
370 1qVxAQGRTwgA05OmurXHVByFcvDaBRMhX6pKbTiVKh8HdJa8IdvuqHOcYFZ2L+xZ\r
371 PAQy2WCqeakvss9Xn9I28/PQZ+6TmqWUmG0qgxe5MwkaXWxszKwRsQ8hH+bcppsZ\r
372 2/Q3BxSfPege4PPwFWsajnymsnmhdVvvrt69grzJDm+iMK0WR33+RvtgjUj+i22X\r
373 lpt5hLHufDatQzukMu4R84M1tbGnUCNF0wICrU4U503yCA4DT/1eMoDXI0BQXmM/\r
374 Ygk9bO2Icy+lw1WPodrWmg4TJhdIgxuYlNLIu6TyqDYxjA/c525cBbdqwoE+YvUI\r
375 o7CN/bJN0bKg1Y/BMTHEK3mpRLLWxVMRYw==\r
376 =MdzX\r
377 -----END PGP PUBLIC KEY BLOCK-----\r
378 </PRE>\r
379 \r
380 ----[  THE END\r
381 </BODY>\r
382 </HTML>\r
383 \r