Conference noted::hackers_v1

    First, make sure that you search all .COM files that they use
    (including the ones in their own directories.)   Search for "@"
    to make sure you get them all.   Even that may not do it.  With
    clever DCL, I can hide almost any DCL command from obvious searches...
    
    If a user with CMKRNL is hacking them, turn on image accounting,
    and then search for suspicious image activations around the time
    they are hacked.   For example, a [USER]DUNGEON.EXE might be the
    image that is doing it.   [USER]HACKPROCESSNAME.EXE is a dead giveaway.

	Find out if the two process names are changed simultaneously (or
	nearly) or if there is a significant gap between the changes.
	If they are changed at different times, then the hack could be
	in something they are running themselves. If at the same time, 
	then chances are that the hacker is probably somebody with privs,
	and checking a list of image activations as suggested in [-1] should
	catch them. What about creating a process which checks for "Batman" 
	or "Robin" as processnames, and broadcasts you with the time when one
	is found ? This would cut down on the amount of searching to be done.

	A third possibility, albeit a less likely one, is that the hack 
	might be a patch to an image in sys$system which is used moderately 
	often. Mind you, I don't think anyone would go that far, but you 
	never know. Keep us posted.

<CFM>

	    The "C3" program (written by Peter Gilbert) searches binary
	files for ASCII strings.  You might want to look through user
	.EXE files for "Batman" and "Robin" with it.  If so, you can
	get a copy from my system:

		{CLOSET|VAXUUM}::TOOLS$LIBRARY:C3.EXE

	   Then again, maybe you could just use SEARCH?
			<_Jym_>
	Of course, this won't work if "Batman" and "Robin" are in an
	encrypted format within the .EXE file.

    I believe there is a watchpoint driver on some future version of
    VMS (v4.4?).  If you'd got it, you could use it to find out who
    changes the relevant fields and from where and when.  I know this
    goes against the whole spirit of hacking, but it seems this is a
    fairly serious request for assistance in nailing a hacker ...
    
    T

First of all, I'd assume the current culprits have just deleted the
evidence, since they probably are following this discussion !

However, for future policing, I've got a program that may help.

The program spits out a line announcing timestamp, username, process
name, terminal, image name, every time someone goes in or out of
anything.

So, for instance, every time someone EXITS the editor, or starts
a command that runs an image, my program spits out a line.

The program does not drain the system much, as it mostly sleeps
and just snapshots the system once every two seconds.

So, one thing you could do is run the program in batch, which will
cause its saliva to accumulate in the log file.  Then, after the
crime has been committed, see who entered or exited what image
in the vicinity of the time the funny process name appeared in the log.

If anyone wants this tool, please send me mail.

/Eric

    
    	If the culprit is reading this (unlikely - my group isn't very
    notes oriented) then perhaps they would like to come and tell me
    how they're doing it. I promise I won't be annoyed !
    
    
    Trev

    If you really want to catch the culprit, do some hacking of your
    own. 
    
    	1. change the page protection on the page containing the PCB
    for the process in question to disallow kernel write access.  You
    might want to make the PCB be on its own page to cut down on hassles.
    
    	2.  Change the accvio handler to special case access violations
    for the page who protection you changed.   When you get an accvio,
    change the page protection, simulate the instruction, and change
    it back again.   Since you know which virtual address is being written,
    you can watchpoint the process name.
    
	One of the gotchas is to watch out for PROBEs.   I'd doubt 
    VMS is probeing to make sure the PCB is writable from kernel mode,
    but you never know.   Of course, you have to do all this at the
    correct (elevated) IPL.   
    
    	SMOP, right?
    
	Another solution might be to cry 'uncle' and hope the hacker
    will tell you what is going on.
    
    	KC

Hi.  I have always wondered how to use cmkrnl to fiddle with process
headers etc.  Just to satisfy my OWN CURIOSITY, could somebody kindly
send some progs they might have around to me?


		Thanks!
.m.

    	The following programme could provide an example for .8. It
    was intended to be run from a login command procedure, and changes
    the account name to what is provided as an argument in the DCL foreign
    command that runs it. It also changes the default directory to
    [username.accountname]. The programme must be installed with CMKRNL
    privilege if not run from a privileged account.
    
    	(I think the above is correct. I wrote the programme about 6
    years ago as a sort of exercise. As you can see it was before I
    learned how to use comments. But then real programmers never need
    comments, right?  :-)   )
    
    	.TITLE SETACNT
	.IDENT /X01/
;
;SET ACCOUNT NAME AND SUBDIRECTORY
;FROM COMMAND LINE
;
	.LIBRARY	\SYS$LIBRARY:LIB\
	$JPIDEF
	$SSDEF
;
;START OF DATA AREA
;
	.PSECT	DATA,RD,WRT,LONG,NOEXE,NOSHR
DATBAS:				;BASE ADDRESS FOR OUR DATA
GETCMD=.-DATBAS
	$CLIREQDESC-
	RQTYPE=CLI$K_GETCMD	;TO GET COMMAND LINE
;
DIRARG=.-DATBAS
	.LONG	3
	.ADDRESS	DIRDSC
	.LONG	0,0		;ARGUMENT LIST FOR DIRECTORY SET
DIRL=.-DATBAS
DIRDSC:	.LONG	0,DIRN		;DIRECTORY NAME DESCRIPTOR
;
GETUSR=.-DATBAS
	.LONG	7,0,0,0
	.ADDRESS	ITMLST
	.LONG	0,0,0		;ARGUMENT LIST FOR USERNAME
ITMLST:	.WORD	12
	.WORD	JPI$_USERNAME
	.ADDRESS	USERN
	.LONG	0,0		;NO LENGTH NEEDED,END OF LIST
;
DIRNAM=.-DATBAS
DIRN:	.ASCII	/[/		;START OF DIRECTORY SPEC
USERN:	.BLKB	20		;REST OF SPEC STARTS WITH USERNAME
;
;START OF CODE
;
	.PSECT	CODE,RD,NOWRT,EXE,SHR,LONG
;
	.ENTRY	SETACC,^M<R2,R3,R4,R5,R9,R10,R11>
	MOVAL	DATBAS,R11	;SET ADDRESS BASE FOR DATA
	PUSHAB	GETCMD(R11)	;GET COMMAND LINE ARGUMENT
	CALLS	#1,@CLI$A_UTILSERV(AP)	;CALL BACK THE CLI
	MOVQ	GETCMD+CLI$Q_RQDESC(R11),R9 ;GET THE RETURN DESCRIPTOR
	PUSHL	#0		;ARGS IN R9,R10 FOR OUR ROUTINE
	PUSHAB	B^KERMOV	;OUR KERNEL MODE ROUTINE
	CALLS	#2,@#SYS$CMKRNL	;CALL OUR ROUTINE IN KERNEL MODE
	BLBC	R0,ERROR	;RETURN STATUS
	CALLG	GETUSR(R11),@#SYS$GETJPI ;GET USER NAME
	BLBC	R0,ERROR	;RETURN STATUS ON ERROR
	LOCC	#^A/ /,#9,DIRNAM(R11)	;FIND END OF NAME
	MOVB	#^A/./,(R1)+	;MOVE IN SUBDIRECTORY SEPARATOR
	MOVC3	R9,(R10),(R1)	;MOVE IN ACCOUNT NAME
	MOVB	#^A/]/,(R3)+	;MOVE IN TERMINATOR
	MOVAB	DIRNAM(R11),R0	;GET START OF NAME
	SUBL3	R0,R3,DIRL(R11)	;SUBTRACT TO GET LENGTH
	CALLG	DIRARG(R11),SYS$SETDDIR	;SET THE NEW DEFAULT DIRECTORY
ERROR:	RET			;RETURN EITHER GOOD OR BAD STATUS
;
KERMOV:	.WORD	0		;KERNEL MODE ROUTINE TO DO SET
	MOVZWL	#SS$_ACCVIO,R0	;SET ACCESS VIOLATION IN CASE
	PROBER	#0,#8,(R10)	;PROTECT OURSELF
	BEQL	RETRN		;IF BAD ARG
	MOVC5	R9,(R10),#^A/ /,#8,@#CTL$T_ACCOUNT
	MOVZWL	#SS$_NORMAL,R0	;RETURN SUCCESS
RETRN:	RET			;BACK TO SAFETY
;
	.END	SETACC
    

    You think process names are being hacked now!  For heaven's sake,
    don't INSTALL .9 with CMKRNL.  Only allow it to be used by people
    with CMKRNL already.
    
    Burns
    

    
    	I found out who was doing it. As suggested in a previous reply,
    I turned on Image accounting, and waited. This morning, one the
    the guys noticed that his name had been changed between 9:30 and
    10:30, so I looked through the log, found a suspicious entry, had
    a look in that user's account ,and found the program that was doing
    it. Thanks for the suggestion...
    
    	In retaliation, I've made a new version of the program that
    sets *his* process name, and put that back in his directory - that
    should confuse him !
    
    
    Trev

    
    	
    
    How about posting a copy of that program ??
    
    	

    YEAH!!!!
    
    

    Re .11,
    	Trevor,
    		Ofcourse you realize that if there is a real _good_ hacker
    		involved then the user you indentified is in fact a victim!
    	Hein.

    
    	Yes, the thought had crossed my mind, but other completely
    unconnected circumstantial evidence also fingers this particular
    gentleman.
    
    	I'm not going to post the program, because I don't really want
    to cause any other system manager grief ! It's trivial really -
    anyone who's been on the VMS internals course could write one -
    you could find out just by reading the VMS internals book.
    
    
    Trev
    
    

    But what about those of us who haven't taken VMS internals or don't
    have a copy of the book? :-)
    
    Mike

    Then you have incentive to take the course and have your cost center
    order you the book, the way the rest of us learned... 

    	Jon

    Hah!   Uh uh.  That's not the way the rest of us learned.  The
    rest of us learned the fun way, type, crash, ask, scratch, drink,
    ask, type, crash, . . .
    
    Hacker's riddle, while we're on the subject of
    hacking process names on VMS (I have the answer):
    
    		Find a way for an unprivileged user to create
    		two processes having the exact same process
    		name.  Yes, same uic's etc.
    
    /Eric

       Well, this isn't easily done by choice, but I know that if you
    were to do something like this, you can get a duplicate process
    name...
    
       #1: Log into your account on any old terminal, keeping your process
    name at its original value.
    
       #2: Log in again at terminal X.  Set your process name to _OPA0:.
    
       #3: Log into OPA0.  Now, when you log in, the system sees a process
    with your username for the process name, so it (without checking,
    the last time I looked) just sets it to your terminal device name.
    
       How's that sound?  It works, but might be more contrived than
    you like.
    
                                            -mjg
    

	    [RE .19]:  I believe you can pull a similar trick with
	_RTAx: terminals/process names too.
			<_Jym_>

    
    	ever tried setting your process name to null or opcom , it
    will let you do it .
    
    	also anybody got an order number for that internals book that
    is referenced in this note ???
    
    							randy
     

    How about setting it to 'swapper' right before launching
    some big cpu killer job.  
    
    

    No problem.  It turns out that there's a window in the VMS code
    that checks for duplicate process names, such that if you $CREPRC
    two processes with the same name within some relatively large
    time window (fraction of a second), neither of them gets the
    duplicate-process-name error.  The $CREPRCs must be done from two
    different processes in order to get them to overlap sufficiently.
    
    Andy G. has assured me that this is a bug in VMS, but it hasn't
    been fixed yet (as of 4.4).

    OK, so now we have 2 processes with the same name. What happens
    if one tries a
    
    $ stop proc_nam
    
    ???
    
    Mike

The RTA solution is the easiest way I know of generating two processes
with the same name.

The OPA solution is not as good, since not every hacker is allowed
into the machine room !

The $CREPRC solution requires intelligence, so forget it.

Here's detail of how to do the RTA solution.  Feel free to try it,
it does no harm (but see end of article).

	$!  First, make sure your process name is the default, namely
	$! your username.

	$ set host 0		! create process RTAx:

	$ set host 0		! create process RTAy:

	$ show process		! find out what y is

	$ logout		! get back to RTAx:

	$ set process/name="RTAy:"
                    		! we are now the FIRST rendition of RTAy:
	$ set host 0		! create SECOND rendition of RTAy:

Let me know if this works for you.  Oh, by the way, it might take several
tries, since if someone else sets host in the interim, x and y can
change.

Here's the interesting question, from the hackers point of view:

	Given that VMS attempts to prohibit multiple process names,
	is VMS only being formal, or is there some security or
	integrity hole opened up by the bug ??

/Eric

	$ set process/name=swapper

	    . . . works fine for me.
			<_Jym_>

The reason why you can set your process names to NULL or OPCOM is because
process names are group logical names, and few users have accounts in
group [0,*] or [1,*].  You don't need access to _OPA0: to pull this
trick, it will work with any hardwire line.  That is, if you know this
terminal is always _TTB1: to VMS, set your process name to _TTB1: before
logging onto the terminal attached to TTB1: (of course you still need the
third process logged in with process name=username.)

-Mike

    	Process names are not logical names. There is no security problem
    associated with any of the ways of duplicating logical names described
    here, the only thing you can do is confuse yourself.
    
    	There is someone here who in his login command file sets the
    name of his first process to a single space, the name of his second
    process to two spaces, ...
    
    	They all appear the same on a display, and it causes no-one
    any problems (except possibly him).
    
    		Dave

    One way I accidently got two processes with the same name was to
    run a command procedure that changed my UIC to [1,4] and then
    changed it back.   While this command procedure was running, I happened
    to log into another terminal to read my mail.   Once I the command
    proceure on the first terminal set my UIC back, I had two processes
    in the same group with the same name.
    
    STOP gives you real strange behavior.
    
    Cheers	
    KC

re .30:  You are right, process names are not logical names.  However, only
processes in your group are checked for duplicates when changing your
process name.  This is why you can set your process name to NULL, etc.

-Mike

    I couldn't help but laugh when I just read this!
    I hadn't been into this notes file lately because nothing
    interesting was happening...now I come back and read this!
    
    I'm laughing because I've been changing not just process
    names, but also *usernames* (note the user name above. ever
    see lower case in a user name?!?)
    
    Now if I could just figure out where the node name was hiding...

	    Yes, I've seen them before.
			<_Moi_>

    Is there a way to disallow users from changing their Process name?
    
    This is  in a  college environment, so you can imaging what kind
    of names the users come up with!! :)
    
    We would like to limited the changing of process name to only a
    few users, if not possible, then disable it altogether.
    
    Regards,	Ray

    Re .35:
    
    Since the process name is changed via a system service call, is
    there a way to "patch" the operating system to return from this
    call?
    
    Mike

>    Since the process name is changed via a system service call, is
>    there a way to "patch" the operating system to return from this
>    call?

  Yes, you could patch SYS$SETPRN+2 with a RET instruction...or, you could
patch EXE$SETPRN to check the caller's access-mode, and return if the caller
was in user-mode.

Ron

>   Yes, you could patch SYS$SETPRN+2 with a RET instruction...or, you could
>  patch EXE$SETPRN to check the caller's access-mode, and return if the caller
>  was in user-mode.
      
      That's dangerous, since the system really wants to do things like
    set the process name for things like JOB_CONTROL, and other detached
    processes.
    
    How about removing the syntax of the SET PROCESS command from SET.CLD?
    
    You said you were in a college environment, I don't know if it's
    legal for you to get SHOWCOMMA from the toolshed, but we have done
    that here for a particular application where the users have access
    to DCL, and we have removed the ability to EASILY change process
    names... This does not prevent a hacker from writing a program to
    use $SETPRN to set a process name, but if you are a college sysmangler
    then you can usually find ways to actively discourage those sort
    of programs (they did it when I was in college...)
    
    Of course, -1 is an elegant solution, but I think it's a bit dangerous
    since you have no guarantee that ALL system software you are running
    or will ever run will execute the $SETPRN outside of user-mode.
    Also, you need to support your patch forever. 
    
    Regards.
    
    /pjh

    A good hacker would've setup the program to copy itself into a
    large buffer attached to a timerqueue entry to go off at a specified
    time.  It would've NEVER been caught...because the process doesn't
    exist!
    
    
    :-)
    
    John

    Another approach, particularly suited to problems in schools, is
    to not prevent process name changing but to instead frustrate it's
    purpose.
    
    For example, let's suppose you have a well-defined notion of the
    "proper" process name for each process.  Something based on the
    username and/or terminal name such as is used by VMS.  Create a
    detached process (or even a batch job) that periodically scans through
    all processes and resets the process name for interactive and batch
    processes to the "proper" value.  (This has to be somewhat selective,
    as there are some processes that require known, fixed process names.
    But you can recognize these by doing a SHOW SYS).
    
    Let the students change their process names all they want -- just
    change them back.  Your background process can even check the current
    process name before restoring it, so you can keep track of who the
    offender's are.  Anyone who can systematically beat a scheme like
    this while still getting work done is probably worth hiring.

    re .40:
    
    Isn't that a little inefficient? I mean a process that continually
    runs and changes process names back to the username seems to me
    that it would use system resources unnecessarily.
    
    I guess it is just a suggestion that works so it's not a bad idea. 
    Depends on what the college really wants.
    
    Mike

    Re: .35

	1) Just teach the operators to kill processes with offending
	   processnames (they *love* this kind of dirty job).  8^)

	2) If the users ask tell them that a detached process kills
	   everything with non-standard processname.

    Users, suddenly, will discover is not so funny play with processnames.

BTW, it's rather difficult for a process to change the name of processes
other than itself...SYS$SETPRN does not provide this service. For the purpose
of enriching the redoubtable occupation of hackery, I will suggest this:

      To change the process-name of another process, go into
      kernel mode. Then acquire the scheduler-database interlock
      (however this is done...raising IPL to SYNCH works on
      uniprocessors only). Then locate the software PCB for the
      target process. Change the field PCB$T_LNAME to whatever
      is appropriate. Unlock the scheduler database and exit.

Of course, you could queue an AST to the target process, and make the AST
service routine be SYS$SETPRN, and the AST parameter be a pointer to the
new process-name, which you've put into a block of nonpaged pool.

Ron

    Re: .42
    
    	A simple batch job (modifiable to contain the offending usernames)
    can be used to automatically kill those jobs!  The operator is
    therefore not restricted to checking for them....
    
    
    :-)
    
    -John
    

    What's the problem with offensive process names, anyway?

    Oh, I see....  Someone may display them.  Well, yank or cripple
    the system utilities that display the process names.

    FWIW -
    
    	The first time I ever changed my process name at my last job,
    my system manager thought I had performed some vast security breach
    (we were all pretty new to VMS) and he was calmly assured by one
    of are more experienced VMS people that a simple DCL command did
    what I had done...
    
    	Boy did I feel silly - I had written a program to go out and
    call $SETPRN... I didn't know the DCL command existed!
    
    					--D

    Greetings from the Great White...
    
    Quick question guys...(I hope replys are read)
    
    Is there any way of embedding escape sequences in the SET PROCESS/NAME
    
    Maybe a flash or two would liven up the SHOW USERS command.  I've
    tried defining NAME :=="<ESC>[5mtext" and then SET PROC/NAME =
    "'NAME'", but it just shows up as .[5mtext when you show users.
    
    When you show symbol NAME it works, but not when you show users...
    hummmmm.
    
    Any ideas ???
    
    
    Ian

It used to work on VMS V3.x, but people often put meaner escape sequences
than just flash-on, so SHOW USER/SHOW SYSTEM now filter out escapes (they
show as dots).  Escapes in MAIL messages are also filtered for the same
reason...

-Mike

    	Ya, I see what'cha mean, gosh, no one I know would do anything
    like that... :^)
    
    	Thanks anyways Mike,
    
    Ian_who_can_almost_feel_Saturday 

    I was just wondering after reading this note, how do you add the
    quotes and a little saying at the end of your user name?
    ex. CURIE::DECARTERET "Right Here"
    
    Also, how did those two people earlier in the note change their
    usernames?
    -=*>Jason<*=-

    VAX Notes and several other interpersonal communications tools support
    personal names such as the "Cute phrases" at the end of the user
    name.  These "Cute phrases" are not part of the user name.  User
    names must be pretty boring.
    
    It's amazing what one can learn by reading the online help or the
    product documentation. 
    
    Have a ball,
    
    Don