Bypassing DOS/Windows Security
by Case
There are certain conditions for bypassing many security measures on DOS/Windows machines. If I can do any one of the following:
1.) Delete, rename, or overwrite any file that is executed (or used by a program that is executed, like config files) at any particular time (boot-up, or during the execution of a particular program).
2.) Prevent a program that is executed at hoot from being executed.
3.) Change the PATH environment variable.
4.) Create files earlier in the path than where the files actually reside.
5.) Boot off a floppy (obviously).
7.) Create a file (usually either BAT or COM) and execute it.
8.) Run MS Word, Excel, Novell WordPerfect (which I prefer), or any other program that has a powerful macro language.
I can probably get a DOS prompt, with network drivers loaded, and probably run unrestricted Windows if I want.
Also, an occasional bug will yield prompt (or the ability to do one of the other items listed above).
Examples
A Windows system had all of its INI files on a server. The usual restrictions were in PROGMAN.INI, preventing me from executing anything other than the icons shown, and preventing me from exiting Windows. Further, Windows was not started from AUTOEXEC.BAT. Instead, it was loaded when the machine logged into the LAN. So, I couldn't remove win from the start-up files. Fortunately, CONFIG.SYS didn't have switches=/n, so I could reboot and hold down Shift (or press F8 or F5) and prevent the machine from logging in.
Even if it had switches=/n, I could have booted from a floppy since the BIOS had A: set up correctly and was set to check for a floppy in A: before booting from C:.
To be able to remove the silly restrictions from PROGMAN.EXE, I needed to be logged in without Windows loaded. Windows wasn't on a local drive, and I couldn't alter the path to point it at another PROGMAN.INI. So, I wrote a TSR that hooks int 21h function 4Bh (execute), same as many a simple virus, and compared the filename to win.
If it found this, it would simply return an error, resulting in the DOS message "Unable to execute win.com." Then I'd be logged in and sitting at a DOS prompt.
Another machine wasn't on a network, but used "Direct Access," a sort of shell/menu for Windows that was supposedly very secure. Direct Access was basically just as restrictive as PROGMAN with the restrictions all enabled. This machine had two other features that made it much more difficult to use: the BIOS was set to boot from C: first, and a silly little TSR (nostop) that prevented Ctrl-C and all varieties of warm booting was loaded from CONFIG.SYS. So, it looked like there was no way to get a DOS prompt.
First, after exploring all the options on the shell, I realized that many of the programs were DOS based. After running a few, I noticed that some even looked like they were run from batch files. But nostop prevented me from breaking out of any of them. I noticed that some of the DOS programs (mostly CD-ROM encyclopedias and such) had options for saving things you looked up.
So the obvious method is to search for a passage of Shakespeare and save it as C:\AUTOEXEC.BAT or C:\CONFIG.SYS or both. Then hard reboot and bingo! DOS prompt.
After using this method, the person who was responsible for making the machine secure made CONFIG.SYS and AUTOEXEC.BAT (as well as just about everything in the Windows and Direct Access directories) read-only. So, I could no longer overwrite any files that were executed on boot-up. But the new AUTOEXEC.BAT executed Windows with simply: win
The AUTOEXEC.BAT is always run from the root and the current directory is always searched first before running any program with COMMAND.COM. Thus, the obvious method is to search for some more Shakespeare (perhaps something from King Lear), and save it as: C:\WIN.BAT
If win is the last line of the AUTOEXEC.BAT, after failing to execute it (COMMAND.COM has no appreciation for poetry) you'll have a nice DOS prompt.
Another LAN machine was configured so that D: (which basically had an image of an untampered C:) was unwritable (via a TSR) and C: (where Windows was executed from) was wiped and restored from D: after each user logged out. Also, some config files were located on a network drive and restored from there instead of D:.
In this case, I couldn't change the wallpaper and have it "stick" so the next user would be greeted by an extra special message, or play net Doom (it sucks from a DOS box).
The first thing to do was to remove the write protection from D: (which was just another partition, by the way), by making a boot disk that had modified versions of CONFIG.SYS and AUTOEXEC.BAT on it, and edit the Windows config files. After doing this, I realized that WIN.INI and PROGMAN.INI were restored from the network. So, no net Doom for me, yet.
Next, I located the file that was responsible for the wipe at each logout. It was an EXE file on D: with a binary config file, and since I didn't want to run Sourcer or IDA on it and reverse engineer it, I decided to rename it. Having done this, nothing was restored on logout and my wallpaper stayed where I put it.
As a side note, these particular machines would go into setup at any time the user pressed Ctrl-Enter, even after many TSRs were loaded. Going into setup crashed Windows though. They also had an option for password protecting either setup or boot or both. Basically, if I was malicious or just feeling pissy, I could make the machine much more secure, prevent the config from being tampered with and reserve it for my personal use.
Conclusion
If you're a UNIX hacker, the methods above probably seem pretty trivial. But, it seems that with so many DOS/Windows machines (many with IP addresses) used at universities, libraries, and other publicly accessible locations, a little DOS/Windows hacking provides many hours of free semi-untraceable Internet access.
Also, since DOS was designed without any security measures built in, once you have a DOS prompt, you can do absolutely anything you want. Including install a keyboard logger, and thereby grab hundreds of valid passwords, PGP secret keys, and whatever.
This is the reason I believe that DOS/Windows machines are the largest security loophole in many large institutions.
Notes
My standard "attack" bootable disk contains:
- SoftICE - The best debugger, can bypass MBR password code.
- DEBUG.COM - From DOS 2.10 (small, doesn't check for version)
- NU.EXE - Norton Utilities Version 4.5 Advanced, better than the new versions.
- DISKEDIT.EXE - Norton Disk Editor - sometimes the new version's better.
- LDE LDE is a disk editor for Linux.
- NLIB200.RTL - Necessary for the previous program.
- Q.EXE - QEdit, don't leave home without it.
- A86.COM - Small and good for cranking out simple TSRs.
- NDOS.COM - Formerly 4DOS, the best DOS shell.
- UUDECODE.COM - Sometimes I have to do a text only transfer.
- UUENCODE.COM - See previous.
- PKUNZIP.EXE - Comes in handy.
- HDIR.COM - HDir, see QEdit.
- CMOSPWD.EXE - Tells me what the BIOS (Award/AMI/Dell) password is, if there is one.