The Hack FAQ

10.0 The Basic Web Server

This section deals with other platforms but it mainly refers to Unix-based Web servers.

10.1 What are the big weak spots on servers?

The big weak spots are as follows:

10.2 What are the critical files?

They are as follows(the names may vary depending on the httpd server you're running):

Contains all of the info to configure the httpd service.
Contains the info as to where scripts and documents reside.
Defines the service features for all browsers.
Limits access on a directory-by-directory basis.

10.3 What's the difference between httpd running as a daemon vs. running under inetd?

Performance. If httpd is running as a standalone daemon, it read its configuration files once, and responses faster to user requests. Typically, if a site is expecting many users, the server is dedicated. This can be as simple as starting httpd as follows:

# httpd &

Of course, the site will probably have something like this in the /etc/rc0 (or equivalent file) so that httpd starts on bootup:

if [ -x /path/to/httpd ]

Most sites with web servers accessible to the Internet run as a standalone daemon. The downside is if the web service isn't being used all of the time then the server is wasting CPU running a web service with no one accessing it.

Running httpd under inetd starts and stops as user requests come in. The performance isn't as good -- as the server spawns httpd for each user, the configuration files are read in for each request. It is usually run by having a line in /etc/services like this:

http 80/tcp

There is an entry like this in /etc/inetd.conf:

http stream tcp nowait nobody /path/to/httpd httpd

This type of setup is most common on intranets. Very few Internet servers are set up this way, unless they are simply not very busy or the site is simply trying to save resources, combining web, ftp, and a few other services on one box.

10.4 How does the server resolve paths?

Typically, a server will resolve paths by having a point in the configuration files that says something like "turn ~ into public_html", which means that ~thegnome will resolve to /server/path/to/documents + public_html. Therefore, if your server's path to docs is /usr/local/etc/httpd/htdocs with a sub directory under that of public_html with all of the users' directories under THAT, becomes and accesses the same file.

The problem with resolves is that some sites (depending on software, revisions, os, patches, etc) will resolve based off of the /etc/passwd listing of the home directory. This is good for intrusion, bad for security. As stated earlier in the FAQ, accessing can yield interesting results. In practical experience, we've seen this more often on BSD derivatives with Apache than anything else.

10.5 What log files are used by the server?

This entirely depends on the server software and how it is configured. It is usually in a subdirectory called "logs" in a different section of the tree than the regular web pages. It is usually named "access_log" for Apache or NCSA, or "access" for Netscape, or some other easily self-identifying name. This log will contain entries like so: - - [14/Dec/1996:00:13:31 -0600] "GET /nomad/ HTTP/1.0" 200 293 - - [14/Dec/1996:00:13:35 -0600] "GET /nomad/2.html HTTP/1.0" 200 303 - - [14/Dec/1996:00:13:39 -0600] "GET /nomad/3.html HTTP/1.0" 200 333 - - [14/Dec/1996:00:13:43 -0600] "GET /nomad/4.html HTTP/1.0" 200 359 - - [14/Dec/1996:00:13:47 -0600] "GET /nomad/5.html HTTP/1.0" 200 385 - - [14/Dec/1996:00:13:51 -0600] "GET /nomad/6.html HTTP/1.0" 200 434 - - [14/Dec/1996:00:13:55 -0600] "GET /nomad/nomad.html HTTP/1.0" 200 1988 - - [14/Dec/1996:00:14:02 -0600] "GET /nomad/unix/index.html HTTP/1.0" 200 5066 - - [14/Dec/1996:00:14:28 -0600] "GET /nomad/unix/cvnmount.exploit HTTP/1.0" 200 3117

Obviously, if your phf accesses are in there, it could be incriminating. If you gain access, you might want to eliminate yourself from them.

  1. mv access_log access_tmp
  2. cat access_tmp | grep -v > access_log
  3. rm access_tmp

The same with the error log. Called error_log or error, it's entries look like so:

[Thu Dec 19 22:10:02 1996] access to /usr/local/etc/httpd/htdocs/nomad/faqs/netware.htm failed for, reason: File does not exist
[Thu Dec 19 22:10:21 1996] access to /usr/local/etc/httpd/htdocs/nomad/faqs/_free.html_ failed for, reason: File does not exist
[Thu Dec 19 23:29:35 1996] access to /usr/local/etc/httpd/htdocs/nomad/HTTP failed for, reason: File does not exist
[Thu Dec 19 23:48:19 1996] send script output lost connection to client
[Thu Dec 19 23:48:25 1996] send script output lost connection to client
[Fri Dec 20 09:19:13 1996] accept: Connection reset by peer
[Fri Dec 20 09:19:13 1996] - socket error: accept failed
[Fri Dec 20 10:35:41 1996] accept: Connection reset by peer
[Fri Dec 20 10:35:41 1996] - socket error: accept failed
[Fri Dec 20 10:39:55 1996] access to /usr/local/etc/httpd/htdocs/nomad/unix/Xtx86.c failed for, reason: File does not exist

10.6 How do access restrictions work?

This is going to vary from platform to platform, but we're going to use NCSA as an example. We're not going into a lot of detail, the point is that service can be limited, and to give a flavor of how easy it is for an admin to set up.

Restricting Access by Host Name:

In NCSA this is in access.conf, and you can specify the following:

host names allowed
determines whether per-directory access overrides global access restrictions
host names denied

There are more options depending on OS, server software, etc., and you can get pretty detailed. But most server software allows access restriction by host names.

Restricting Access by Directory:

This is usually accomplished by specifying a realpath/to/directory tag with the restrictions following, and then closing with an ending tag of , all within the access.conf file. For example, let's say the admin wants to limit a directory to company employees only on an NCSA server:

<Limit GET>
        order deny,allow
        deny from all
        allow from

Include those lines in a .htaccess file in the directory you wish to limit and bingo, you're limiting access.

10.7 How do password restrictions work?

This typically involves the admin performing the following functions:

Building each user id/password as needed. Updating the main configuration files to recognize that passwords are being used. Updating any .htaccess files in individual directories.

The command line syntax for creating a user ID and password (on NCSA) is:

htpasswd [-c] .htpasswdUserName

UserName is the name of the user file you wish to create or edit. The -c option specifies a new file be created, not the old one edited. If you are creating a new UserName file, and htpasswd doesn't find a duplicate name, you will be prompted for the password. If it finds a duplicate name, it will prompt you to type it in twice. These passwords do not correspond to system passwords, so if you are an idiot wannabe hacker and you just got into a server with a shell, don't expect to create a root account with htpasswd and then su to it.

In NSCA, you will find the following in the access.conf file indicating passwords are in use:

<Directory /usr/stuff/WWW/docs>
        AllowOverride None
        Options Indexes
        AuthName secretPassword
        AuthType Basic
        AuthUserFile /usr/WWW/security/.htpasswd
        AuthGroupFile /usr/WWW/security/NULL
        <Limit GET>
                require user UserName

For a directory-level usage, this might be in the .htaccess file:

AuthName secretPassword
AuthType Basic
AuthUserFile /usr/WWW/security/.htpasswd
AuthGroupFile /usr/WWW/security/.group1
<Limit GET>
        require user UserName

Once again, we're not going to go into a lot of detail here. You need to read the documentation for the server you're attacking (i.e. do your homework) and THEN start changing or updating files. For example, .htaccess is the name of the file for NCSA and its derivatives.

One of the good things for intruders is that if an admin is using per-directory restrictions you can often retrieve these files just like a regular URL. For example, if the target is restricting access to the /usr/local/etc/httpd/docs/secure directory using a .htaccess file to control access, this URL might retrieve it (depending on server software):

Besides containing important info, it will give you the location of the web passwd file.

10.8 What is web spoofing?

Summed up, web spoofing is a man-in-the-middle attack that makes the user think they have a secured session with one specific web server, when in fact they have a secured session with an attacker's server. At that point, the attacker could persuade the user to supply credit card or other personal info, passwords, etc. You get the idea.

Here's how it works in a nut shell:

What is the problem here? It is not SSL. It is the certificates. You see, as long as you have what looks to be the proper info in the certificate, the user will never know the difference. Sure, the URL might not look right, but you can use Java to control that.

Of course, only an idiot would redirect a user to a server in their home or office, you would of course redirect them to a server you have compromised. And you would use the compromised server's certificate to get that solid key. That's the trick -- make the key solid, and the user is fooled.

For more details on this type of attack, check out the following URLs:

Top | Next: NT Basics | Previous: The Web Browser as an Attack Tool | Table of Contents