Simtel MSDOS 1992 September

home *** CD-ROM | disk | FTP | other *** search

/ Simtel MSDOS 1992 September / Simtel20_Sept92.cdr / msdos / info / dostips4.arc / DOSSCTY.TXT < prev next >

Wrap

Text File | 1986-06-29 | 16.0 KB | 314 lines

Security Concerns (PC Magazine Vol 5 No 1 January 14, 1986 PC Tutor) One of the consequences of the PC's open architecture is that password security is very difficult to implement. Many corporate PC users live by a simple rule: If the file contains confidential information, it must be stored on a disk and kept in a locked desk. Typically, some paranoia accompanies this rule, such as requiring users to turn off the PCs after using a confidential file so nobody could DEBUG the data out of memory. If your database is much too big and complex for disks, another solution is Iomega's Bernoulli Box. The standard configuration comes with two 10-megabyte drives with removable cartridges. Bernoulli Box access is faster than XT hard disk access, and the cartridges are more reliable, since they cannot crash. Cartridges are removable, easy to back up, and they can be kept in a safe place when not in use. If you have multiple users of a system, however, people may find it inconvenient to fetch a disk or Bernoulli Box cartridge whenever they need to use the database. You could, therefore, replace the XT hard disk with another that is not quite so IBM compatible. Such third-party hard disks generally require a driver program in a CONFIG.SYS file during boot time. Thus, authorized users could be given a copy of the properly configured boot disk. If the machine is turned off after each use, the hard disk could not be accessed without the right driver program. (The Bernoulli Box without the boot option also needs a driver file, but if you left the cartridge itself in the machine, someone could walk away with it.) Another possibility is to use an encryption and decryption program. After using a confidential file, you'd run the encryption program with a password, which scrambles up the file. When you wanted to use it again, you'd run the decryption program with the same password to unscramble it. Low-cost encryption programs are readily available. Such encryption schemes are very difficult to break without knowing the password, even if you should gain access to the decryption program. Moreover, if someone maliciously tries to scramble up the encrypted program, it should be obvious when it's decrypted. To protect against such contingencies, you should be keeping disk backups anyway. Preventing someone from using your PC entirely is a little more difficult. One solutin is a lock switch on the machine, something like the keyboard lock on the PC AT. There are commercial locks that attach to the on/off switch on the PC and XT. Putting a password program in an AUTOEXEC.BAT program does not work at all, since the user can break out of the batch file before the program is even executed. You can put the password program in a dummy device driver. Device drivers are loaded early in the boot process, and it would not be possible to break out of it. However, someone can come along with a bootable disk and boot the machine from drive A:. DO NOT disable drive A: to prevent this. You can, however, install a password program that cannot be circumvented by a drive A: boot. This program has to be executed before the PC even attempts to boot. Here's how it works. When the PC is first turned on, it executes a "power-on self test" (POST) program coded in the PC's ROM BIOS. This program initializes the system, checks memory and ultimately boots the operating system from a disk or hard disk. Before the boot, however, the POST program checks memory locations between addresses C8000h and F4000h for the presence of additional read-only memory (ROM) programs. Generally, these programs are used to perform some extra system initialization before the PC is booted. In fact, the extra BIOS for the XT hard disk is at address C8000h. You would have to program a small password routine somewhere in that memory space where it wouldn't conflict with anything else. Moveover, the program must stay in memory when the PC is turned off. Getting the password program encoded in ROM is a bit extreme. An easier approach is to code it into random access memory on a CMOS RAM memory board with battery backup. (Tecmar, for instances, sells a 32K CMOS RAM board through its Scientific Solutions subsidiary.) CMOS RAM uses very little power -- almost none at all while inactive -- so a rechargeable battery backup should last for many months. The board's memory address would be set up to begin at D0000h, d*000h, E0000h or E8000h. The program must use a special format, which is explained in the ROM BIOS section of the PC or XT Tech Reference manuals under the heading "Adapter Cards with System-Accessible ROM Modules." The code must start off with a 55h and AAh, to tell the BIOS that it is executable. The third byte is the number of 512-byte blocks in the program -- probably 1 for a simple password routine. The program itself begins at the fourth byte, and it must return to the BIOS with a far return. You should write the program in assembly language, and you may not use any DOS calls (Interrupts 20h and up) because DOS will not be loaded when the program runs. You may, however, use all the BIOS resources for the keyboard and display. The ROM BIOS does a check-sum of the bytes of the program and gives you a terse "ROM" message if they don't add up to zero ignoring overflow above 256. So, you're going to have to add up all the bytes in your program, take the negative, and put that byte somewhere in the file. The assembly language program below can get you started. (This program has NOT been tested with a CMOS memory board, but it follows all the rules and should work.) The use of the word "password" for a password is obviously a very poor choice and is used here only for illustration. Note that there is no prompt for the password. Not are the characters echoed to the display. To someone who doesn't know that you've installed this, it will appear as if the machine is broken and will not boot. Note also the nasty CLI and HLT code if a wrong letter is typed. This will disable interrupts and halt the microprocessor, so even a "three-key" restart won't work. Any tamperer would have to turn the machine off and back on to try again. You could omit the CLI to allow use of Ctrl-Alt-Del if a mismatch occurs. You can get more elaborate and allow three retries and asterisk echoes and stuff like that. For testing the guts of the program, you may want to set it up first as a regular .COM file and alter it for the ROM format after it's working. Once you've MASMed, LINKed and EXE2BINed the ROM format program, you must add up all the bytes in it and find the two's complement (the byte that added to the rest will make zero, ignoring overflow above 256). You could write a BASIC program to help out with this calculation. Put the byte in after the CHECK label and reassemble. When you're ready, load the final file into DEBUG and move it to the CMOS RAM board with the command line: M 100 L 200 D000:0 Reboot to test it out. If it doesn't seem to work, you'll have to disable the memory board via a DIP switch and try to figure out what the problem is. Debugging pre-boot ROM routines usually requires specialized tools and is not easy on a regular PC or XT. If this project sounds like the ultimate headache, there is at least one commercially available board (from International Electronic Technology Corp.) that does virtually the same thing. You create an 8-digit numeric password by setting DIP switches on the board. Even though the board method seems pretty good, it is certainly not completely tamperproof. Anyone encountering a PC reluctant to boot could simply open the PC, remove the offending board and restart the machine. You may want to bolt the case down with fancy screws that require a special screwdriver. And don't forget to protect yourself agains the ultimate security problem -- the one where you come to work in the morning and the PC is not there at all. ; PASSWORD.ASM for CMOS RAM ; CSEG Segment Assume CS:CSEG Marker db 55h, 0AAh, 1 Entry Proc Far Mov BX,Offset Pword - 1 Mov CX,8 Looper: Sub AH,AH Int 16h Inc BX Cmp AL,CS:[BX] Jnz NoGood Loop Looper Ret NoGood: Cli Hlt Entry EndP Pword db 'password' Check db ? db (512-($-Marker)) dup (0) CSEG Ends End ----------------------------------------------------------------- Easy Data Security (PC Magazine Vol 5 No 7 Apr 15, 1986 User-to-User) There's a simple but effective method for keeping data on a shared hard disk secure. It won't fool a real expert, but it does screen most others out. The trick is to use the ASCII character 255 either as part of a subdirectory name or a filename. To create a subdirectory that few, if any, users will be able to access, type: MD\SECRET but add a CHR$(255) after the final T in SECRET by holding down the Alt key, typing 255 on the number pad, and then releasing the Alt key. After this has been done, all a snooping user will get by typing CD\SECRET is a frustrating "Invalid directory" message. You can also use this trick with filenames, either by putting the CHR$(255) in the middle of the file or at the end. In this case, users will get a "File not found" message. Editor's Note: This trick will fool most naive users who either won't see the CHR$(255) blank if it's at the end of a subdirectory or filename, or who will assume it's a conventional CHR$(32) space if it appears elsewhere in the name. Not only will unauthorized users not be able to type the contents of such secured files, they also won't be able to copy or delete them. ----------------------------------------------------------------- Sneaky File Security (PC Magazine Vol 5 No 11 June 10, 1986 User-to-User) While various programs on the market can encrypt DOS data files that contain sensitive information, there is one big limitation to all of them -- the user must manually call up the program, specify which file to encrypt, and then enter some sort of password. Pity the poor soul who forgets the password! It would make more sense to build the encryption directly into the program. One simple method would be to add 128 to the ASCII value of each character in the file, but that requires extra code every time the program reads or writes. Worse, it would be painfully slow when processing many records. A better way is to write a Ctrl-Z at the beginning of the file -- before any data is stored. This prevents unauthorized users from snooping with the TYPE command or using the COPY command to send the file to a printer on the screen. But it lets you copy the file to another disk. For a nonprogrammer, the only way to get the data would be with a sector-reading utility like Norton's Utilities. The HIDDEN.BAS program below creates and reads a simple name-and- address file, while demonstrating the technique described. The only compromise is the space lost to the first record. Note that this method will also work when writing a sequential file; however, it must be read as a random file using the FIELD and GET statements. 100 'HIDDEN.BAS -- Reads/writes "hidden" files 110 'First, create "hidden" file 120 OPEN "NAMES" AS #1 LEN=80 130 FIELD #1,22 AS NAM$,22 AS STREET$,22 AS CITY$,14 AS PHONE$ 140 LSET NAM$="Access Denied"+CHR$(26):PUT #1 150 FOR X=1 TO 9 160 LSET NAM$ = "Smith, John" 170 LSET STREET$ = "129 East 14th St. #"+MKI$(X+48) 180 LSET CITY$ = "New York, N.Y. 10028" 190 LSET PHONE$ = "(212) 555-1212" 200 PRINT "Writing record #";RIGHT$(STR$(X),1) 210 PUT #1:NEXT:CLOSE 220 'Show you can still read from "hidden" file 230 INPUT "Which record do you want to read (1-9): ",F$ 240 IF VAL(F$)<1 or VAL(F$)>9 THEN BEEP:GOTO 230 250 OPEN "NAMES" AS #1 LEN=80 260 FIELD #1,22 AS NAM$,22 AS STREET$,22 AS CITY$,14 AS PHONE$ 270 GET #1,VAL(F$)+1 280 PRINT NAM$:PRINT STREET$:PRINT CITY$:PRINT PHONE$ 290 CLOSE Editor's Note: Software manufacturers have been using a variation of this trick for years, putting a copyright notice or a screen full of text at the beginning of a .COM or .EXE file, followed immediately by a Ctrl-Z end-of-file marker. If users try to type the file, all they get is the message. The trick in HIDDEN.BAS works only with naive users. The first thing a typical user would do on seeing an "Access Denied" message is look at the contents using DEBUG's (D)ump command. Or he would write a small program to read the file byte by byte: 100 'Random file reader 110 OPEN "NAMES" as #1 LEN=1 120 FIELD 1,1 AS A$ 130 FOR A=1 to LOF(1) 140 GET 1,A:PRINT A$; 150 NEXT Obviously, you should substitute the name of the file in question for NAMES in line 110. And you can speed things up considerably by increasing the LEN record length beyond one character. Incidentally, while adding 128 (or any other value from 1 to 128) to each character in a file is a very unsophisticated security device, it will also keep casual snoopers away and is simple to do. To try this with the NAMES file created by the HIDDEN.BAS program, simply run the following program: 100 'Trivial encryptor 110 OPEN "NAMES" AS #1 LEN=1 120 OPEN "NEWNAMES" AS #2 LEN=1 130 FIELD 1,1 AS A$ 140 FIELD 2,1 AS B$ 150 FOR A=1 to LOF(1) 160 GET 1,A 170 LSET B$=CHR$(ASC(A$) XOR 128) 180 PUT #2,A 190 NEXT:CLOSE (Be sure the NAMES file you created in the previous example is on the same disk as this trivial encryptor, or it won't have anything to encrypt.) If a user types the contents of the NEWNAMES file, all he'll see is meaningless "high-bit" characters. To unscramble the NEWNAMES file, just run this program: 100 'Trivial decryptor 110 OPEN "NEWNAMES" AS #1 LEN=1 120 FIELD 1,1 as A$ 130 FOR A=1 to LOF(1) 140 GET 1,A 150 PRINT CHR$(ASC(A$) XOR 128); 160 NEXT:CLOSE Instead of using the 128 in the two previous programs, you can substitute any number from 1 to 127, but make sure you do it in both the encryptor and decryptor programs. It's easy to beat such a trivial transposition encryption scheme. To do so, just look at the contents with the DOS TYPE or DEBUG Dump commands. Random access files pad out unused fields with space characters (CHR$(32)). The encryptor file above will uniformly change them to something else. In this example, it will be an a with a dot over it (CHR$(160), since 32 + 128 = 160). It's easy to see these characters padding out fields of different sizes. Once you find the "encryptor" space character, subtract 32 from it and XOR all the characters with the value of the difference. ----------------------------------------------------------------- Security Leaks (PC Magazine Vol 5 No 11 June 10, 1986 User-to-User) A person used the encryption feature of SuperKey to "keep safe" sensitive correspondence on a hard disk. In checking these safety measures, the results were enlightening. In this instance, a well-known word processor was used that produces .BAK files with each new or changed document, and the .BAK files were erased. After a couple of minutes with Norton Utilities, it was possible to unerase these unprotected backup files. Now the person uses Norton's FileWipe program to complete erase backup files or encrypts them before erasing. However, in addition to the visible .BAK files, this particular word processor produced several working files (with .$$$ and .@@@ extensions). Therefore, the person has to use Norton Utilities to unerase the working files and then FileWipe or encrypt them. The moral is that just encrypting the working file is not enough. Make sure all copies of the file are either encrypted or erased with a program that will prevent them from being recovered.