Well, inside every page there are treasures of hidden information.
Use an agora server with the deep command or a good ftp-mailer, like mogli (w3mail@mogli.gmd.de)
with something like
get -l -a -img http://...
And you'll immediately see, without any effort, ALL hidden links existing on that same page.
You can find very useful snippets also through the simple "View document source" option
of Netscape... if a page uses frames, just "spring off" them, looking at the source code
that called those frames, in order to call it directly yourself without the "frame jacket"
(you may work on this personally on line or, better, per email, using a good agora server).
Since the majority of the smut depots do call "hidden" pages, you just need to perform a
deep "snooping" of their "allowed" pages in order to understand where else they could link
to... most of the time they will really hide some valuable information, and you'll be able to exploit the "weak"
side of their CGI-scripts, in order to destroy them, as explained inside my
"CGI-Script reverse engineering" pages one and two
Another useful trick is to have a look at all the COUNTERS of the site
you are attacking: smut dealer sites use counters heavily (in order to
be listed on the various "top reviews", see the "combing" page) and
counters use CGI-scripts! Some counter sites keep also track of ALL related
sites of a given counter, for instance ClaimItFor,
and this means that you can find "backwards" totally unrelated servers that
carry information pertaining to the same site!
You may also try an old "ftp" trick: mount a directory backwards (simply delete
from the URL Location window of your browser the last subdirectory, or the last
two, and see if that pays! If you "come through" to the arborescence you'll have
many chance to find somewhere a perl or CGI-script call that you can reverse to
destroy the site... or at least you'll be able to send the whole arborescence to
the newsgroups of the suckers (various alt.erotik.etcetera) laming the site out of
commerce for a while, until the site owner restructures the whole subdirectories
naming conventions :-)
Remeber that publishing (if you intercept or reconstruct them) some access
passwords of the site on Usenet WILL NOT DAMAGE the smut site, because all these sites
automatically filter any login: if two persons log in at the
same time with the same login_ID and password (which inevitably happens if you get
only some passwords attacking the site and then publish them on Usenet) the
relative accounts will be disabled.
But if you get THE WHOLE LOT (say piping a
metacommand, and publish
it on the Newsgroups of the porno addicts, you'll probably push the whole smut site out of commerce, because all the "legitimate"
suckers will make quite a big fuss with the smut site owner about not being able
any more to leech their pictures inside it!.
By all means, even if they WILL NOT work any more, for the filtering reasons explained above, have
a look at the many "smut-passwords-lists" that you'll find in the "warez" scene
sites, for instance here under
hacking/phreaking... some sites (not many, alas) use an AUTOMATICAL algorithm for
the password creation, based on the Name string of the user! These are pretty easy
to reconstruct, as you'll learn reading the +ORC's tutorial lessons and
the students' essays on my "main" site that deal with
all password protection schemes (and their algorithms).
User authentication on Unix type servers can allow or deny individuals access
to the document tree directories on a username and password basis. There is NO
correspondence between the system level usernames/passwords (in /etc/passwd) and
the web server's username/password file.
When users access pages that are protected with this mechanism, they are given
two prompt (username and password) to which they must respons correctly before
access is allowed. Once authenticated, they can navigate from page to page
without repeated authentication prompts. This works because the Web browser
remembers the hostname, directory path, and name/password for subsequent
retrievals. To use user authentication there must be somewhere a private
htpertext username/ppassword file. By convention, this file is called
.htpasswd
User authentication is designed so that a user does not need an account on
the system in order to be authenticated for access to files on the web server.
The .htpasswd file is manipulated through a program called htpasswd.
The source of this program is called htpasswd.c and is found in the
support/ subdirectory of most servers.
htpasswd is invoked as follows:
% htpasswd [-c] .htpasswdusername
where username is the name of the user that should be added or edited. The -c
flag, if present, tells hpasswd to create a new hypertext password file instead of
editing the existing one.
If htpasswd finds the specified user, it will ask to change the user
password (which must be typed twice). httpd then updates the file.
Individual authentication is accomplished using a combination of access control
directives and a private .htpasswd file. Let's look at an example used to
restrict access to only those individuals who know the password:
The access.conf configuration file (assuming they use DocumentRoot) must
look like the following:
<Directory /usr/local/etc/httpd/htdocs>
Options Indexes FollowSymlinks
AllowOverride None
AuthUserFile /usr/local/etc/httpd/conf/.htpasswd
AuthGroupFile /dev/null
AuthName By Secret Password Only!
AuthRType Basic
<Limit GET>
require user username
</Limit>
</Directory>
If you compare this to the general unrestricted configuration you'll see
that:
The AuthUserFile directive is added to specify the absolute pathname to the
hypertext password file (our target);
The AuthGroupFile directive has been added, but set to /dev/null, which by
UNIX standartds indicates that the file does not exist;
The AuthName directive is added to specify the prompt to be given to the
user for the username (in this case: "By Secret Password Only!");
The AUthType directive is added and sent to Basic. There is mostly no choice,
since Basic is the most used authorization type available.
ALL FOUR Auth directives go outside the Limit sectioning directive
The order and allow directives were removed from the <Limit> sectioning
directive and replaced with the require directive. This tells httpd to prompt
for a username and password and that the username has to be username.
Using the require directive dictates the need to use the AuthUserFile, AuthGroupFile,
AuthName and AuthType directives.
What happens next?
An hypertext password file is created for the username specified in the
access.conf configuration file:
% htpasswd -c /usr/local/etc/httpd/conf/.htpasswd username
htpasswd prompts now for the password.
If individual authentication is needed on a directory-level basis, say to protect the directory /usr/local/etc/httpd/htdocs/xxxsmut directory,
the following directives must be placed in a .htaccess file in that directory:
AuthUserFile /usr/local/etc/httpd/conf/.htpasswd
AuthGroupFile /dev/null
AuthName By Secret Password Only!
AuthRType Basic
<Limit GET>
require user username
</Limit>
As we have seen above.
Our smut targets use the same system, but for GROUP authentication
The users are placed into groups and then each group is treated as a
whole. There are three steps in this process:
A modification of the global ACF (access.conf) file.
The creation of an hypertext group file (.htgroup) with
multiple users as members.
The double checking that ALL users in the hypertext group file are
also in the hypertext password file.
Let's take a specific example:
<Directory /usr/local/etc/httpd/htdocs>
Options Indexes FollowSymlinks
AllowOverride None
AuthUserFile /usr/local/etc/httpd/conf/.htpasswd
AuthGroupFile /usr/local/etc/httpd/conf/.htgroup
AuthName By Secret Password Only!
AuthRType Basic
<Limit GET>
require group groupname
</Limit>
</Directory>
If you compare this against our starting point you'll see that:
The AuthGroupFile directive was modified from /dev/null to point to a
group password file called .htgroup. Usually this file is placed in
the SAME directory as the htpertext password file.
The require directive was modified from user to group and the username
was changed to groupname.
In a second step is created the file /usr/local/etc/httpd/conf/.htgroup,
which contains the following group definition:
groupname: username1 username2 username3... usernameN
Usernames are separated by spaces. Multiple groups could be identified in the
hypertext group file, one per line.
Web server don't have (like FTP and GOPHER) the chroot() feature, wherein
access is absolutely restricted to files within the data tree.
However, Web browsers can't randomly walk across the directory structure of the
system. All access is relative to the top of the docupent tree (as defined
by the DocumentRoot directive). httpd does not let users change directories
up past the top of the docupment tree.
However, unlike FTP and gopher (when set up properly), links from WITHIN the
document tree to OUTSIDE the tree do work!!.
If a symbolic link has been written in an html page to an existing directory
OUTSIDE the document tree (say inside a private user HTML directory), you may
be able to pass, unless the followsymlink option inside access.conf has
been disabled or changed to SymLinksIfOwnerMatch
The Server administrators usually set the AllowOverride directive to None and
the Options directive to Indexes, preventing users from purposely including
executable CGI scripts in the HTML stream or establishing symbolic links that
lead out of the document tree.
The SymLinksIfOwnerMatch clause to the Options directive assures that
users can only establish symbolic links to files and directories they own,
AND THESE ON SMUT SITES are oft outside the document tree! If such links do
exist and you find them, you can oft escape the document tree jacket.
Antismut main page