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

This is strange, following up my own post, but I made some statements that
weren't entirely correct.  After more testing here's my results:

In article <1992Dec22.161918.9033@ncsa.uiuc.edu> jsue@ncsa.uiuc.edu (Jeffrey L. Sue) writes:
>
>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].

NOTE: ANALYZE/DISK/REPAIR and VMS BACKUP neither one "lost" the files
	in my example.  They were in the saveset, with "[]" as the directory.

>
>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.
>

My NOTE above is completely incorrect.  All files and directories are
restored during a full disk restore (BACKUP/IMAGE restore).  However,
if a backup /SELECT=[mydir...] were performed to restore my files,
then the files hidden will not be restored.  This effectively breaks
things like SLS or TAPESYS, which depend on the listing and /SELECT
qualifiers to find and restore files.

The surprising thing to me is that using directory levels below X9 does
not cause any errors!  Not even ANALYZE/DISK/REPAIR will point them out.
This does create a neat way to hide files, however anyone who has privs enough
to look around in my directory can also see that I have .DIR files at level
9 and define the necessary logical to start looking in there as well.  In
fact, it might even be more obvious to such a person that I have something
to hide, since he/she can merely do a DIRECTORY:[*.*.*.*.*.*.*.*.*] just to
see if anything shows up.

My definite favorite is using the MAIL$bignumber.MAI to hide them.
Nothing's better than hiding in plain sight.


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