- HACKING UNIX - PART ONE: Vulnerabilities in Network Software ----------------------------------- Completed on 10-17-01 (MM-DD-YY) By: XT - [DuHo] & ** This is a multi-part tutorial, & ** please check our website for other & ** parts: & ** http://duho.cjb.net & & Next part, soon to come out (as of 10-17-01): & => System Profiling Unices & & AND MORE TO COME! ****** INDEX: 0. - Forword 1. - Audience 2. - Introduction 3. - Known Vulnerabilities 3.1 - Full Disclosure 3.1.1 Advantages & Disadvantages 3.2 - Exploit Code 3.3 - 'Access Levels' and 'Environments' and 'Security' 4. - Where do vulnerabilities occur? 5. - Who finds vulnerabilities 6. - Last words **************************************************************** 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 these tutorials are outdated and irrelevant, but i think it's not bad to read them afterall, because this is oldskool hacking which is always fun-reading. Also take a look in the phrack archives (www.phrack.org) in the old issues, for a look in the past. I first 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 in network software' 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. Ever tried 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. So let's get started right away: 2. Introduction In a nutshell these are the steps the hacker takes: A hacker first searches a system that he interested in, then 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 yourself in the configuration of a system and exploiting them. Another way to break into a system is to use known vulnerabilities in the network applications. Network applications are services like HTTP and FTP. If you don't know what these are, search for them on www.google.com. } In this first part of the tutorial I introduce you to known vulnerabilities. In later parts I'll introduce the rest that involves hacking. 3. Known vulnerabilities If there are vulnerabilities known in a server application like the apache webserver (HTTP server) then these are dependent on the version that is used => When a vulnerability is *known*, the vendor (like the Apache project) will fix it in the next release and/or a patch is released and then the vulnerability (rather bug) is corrected. { - A hacker searches for services running on a server and check what program and what version number delivers the service and then find information about vulnerabilities in the particular program. -A security concious administrator will keep track of these vulnerabilities (bugs) and will apply fixes immediately so that they won't be vulnerable anymore. } The chances of succesfully abusing a known vulnerability depends on the degree of detail that the founder of the problem has disclosed in his publication of the problem. 3.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. } 3.1.1 Advantages and Disadvantages The full-disclosure method has advantages and disadvantages for security. Full-disclosure articles explain the details of a vulnerability in the degree that the exploitation state is reproducable. Disadvantages of Full-Disclosure: This is a disadvantage for security as many administrators do not care about vulnerabilities in software they use and 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 because if a certain type of vulnerability is found multiple times this will get the vendor a bad name (Microsoft is one ;-). 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. 3.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. 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. Hackers must seek full-privilege to a server so that logtraces can be removed and stuff like that. 3.3 'Access Levels' and 'Environments' and 'Security' When a hacker gains access to a system via a vulnerable network service, this doesn't mean that the hacker will have instant full privileged access to the system. Most network service programs do not require full system access for their tasks so they are preferred to have low-privileges. Privileges ofcourse involve access control rights on files, network resources, memory access, system calls etc. *I will call this the program's (or users') 'environment' throughout the rest of the tutorial. But you ask; well, what can a hacker get by 'exploiting' a network service? Well, the hacker will gain more access to a system than a network service tends to provide (the environment that the service creates for the client). { --> With this statement you should understand that a network service is there to provide resources available on the system, but not all the resources that are in it's own environment. For example, when you have anonymous access to an FTP archive you will not be able to see other parts of the file system that the server holds. Well, if you are able to break into the system through a vulnerability in that FTP program, you will get the full privileges that the FTP program has (but simply not provides to it's users). When you broke into the FTP programs' complete environment you can read all files that are readable by the FTP program, you may be able to read password lists and you name it. Sometimes you may be able to produce an exploit state where you will have local shell access to the system, and you will be able to run programs installed locally on the remote server. This way you can search for other holes in programs with more privilege (or even full-privilege) that are installed locally on the server. } So you should have noticed that security is all about evaluating what privileges a program or user needs (and not needs). { Actually, if you want to secure a FTP service to the limit, you should only give access to the files it has to read. But this approach is not very flexible when you want to deliver an operating system with FTP service which has numerous possible configurations. So this is why vendors just give the FTP service access to all files the program would possibly need to read. So a very paranoid administrator will deny access to everything that he thinks the FTP program would not need. This can be done using chroot() environments, but I think I will explain this in part 3, which will be 'insecure configuration' or something. } You could think of an environment where an object resides: The operating system virtually creates an environment and makes sure the program is unable to break out of an environment and enter another environment. Well, the operating system controls only the program's environment and users's environment. But a service program needs to set build-in restrictions to make a solid environment for client programs that use the service. { 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, namely 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. We will be able to exploit higher-privileged processes (programs) within the system through known vulnerabilities. Vulnerabilities like race conditions, format string bugs, administrator's configuration mistakes, buffer and heap overflows, symbolic link problems. We might get access to userlists which we can use to hack into a users' account, stuff like that. We will get to all these elements later in this tutorial. } 4. Where do vulnerabilities occur? Basically i think that all vulnerabilities occur in (to list some): - input handling - configuration stupidity's - 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 vulnerabilities. { Hackers search for ways to make a system do things it was not supposed to do. A system can be anything: a program, a user (person), a protocol. } A hacker will examine a program on how it works. And while he reverse engineers a program he will try to understand what procedures a program could take and he will investigate whether these methods are secure. Like handling input, but also where a program relies on and what in the program relies on something else and is that 'something else' secure... etc. It is a bit hard to explain this to you, but you will understand this by reading typical security advisories. Here's such a report on a security problem so you can see what i mean: ------------------------------------------------------------------------------ Date: Thu, 20 Sep 2001 21:48:34 +0200 From: "Przemyslaw Frasunek"  Subject: Local vulnerability in libutil derived with FreeBSD 4.4-RC (and earlier) Organization: babcia padlina ltd. To:   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: http://www.freebsd.org/cgi/cvsweb.cgi/~checkout~/src/lib/libutil/login_cap.c?rev=1.17.2.3&content-type=text/plain Official advisory is pending. It's possible, that other *BSD systems, supporting login capability database are also vulnerable. -- * Fido: 2:480/124 ** WWW: http://www.frasunek.com/ ** NIC-HDL: PMF9-RIPE * * Inet: przemyslaw@frasunek.com ** PGP: D48684904685DF43EA93AFA13BE170BF * ------------------------------------------------------------------------------ I don't expect you to understand this advisory, to be fair; i don't even understand all of it: Never heard of OpenSSH's login class capability dbase -- guess it has to do with permissions to users which are set in a database. 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 (full-system-access) you can place any file name in the .login_conf, and it will be displayed! This means you can read the master.passwd file where the password-hashes for all users are stored. { This file is normally not readable for a 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 cracked the root password. *BUT* 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. I think the subject of cryptography will be explained in part 4 of this guide. } Note that the hacker had first informed the vendor FreeBSD which created a patch. After the patch was finished, 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 provided. There are also people that don't report bugs to vendors and the public and use their information for their own sake. I suspect governments do this. I think they find bugs and create an archive of exploits so that if they have to hack a computer, they can. But ofcourse there are alot people in the underground (black-hat hackers) that keep the information to themselves too. Exploits which are not publicated are called zero-day exploits (0-day). This is the reason why you should disable any service, or not install any program that you don't need and restrict those that you do need. If you have a sendmail service on your system for personal use you must put a firewall to drop all incoming connections on port 25 coming from the internet. Even if you have the latest and patched versions of services ofcourse. 6. Last words I wanted to give you some practical examples here which you could try on your own system. But I have a good reason not to do this. In my opinion you should first try to understand a little of the first few tutorial parts. These parts include how to avoid being detected and how to plan an attack. So I keep the practical parts and guiding tutorial parts to the end. Otherwise I'm afraid some of you will never learn what else is involved. Keep your eyes open for the following parts: VISIT http://duho.cjb.net/ You are encouraged to spread this file but don't modify it. XT (duho@my.security.nl): [DuHo] 2001 -EOF- Size: 20480 bytes chars: 18821 Words: 2902 Lines: 459