Conference noted::hackers_v1

    
    Try having people hit ^Z at the Username: prompt first - that should
    catch a poorly designed password grabber.
    
    Unfortunately the best password grabber I ever saw trapped ^C and
    ^Y, disabled broadcast for ^T, and even did the ^Z trick. However
    if you go secure and enable the <BREAK> key instead, no program
    can get around it. 
    
    I don't think you can share a terminal with anyone without SHARE
    privs; likewise, you need CMKRNL to get around most everything else,
    like the "force input/output" hack seen earlier.
    
    Are your terminals dedicated? (like, rs232 on a DMF-32 or something
    like that?) If they are it isn't hard to be more secure.
    
    /pjh
    

Your ability to allocate (or open a channel on) a terminal is controlled by
the protection on the terminal device.  The VMS default - since at least V3 -
is to set free terminals to no access by WORLD.  (You can log in because
because LOGINOUT has all the privileges it needs to get at any terminal.)
This eliminates all simple password grabbers not initiated at the terminal
itself.  However, it's not hard to for the system manager (or any privileged
user) to change the protections - find out what they've been set to before
going further.  I can imagine reasons why someone might want to change this -
programs that drive a bunch of terminals that they allocate, for example.
These programs SHOULD be installed with sufficient privilege to be able to
get at the terminals; of course, then they have to be written carefully to
not abuse their privileges.

To provide complete protection against password grabbers who CAN get at your
terminal and leave a program running, set the termainl /SECURE_SERVER and
then ALWAYS type BREAK before trying to log in.  VMS, when it receives a
BREAK on a SECURE_SERVER terminal, disconnects or deletes the process logged
in to the terminal (it may also close any channels opned by other processes,
but I'm not certain); the program cannot prevent this.

The biggest problem with /SECURE_SERVER is that it's incompatible with /AUTO-
BAUD.

Note that a password grabber will (a) normally be running under the grabber's
account; (b) has no way of actually logging you in into your account.  Because
of (b), password grabbers usually pretend that you mistyped your password, or
through out some fake line noise, and then log out.  When you try again, you
may spot a discrepency in the number of failed login attempts reported -
probably 0 - and the number you know have just occured.  If so, report the
probaly immediately - because of (a), the perpetrator can be found with no
trouble.
							-- Jerry

    A datascope on the TT line may do the trick. 
    Definitly *not* software, but works !!!
    
    In fact, it is maybe not *only* a matter of VMS privs ... But I'll
    let some security specialist discuss it ;-)
    
    Pierre.

There was a note on Usenet recently of a site that didn't have
some "security patch" installed.  Someone broke into the system,
obtained privileges, and made a few selective patches to the system.

Among others, an encrypted (but not one-way hashed) copy of all
passwords was stored in the "reserved to users" field of the
UAF database.  The thieves could then keep up-to-date on the
changed passwords.

I would hope someone has distributed a checklist "what to do when
you're system is compromised" to our customers (or at least our
field specialists).

Martin.

    Section 6.3.2.3-6.3.2.4 of the _Guide_to_System_Security_ addresses
    this issue.  It recommends restoration of critical system components
    from the VMS distribution media.

As an addition to .5, suggest you try the following:

1. Audit your SYSUAF to re-examine exactly what privelege everyone has and 
if it is waht they should have, (check system startup for trojan horses 
placed in that area)

2. Introduce forced weekly password change to force the hacker to run their 
procedure again if they want to keep the benefit of some stolen privelege.

3. get several suspected victims and ask them all to tell you what 
passwords they have been using for the past week or so.

4. ask them to change passwords immediately (just good practise ;-)  )

5. Overnight run in batch, per device:
$SEARCH [000000...] "password1","password2".....


My guess is the hacker will actually be writing the none-encrypted 
passwords away somewhere, find the loot and you begin to find the thief,
I'd love to know if you catch them, did you catch the 'bother' ones (maybe 
the same people)?? Did you try the define/key I suggested for that one??


Jerry

>1. Audit your SYSUAF to re-examine exactly what privelege everyone has and 
>if it is waht they should have, (check system startup for trojan horses 
>placed in that area)


A useful method of spotting this is to use COMTREE from the toolshed which 
shows you the call structure of a set of command files.


Jerry

    .6 This is pretty definitely the same people that were playing with
    BOTHER.  The plug I've done for that is to disable network phone
    by removing the object in NCP.  We have a copy of BROADCAST here,
    (like SEND) on the digital systems.  It has the anonymity that 
    BOTHER has, in that it looks at your process name when identifying
    the sender.  I'm rewriting it to look just like BROADCAST with the
    exception that it writes the message to a file identifying the sender,
    the sendee and the message sent.  That should produce interesting
    data.  The plugging of network phone is a minimal impact soluting
    compared with having to train around 1k novice users about hitting
    a certain key sequence.  Good idea, but not a workable one in our
    current environment.  The rumor mill is very active here; the 
    "predators" have hidden their tracks and we're going to have to
    let them feel safe again before we can catch them.  
    
    Patrick

If the line is NOT set secure, it's fairly simple to steal passwords
and make the user think they're really logging in, including correct
response to ^Z, ^Y etc.

The general method is, install DTM, then open a PTY, and open the
mark's line, and use pass-through mode.  Every character the mark
types, record in a buffer or file, and pass to PTY.  Everything coming back
from the PTY, send to mark's line.

In this manner, the mark really IS logging in, but on a pty instead
of the line they think they're on, so typescript will look exactly right.

Now, if line is set secure, here's another idea I've never tried.
Do above procedure, except have a tight loop in a subprocess that
continually polls to make sure the program is still associated with
mark's line.

Then, if mark hits break and VMS disconnects the line, program immediately
detects it.  Have program IMMEDIATELY reassign the line.  I wonder if program
can possibly reassign mark's line before VMS starts real job on it.
(if so, it's a security bug in vms).

/Eric

    RE: .9
    
    Last time I checked, pressing break on a line set /SECURE summarily
    deleted any process owning that line.  Makes it kinda hard to reassign
    a channel, I suppose.  I have no idea how PTYs are affected by this.

>============================================================================
>Note 536.10                     password grabber                 10 of 10
>NEWVAX::CRITZ "In one damn minute, Captain"      5 lines  25-AUG-1987 16:58
>------------------------------------------------------------------
>                                               
>    RE: .9
>    
>    Last time I checked, pressing break on a line set /SECURE summarily
>    deleted any process owning that line.  Makes it kinda hard to reassign
>    a channel, I suppose.  I have no idea how PTYs are affected by this.



	If the bug I'm asking about exists, deleting the process
	wouldn't be enough.  Devious program could have another process,
	in a tight loop, attempting to assign the line.  As soon as
	BREAK causes first process to be deleted, other process might
	be able to grab the line !

/Eric

re .11, .10:

Probably the only way around this is to have BREAK start up the login process
automagically as part of its function as well as disconnecting/deleting the
owning process.

-Mike

    RE: .12
    
    Again, as I recall, the break key does, in addition to deleting any
    connected process, cause TTDRIVER to notify the JOB_CONTROLLER to
    initiate an interactive login.  I suppose there is an unavoidable
    window between this notification and the initiation of a LOGINOUT
    process where another process could steal the terminal.

    	Any process deletion that the terminal driver may try can be
    defeated by ASTs and exit handlers. I have seen an excellent example
    of this from Lisbon University. You must set the terminal to secure
    server and disconnectable, otherwise it is possible to run a programme
    from that terminal, but without privileges, which acts as a password
    catcher. You must also educate all users to hit <break> before trying
    to log in.
    
    	The recently distributed patches in the hackers bulletin boards
    are fairly insidious. If they can once get sufficient privileges
    to patch VMS images then there is one to LOGINOUT which does three
    things. It lets a someone in to a privileged account if they know
    the special password, it records *all* passwords in a two way encrypted
    form in the UAF (as mentioned earlier) and it puts a special flag
    on the process. Someone getting in via the special password can
    then read all the other passwords that have been used since the
    patch.
    
    	The other patch is to the SHOW utility. The effect is that if
    the special flag is set on a process (by the patched LOGINOUT as
    above) then the process does not show up with a $ SHOW USERS display.
    
    	Currently these patches can be detected fairly easily with 
    $ CHECK /IMAGE.
    
    		Dave

re: several, assigning the terminal after it is disconnected by BREAK

None of the possible timing windows or VMS bugs are relevent if the terminal
devices are set with the protections they should have:  No access to WORLD.

Of course, you can speculate about VMS bugs that let you get around the pro-
tections, but why go that far - how about speculating about VMS bugs that,
if you type just the right 5 letters to DCL, turn on all your privileges?

							-- Jerry

Re: .15

>... how about speculating about VMS bugs that, if you type just the
>right 5 letters to DCL, turn on all your privileges?

Gee, is five letters really necessary?  I thought all DCL commands
were unique within four characters.

    re .15 and .16
    
    But we all know that DCL does not grant privs. The operating system
    does.
    
    Mike

    .4 After re-reading this note, I decided to look into the
    "reserved-to-users" field of the UAF database.  The first time I
    read that, it didn't provoke a blink, but after trying to find some
    documentation of that field, I have to admit I'm stumped.  Where
    is it, what is it, and how is it accessed?  Better yet, where in
    the **** is it documented?
    
    Thanks,
    
    pnsoehl

    	The second 16 bit word of the record contains an offset to the
    field. You can find this out easily by extracting the record definition
    from the Bliss or Macro libraries.
    
    	I am pretty sure it was documented in the VMS V1 manual set,
    because I have always known about it. Now that $GETUAI, $SETUAI
    are being encouraged I would not expect to see any fields in the
    record documented.

    The user data area of the UAF is documented in Appendix B of the Guide
    to System Security.  It's still supported although it is not yet
    available through $GETUAI/$SETUAI (we're working on that...).

    Derrell (VMS Security Project)

    .20 Well, am I embarassed!  There it is, appendix B.  
    
    Thanks Derrell.
    
    

Systems tend to reveal the most chinks in their armor in the least
exercised parts.

Sure, you *might* find a way with DCL to get wheel privileges turned on.
But it's unlikely since so many people can so easily experiment with
DCL, so such bugs would have probably already been squashed.

But something like a loop attempting to grab a terminal just after break
has been typed.  Such areas aren't as easily experimented with, so the
chances of finding a bug are greater.

Of course, there might not be such a bug, which makes this "academic".

But as a veteran hacker I can tell you, if you want to hack, if you want
to break the system (translate: help Digital improve the security and quality
of its products), play with the darker crannies, not the obvious.

/Eric

    RE: .22
    
    Wheel privileges!  Have you gained an extra 4 bits somewhere?

    I found no mention of the potential security hole with LATservers:
    (It does require PHYIO privilege)
    
    The passwords are sent unencrypted on the Ethernet. If someone has
    PHYIO, they can access the DE*NA and get all packets on the ethernet.
    
    This can also be done with an ethernet analyzer, equivalent to the
    comm. analyzer mentioned in an earlier reply.
    
    Steve Kovner
    

It only requires PHY_IO if you try to read the packets using promiscuous mode.
But the LAT protocol number is known, so you can read just the LAT packets.
This requires no privileges, though it DOES require that the system you are
running on not be running LAT.
							-- Jerry