From: jsue@ncsa.uiuc.edu (Jeffrey L. Sue)
Subject: Re: HELP!!! Security problem for gurus.
Originator: jsue@pluto.ncsa.uiuc.edu
Organization: The Dow Chemical Company
Date: Tue, 22 Dec 1992 16:19:18 GMT
Keywords: hack security files-11 protection

In article <1992Dec19.025940.1@us.oracle.com> comet@us.oracle.com writes:
>In article <Bz1nrE.ALq@unx.sas.com>, sasjzs@falcon.unx.sas.com (Joseph Slater) writes:
>>
>>In article <B1FB21FFA27F004AEF@imimnvx.irfmn.mnegri.it>,
>>PSI%ITAPAC.22800002::PITCLS::ADRIANO@imimnvx.irfmn.mnegri.it
>>(Adriano Santoni) writes:
>>
>>|>      I need to avoid certain people to scan a directory of mine.
>
>Well, there are "avoidance" techniques you can use.
>
>>|>      This could seem a very trivial issue, if it was not for
>>|>      the following:
>>|>      o  Some users of mine have (and need to retain)
>>|>         *ALL* privileges
>
>There are NO "prevention" techniques effective against fully privileged users.
>
>Having the directory level be at level 9 or lower (to 15?) and accessing it
>via a concealed, terminal logical name is an excellent avoidance technique.
>I've used this in conjunction with recursive directory specifications
>(by $ CREATE/DIRE <.1> and $ SET FILE/ENTER=[.1]2.DIR 1.DIR.  Horrid, eh? ;)
>to really confuse things.  Again, making a pathological directory will stick
>out during an $ ANALYZE/DISK operation.
>[some deleted]
>Other ideas:  You can write a program to set the directory (and enclosed files)
>de-access locked.  I don't know how effective (if at all) this would be, but
>you can $ UNLOCK file when you're ready to use it.
>
>You can munge the .DIR file so that anybody normally browsing your directory
>will receive any escape sequence you can imagine that would disable their
>terminal.  This may discourage casual scanning, and draw the attention of
>"hacker" types, so you can use this technique both as a decoy and as a
>countermeasure.  I put some of these in higher levels of my recursive tree.

I want to warn anyone using "unsupported" VMS techniques like putting the
directory below 8 levels deep, renaming the .DIR to something else (e.g.,
.DAT), or completely munging the directory.

If this information is important to you, then just realize that VMS BACKUP
will "lose" this information in the event of a full disk restore.  Also,
if ANALYZE/DISK/REPAIR (before or after the restore) will place these files
in [SYSLOST].

Just to see what would happen, I used my V5.5-2 system to create a directory
16 levels deep and created a file in it.  This is [X1...X16]XXXX.XXXX

Also, I created [YY]TEST1.DAT and then renamed yy.dir to ZZ.DAT.  Here is
the backup listing that resulted.

*********************
Listing of save set(s)

Save set:          X.BAK
Written by:        S084349
UIC:               [000001,000005]
Date:              22-DEC-1992 11:02:20.98
Command:           BACKUP/IMAGE DISK$VUSER2: DISK$VUSER1:[000000]X.BAK/SAVE
Operating system:  VAX/VMS version V5.5
BACKUP version:    V5.5-2
CPU ID register:   13000202
Node name:         _CRVS02::
Written on:        _$1$DKA200:
Block size:        32256
Group size:        10
Buffer count:      116

Image save of volume set
Number of volumes: 1

Volume attributes
Structure level:   2
Label:             VUSER2
Owner:
Owner UIC:         [000001,000004]
Creation date:      9-DEC-1992 07:39:39.87
Total blocks:      1316751
Access count:      3
Cluster size:      3
Data check:        No Read, No Write
Extension size:    5
File protection:   System:RWED, Owner:RWED, Group:RE, World:
Maximum files:     164593
Volume protection: System:RWCD, Owner:RWCD, Group:RWCD, World:RWCD
Windows:           16
Minimum retention:   30 00:00:00.00
Maximum retention:   30 00:00:00.00

[000000]BACKUP.SYS;1                                      0   9-DEC-1992 07:39
[000000]BADBLK.SYS;1                                      0   9-DEC-1992 07:39
[000000]BADLOG.SYS;1                                      0   9-DEC-1992 07:39
[000000]BITMAP.SYS;1                                    109   9-DEC-1992 07:39
[000000]CONTIN.SYS;1                                      0   9-DEC-1992 07:39
[000000]CORIMG.SYS;1                                      0   9-DEC-1992 07:39
[000000]DEFRAG.DIR;1                                      1  12-DEC-1992 14:36
[DEFRAG]$1$DKA0_PIC.LIS;1                                13  12-DEC-1992 15:33
[DEFRAG]$1$DKA200_PIC.LIS;1                              10  12-DEC-1992 16:56
[000000]INDEXF.SYS;1                                   1062   9-DEC-1992 07:39
[000000]OFFLOAD.DIR;1                                     1  12-DEC-1992 14:41
[000000]PATCHES.DIR;1                                     1  10-DEC-1992 09:08
[000000]SCR.DIR;1                                         1  12-DEC-1992 14:41
[000000]SYSLOST.DIR;1                                     1   9-DEC-1992 07:39
[000000]VOLSET.SYS;1                                      0   9-DEC-1992 07:39
[000000]X1.DIR;1                                          1  22-DEC-1992 10:48
[X1]X2.DIR;1                                              1  22-DEC-1992 10:48
[X1.X2]X3.DIR;1                                           1  22-DEC-1992 10:48
[X1.X2.X3]X4.DIR;1                                        1  22-DEC-1992 10:48
[X1.X2.X3.X4]X5.DIR;1                                     1  22-DEC-1992 10:48
[X1.X2.X3.X4.X5]X6.DIR;1                                  1  22-DEC-1992 10:48
[X1.X2.X3.X4.X5.X6]X7.DIR;1                               1  22-DEC-1992 10:48
[X1.X2.X3.X4.X5.X6.X7]X8.DIR;1                            1  22-DEC-1992 10:48
[X1.X2.X3.X4.X5.X6.X7]X9.DIR;1                            1  22-DEC-1992 10:50
[X1.X2.X3.X4.X5.X6.X7.X9]X10.DIR;1                        1  22-DEC-1992 10:50
[000000]ZZ.DAT;1                                          1  22-DEC-1992 11:01
[]000000.DIR;1                                            2   9-DEC-1992 07:39
[]TEST1.DAT;1                                             1  22-DEC-1992 11:01
[]X11.DIR;1                                               1  22-DEC-1992 10:50
[]X12.DIR;1                                               1  22-DEC-1992 10:50
[]X13.DIR;1                                               1  22-DEC-1992 10:50
[]X14.DIR;1                                               1  22-DEC-1992 10:50
[]X15.DIR;1                                               1  22-DEC-1992 10:50
[]X16.DIR;1                                               1  22-DEC-1992 10:50
[]XXXX.XXXX;1                                             1  22-DEC-1992 10:50

Total of 35 files, 1220 blocks
End of save set

**************************************
NOTE:  All files and directories will not be restored correctly if a disk
	problem occurs.


>
>You can also create files which, when browsed (say, with a $ TYPE filename
>command), will result in the immediate termination of the browsing process!
>(Make sure BUGCHECKFATAL is FALSE).  Such a file cannot be COPYed, although
>it can be BACKUPped.  PRINTing such a file will cause the queue to stop.
>{sudden thought, I wonder what would happen if this poison file were a valid
>directory format, and I renamed it to .DIR.1?  Another avoidance technique!}

Cool... how do you do this?


>
>If you have a MAIL subdirectory, then having extra files in there with names
>like MAILbigfilename.MAI is fairly inconspicuous.  Unless somebody is being
>particularly snoopy, (or using the $ SEARCH command), then this method is a
>decent "avoidance" technique.
>

Now that's a creative way to do it.  Just hope MAIL doesn't decide to use
that MAILbigfilename.MAI sometime - though it may check for this and handle
it correctly, I've no idea how to test this.  (besides I'm sure that the
possibility is quite small)

Anyway, just wanted to make sure people are aware of problems with using
some of the "avoidance" techniques.


-- 
-----
Jeff Sue   
 - All opinions are mine -       (and you can't have any, nya nya nya)