💾 Archived View for spam.works › mirrors › textfiles › hacking › issm204.hac captured on 2023-11-04 at 13:23:08.
⬅️ Previous capture (2023-06-14)
-=-=-=-=-=-=-
??????? Information???????????????????????????????????????????????????
? ???? ?????? ?????? ??? ??? ?
??????? Systems ??????????? ?? ?? ???? ?? ???? ??? ????? ?? ???? ?????
? ?? ?????? ?????? ????????????? ?
??????? Security ?????????? ?? ????? ??? ??? ??? ? ??? ???? ???? ?????
? ???? ?????? ?????? ??? ??? ?
??????? Monitor ??????????????????????????????????????????????????????
"Dedicated to the pursuit of security awareness."
======================================================================
Volume 2 Number 4 October 1992
======================================================================
/////////////////////////// In this Issue \\\\\\\\\\\\\\\\\\\\\\\\\\\\
BPD Security BBS Interview
Did You Know That...
Public Debt "Hackers"
Clyde's Hall Of Fame
"Dear Clyde..."
Computer Speak
Voice Mail Toll Fraud
Computer Security Day
///////////////////////////////////////////////////////////////////////
BPD SECURITY INTERVIEW
Editor's Note: The following interview was conducted by Jim
Thomas, Department of Sociology, NIU, Dekalb, Il., editor of
Computer underground Digest (CuD), August 12, 1992. Permission
to reprint the article has been given by the editors of CuD.
Computer Underground Digest is an open forum dedicated to sharing
information among computerists and to the presentation and debate
of diverse views.
(MODERATOR's NOTE: We heard about the AIS BBS from several
readers, and checked it out. We were impressed by the collection
of text files, the attempt to bring different groups together for
the common purposes of security and civilizing the cyber frontier,
and the professionalism with which the board is run. AIS BBS is
a first-rate resource for security personnel who are concerned with
protecting their systems).
THOMAS: What is this Board? (Name, number, who runs it (dept &
sysop). What kind of software are you using? When did the board
go on-line?
CLANCY: The Bulletin Board System (BBS) is run by the Bureau of
the Public Debt's Office of Automated Information System's Security
Branch. The mission of the Bureau is to administer Treasury's debt
finance operations and account for the resulting debt. The OAIS
Security Branch is responsible for managing Public Debt's computer
systems security. The AIS BBS is open to the public and the phone
number for the Board is (304) 420-6083. There are three sysops,
who manage the Remote Access software. The BBS operates on a
stand-alone PC and is not connected to any other Public Debt
system. The Board is not used to disseminate sensitive
information, and has been up operating for the past 15 months.
THOMAS: What are the goals and purposes of the Board?
CLANCY: The BBS was established to help manage Public Debt's
security program. Security managers are located throughout Public
Debt's offices in Parkersburg, WV and Washington DC. The security
programmers saw a need to disseminate large amounts of information
and provide for communication between program participants in
different locations. Because the Board was established for
internal purposes, the phone number was not published. However,
the number was provided to others in the computer security
community who could provide information and make suggestions to
help improve the Bureau's security program. Gradually, others
became aware of the Board's existence.
THOMAS: What kinds of files and/or programs do you have on the
Board? Why/how do you choose the files you have on-line?
CLANCY: There is a wide variety of files posted. In the
beginning, we posted policy documents, newsletter articles from our
internal security newsletter, bulletins issued by CERT, such as
virus warnings, and others for internal use. I located some
"underground" files that described techniques for circumventing
security on one of the systems we manage. The information, from
Phrack magazine, was posted for our security managers to use to
strengthen security. When we were called by others with the same
systems, we would direct them to those files as well.
Unexpectedly, the "hacker" that had written the file contacted me
through our BBS. In his article he mentioned several automated
tools that had helped him take advantage of the system. I requested
that he pass on copies of the programs for our use. He agreed.
This is how our "hacker file areas" came to be. Other hackers have
done the same, and we have also received many files that may be
useful. It is, indeed, an unusual situation when hackers and
security professionals work together to help secure systems.
However, this communication has been beneficial in strengthening
an already secure system.
THOMAS: Since you and the Secret Service are both part of the U.S.
Treasury, was the Board set up to catch "hackers?"
CLANCY: No, the BBS was designed to manage our internal security
program. We do not allow individuals to sign on with "handles."
We do not know if people are hackers when they sign on unless they
identify themselves.
THOMAS: How did you get the idea to set it up?
CLANCY: The security branch accesses many BBSs on a daily basis
for research purposes, information retrieval and to communicate
with others. Since our security program is decentralized, the BBS
seemed to be an effective way of communicating with program
participants in diverse locations.
THOMAS: What distinguishes your board from sources like CERT, or
from "underground" BBSes?
CLANCY: First, there is a wide diversity to our files, ranging
from CERT advisories to the 40Hex newsletters. Also, many of the
files on our system are posted as a resource we use for the
implementation of our security program. For example, the Board
lists computer based training modules that we have developed,
policy documents, and position descriptions. These are files that
other security programs can use to implement or help start their
programs. On the message side of the BBS, what distinguishes it
would have to be the open interaction between hackers, virus
writers, phone phreaks and the security community.
THOMAS: What kinds of difficulties or problems have you
encountered, either from superiors or from users, in operating the
Board?
CLANCY: I can recall few, if any, difficulties from anyone, users
or superiors. Upper management understands the value of the
technology and has been extremely supportive. All users have been
courteous, professional, and supportive. Security professionals
constantly thank us for providing "underground" information for
them. It allows others in the field to gain access to valuable
information without having to access "underground" systems. Users
appreciate the opportunity to share their knowledge with others and
seem grateful to have an avenue to communicate with security
professionals who will listen to "hackers" experiences.
THOMAS: Can you describe any unusual or humorous experiences you
have had with users while running the Board?
CLANCY: It is unusual for "hackers" and security professionals to
work together to help secure systems, but that is what is occurring
on our system. I have had requests from other government agencies
asking for resumes of "hackers" that may assist them. I have been
contacted by numerous government and private agencies asking for
our "contacts." I just direct them to the BBS and advise that they
post messages regarding the questions they need answered. If
anyone is interested in helping, they will respond. It is an
unusual situation, but, in my opinion, I can attest that the
information we have received has been very useful to our security
program.
THOMAS: What future plans do you have for improving the hardware,
such as upgrading modem, number of lines, or storage capacity, or
for developing the services of the Board?
CLANCY: Starting July 13th, the Board will be down periodically
for system upgrades. We are adding an additional phone line, and
a 315 mb hard drive. Also, we are going to make a few changes to
reorganize files. It is hoped that group information will be more
efficient in this manner. We are also adding RIME relay net
conferences and will carry topics such as Data Protection.
THOMAS: What should potential users know about the Board or your
policies before attempting to receive access?
CLANCY: Users must be aware that we do not allow handles on the
BBS. If they sign on with a handle it will be deleted. We also
reserve the right to review all E-mail, public and private. All
users have access to the BBS upon sign on. If a user wants access
to the "hacker" file area, they need to send a message to the sysop
requesting access. Potential users should know they are welcome
to call in and communicate with us and others.
----------------------- End of Article ---------------------------------
DID YOU KNOW THAT...
Public Debt's ISSMs recently completed Disaster Recovery Training
at classes held in both Parkersburg and Washington. The classes
consisted of both disaster recovery theory and the use of the
Bureau's purchased software product "DISASTAR", which is to be used
to prepare each application's own portion of a Bureau wide recovery
plan...
There is an ISSM meeting that is held every month. Your ISSM would
be happy to hear from you about any computer security questions,
issues or concerns that you may have so that they can be addressed
at that meeting...
----------------------- End of Article ---------------------------------
PUBLIC DEBT "HACKERS"
After reading the article in this issue of the ISSM about our
bulletin board system, it is no secret that we actively use hacking
tools against our computer systems to test their security. One
tool I have used to test our security is called GETIT.COM. (later
known as THIEF) . It is a program floating around the underground
community designed to capture logonids and passwords for Novell
Networks. I must say I found the program pretty impressive. It
is extremely easy to use and install and it works wel
Another file not included states that this program can be easily
spoofed if a user types "login userid". This allows the program
to only capture a password and not the logonid associated with it.
Of course, capturing passwords is not a good thing to let happen
but at least it does not give a person all the pieces at once.
Following is the documentation for the program.
Thief is a TSR (Terminate and Stay Resident) utility written in
8086 assembly language that attempts to steal Novell passwords.
It originates from a site with consummate hackers and a long,
colorful history of mischief: George Washington High School in
Denver, Colorado.
The school is well endowed with a large variety of IBM
microcomputers. Five rooms of about 30 computers each are all tied
together on a Novell network. Four of the five rooms solely use
boot proms* for initializing the workstations. However, the fifth
houses IBM PS/2 model 80s with hard drives. The power users tend
to congregate in this area, including the "administrators" with
Supervisor equivalence. These machines do not use boot proms.
So it was on one of these computers where the "thief" was first
discovered because it takes advantage of weaknesses in the security
at the boot phase. Into the regular flow of action in the
AUTOEXEC.BAT file, the creator inserted a line that executes the
(hidden) program copied onto the boot disk. The TSR remains in the
background and the process continues. Visual signs of thebreak-in
are imperceptible.
Then, as soon as a program named LOGIN is executed, the thief
springs to life and records all the keystroke action into a hidden
file on the boot disk. The human thief may then later return to
the computer and see what the trap caught. Before a more
detailed description of the "metabolism" of the thief, consider now
the weaknesses that led to the breach:
o a localized boot process, or at least one that is corruptible.
o physical access to a sensitive computer.
Both are controllable, of course. The boot prom is a solution
for the former, and lock and key (on the computer or a room that
surrounds it) is for the latter. Now return to the "metabolism".
Surprisingly, THIEF uses the same "hook" that the Novell shell
does! That is, it captures the centralized portal to DOS interrupt
21h.** Then, it intercepts all function calls. Specifically, it
checks for the EXECute file function call and the "terminate"
interrupt.
Whenever an EXEC call is made with a filename LOGIN, THIEF
springs to life and records keystrokes until the program
terminates. This is somewhat sophisticated; however, an even more
effective method could be realized: it could simply wait for the
specialized Novell function call to log in, and record the calling
parameters. Note that the above technique requires the program to
be loaded subsequent to the Netware shell.
By no means are these types of programs new; they have been
around as long as password-based program security. Here, however,
is an example that is tangible and immediate. Study of it is
beneficial because knowledge of Netware security is one thing;
knowledge of how to defeat it is quite another! The latter demands
cutting-edge sophistication and comprehension. The future will
certainly see improved identification techniques, and timeless,
devious ingenuity will be there to greet them.
Note: THIEF was formerly named GETIT by its creator, who was
careless and cocky enough to leave the source code.