--------------------------------------------- From: Peter.Kunz@sega.ch Subject: AW: RedTeam Mailing List 1999-05-08 Date: Mon, 10 May 1999 10:29:06 +0200 I am currently working on a thesis which as a result should include instructions on putting together the necessary "penetration system" as well as instructions on how to go about testing a system. I'd be interested in exachinging info, especially in terms of best practice. The goal is to use publicly available tools to test for the common problems - nothing fancy. cu -pete P.S. An: firewalls@Lists.GNAC.NET Betreff: Hacking Firewalls FYI, a nice little piece. http://www.infowar.co.uk/thc/files/thc/fw-backd.htm [FC - Included below for your convenience] ---------------------------------------------
| Author: van Hauser / THC |
This article describes possible backdoors through different firewall architectures. However, the material can also be applied to other environments to describe how hackers (you?) cover their access to a system.
Hackers often want to retain access to systems they have penetrated even in the face of obstacles such as new firewalls and patched vulnerabilities. To accomplish this the attackers must install a backdoor which a) does it's job and b) is not easily detectable. The kind of backdoor needed depends on the firewall architecture used.
As a gimmick and proof-of-concept, a nice backdoor for any kind of intrusion is included, so have fun.
----[ Firewall Architectures
There are two basic firewall architectures and each has an enhanced version.
Packet Filters:
Stateful Filters:
Proxies / Circuit Level Gateways:
Application Gateways:
Most firewalls that vendors sell on the market are
hybrid firwalls, which means they've got more than just one type
implemented; for example the IBM Firewall is a simple packet filter with
socks and a few proxies. I won't discuss which firewall product is the
best, because this is not a how-to-by-a-firewall paper, but I will say
this: application gateways are by far the most secure firewalls,
although money, speed, special protocols, open network policies,
stupidity, marketing hype and bad management might rule them out.
----[ Getting in
Before we talk about what backdoors are the best for which firewall architecture we should shed a light on how to get through a firewall the first time. Note that getting through a firewall is not a plug-n-play thing for script-kiddies, this has to be carefully planned and done.
The four main possibilities:
Insider:
Vulnerable Services:
Vulnerable External Server:
Hijacking Connections:
Trojans:
----[ Placing the Backdoors
An intelligent hacker will not try to put the backdoors on machines in the firewall segment, because these machines are usually monitored and checked regulary. It's the internal machines which are usually unprotected and without much administration and security checks.
I will now talk about some ideas of backdoors which
could be implemented. Note that programs which will/would run on an
stateful filter will of course work with a normal packet filter too,
same for the proxy. Ideas for an application gateway backdoor will work
for any architecture.
Some of them are "active" and others
"passive". "Active" backdoors are those which can be used by a hacker
anytime he wishes, a "passive" one triggers itself by time/event so an
attacker has to wait for this to happen.
Packet Filters:
Stateful Filters:
Proxies / Circuit Level Gateways:
Application Gateways:
----[ Backdoor Example: The Reverse WWW Shell
This backdoor should work through any firewall which
has got the security policy to allow users to surf the WWW (World Wide
Waste) for information for the sake and profit of the company.
For a
better understanding take a look at the following picture and try to
remember it onwards in the text:
+--------+ +------------+ +-------------+ |internal|--------------------| FIREWALL |--------------|server owned | | host | internal network +------------+ internet |by the hacker| +--------+ +-------------+ SLAVE MASTER
Well, a program is run on the internal host, which spawns a child every day at a special time. For the firewall, this child acts like a user, using his netscape client to surf on the internet. In reality, this child executes a local shell and connects to the www server owned by the hacker on the internet via a legitimate looking http request and sends it ready signal. The legitimate looking answer of the www server owned by the hacker are in reality the commands the child will execute on it's machine it the local shell. All traffic will be converted (I'll not call this "encrypted", I'm not Micro$oft) in a Base64 like structure and given as a value for a cgi-string to prevent caching.
Example of a connection: Slave GET /cgi-bin/order?M5mAejTgZdgYOdgIO0BqFfVYTgjFLdgxEdb1He7krj HTTP/1.0 Master replies with g5mAlfbknz
The GET of the internal host (SLAVE) is just the command prompt of the shell, the answer is an encoded "ls" command from the hacker on the external server (MASTER). Some gimmicks:
The SLAVE tries to connect daily at a specified time to the MASTER if wanted; the child is spawned because if the shell hangs for whatever reason you can check & fix the next day; if an administrator sees connects to the hacker's server and connects to it himself he will just see a broken webserver because there's a Token (Password) in the encoded cgi GET request; WWW Proxies (f.e. squid) are supported; program masks it's name in the process listing ...
Best of all: master & slave program are just one 260-lines perl file ... Usage is simple: edit rwwwshell.pl for the correct values, execute "rwwwshell.pl slave" on the SLAVE, and just run "rwwwshell.pl" on the MASTER just before it's time that the slave tries to connect.
Well, why coding it in perl? a) it was very fast to code, b) it's highly portable and c) I like it. If you want to use it on a system which hasn't got perl installed, search for a similar machine with perl install, get the a3 compiler from the perl CPAN archives and compile it to a binary. Transfer this to your target machine and run that one.
The code for this nice and easy tool is appended in
the section THE CODE after my last words. If you've got
updates/ideas/critics for it drop me an email. If you think this text
or program is lame, write me at root@localhost. Check out http://r3wt.base.org for updates.
----[ The Source
Grab it here ...
Now it's an interesting question how to secure a firewall to deny/detect this. It should be clear that you need a tight application gateway firewall with a strict policy. email should be put on a centralized mail server, and DNS resolving only done on the WWW/FTP proxies and access to WWW only prior proxy authentication. However, this is not enough. An attacker can tamper the mailreader to execute the commands extracted from the crypted X-Headers or implement the http authentication into the reverse www-shell (it's simple). Also checking the DNS and WWW logs/caches regulary with good tools can be defeated by switching the external servers every 3-20 calls or use aliases.
A secure solution would be to set up a second network which is connected to the internet, and the real one kept seperated - but tell this the employees ... A good firewall is a big improvement, and also an Intrusion Detection Systems can help. But nothing can stop a dedicated attacker.
----[ Last Words Have fun hacking/securing the systems ... Greets to all guys who like + know me ;-) and especially to those good chummers I've got, you know who you are. Ciao... van Hauser / [THC] - The Hacker's Choice For further interesting discussions you can email me at vh@reptile.rug.ac.be with my public pgp key blow:
--------------------------------------------- Subject: WG: [ISN] Army to offer 'information survival' training Date: Mon, 10 May 1999 17:31:27 +0200 Perhaps of tangential interest. cu -pete -----Urspr=FCngliche Nachricht----- Von: cult hero [SMTP:jericho@dimensional.com] Gesendet am: Montag, 10. Mai 1999 11:10 An: InfoSec News Betreff: [ISN] Army to offer 'information survival' training=20 http://www.fcw.com/pubs/fcw/1999/0503/web-army-5-5-99.html MAY 5, 1999 . . . 10:48 EDT Army to offer 'information survival' training BY DANIEL VERTON (dan_verton@fcw.com) SALT LAKE CITY -- The Army this fall plans to offer an online graduate-level training course on information systems survivability, teaching engineers to develop systems capable of surviving any kind of technical glitch and network attack. The new 14-week Infosurv course will be offered through the University of Maryland as an online, distance-learning initiative sponsored by the Army Research Laboratory in Adelphi, Md. During the course, students with a basic engineering background will build on their education with instruction on reliability, security and performance risks that must be addressed early in the life cycle of an information system. According to Lt. Col. Paul Walczak, senior computer scientist at the Army Research Laboratory, the concept of Infosurv has been around for about 10 years, growing out of research conducted at the Army Research Laboratory. Survivability, Walczak said, can best be defined as a system's ability to withstand hardware faults, software flaws, network attacks by hackers and electromagnetic interference. When one of these types of failures brings a system or a portion of a system down, the rest of the information infrastructure must be capable of operating, he said. "This is a serious attempt by the Army Research Lab to institutionalize the concept," Walczak said. Until now, reliability, survivability and security have been features that systems developers have "bolted on" after the development process started, he said. The goal is to build these requirements into the system design before development work begins, he said. The Army plans to transmit live courses each Thursday from a lecture room on the College Park, Md., campus to as many as 16 satellite locations. "We plan to beam this course out to as many sites as are interested in it," said Walczak, who noted that the University of Tennessee, Pennsylvania State University and Harvard University also have expressed interest in taking part in future courses. Peter Neumann, principal scientist at the Computer Science Laboratory at SRI International and the principal investigator for Infosurv research, will be the primary instructor for the course. The course will act as the core course in a new four-course masters-level certificate program in survivable systems, and it also can be used as credit toward a regular degree program. ---------------------------------------------