- UNIX Security Issues
- Basics 1: The Intruder's Goal
- Basics 2: Password Banging
- Unfinished Business
Basics 2: Password Banging
We've all seen nice posters asking people to choose complex passwords. But that's a lot of trouble, so there might be a few guessable passwords among all the good ones.
It gets worse. Come with me on a casual stroll among the workstations and PCs. Few screensavers are enabled. Monitors bloom with yellow "stickies" announcing machines and passwords, their daisy-like faces welcoming the afterhours visitor. If this is your company, complain loudly now. Passwords still represent the most-used authentication credential. It's almost fun, pointing out that users commonly synchronize passwords across many machines nowadays. Get one password, and the intruder may have one that works on a few servers, even on a few platforms.
Some of those "stickies" look pretty old. They've been in production for a few hundred users for a few years, and no one has the courage to force a change. Intruders know they can trust those passwords to be intact and unchangeable no matter what they do with the account in a privilege escalation attack. The security person may argue to change the password, sensing an attack, but no one will want to follow that advice.
So far, with nothing more than a stroll, an intruder may have gained a half-dozen passwords. But this is only the easiest way to learn passwords; intruders often try more complex ways when there is no physical access.
Getting a foothold on a UNIX machine provides a lot of information, so many intruders begin "the quest for guest" early on. Many scripts make the complex task of tackling a large enterprise easy. One file has a bunch of machine names, and the script goes knocking on doors, seeing whether guests are permitted. How about some of those default accounts and passwords that come with applications? Are they honored, or changed? People complain about SQL Server's SA account, but UNIX has those problems also.
A password-checking script knocks twice on each door, announcing itself as many types of accounts, often providing the kinds of simplistic passwords users love: Mar98 or Packers! (yes, these scripts anticipate substituting punctuation marks for numbers: Packers1). With little effort, the environment is combed for some landing, some foothold on the Gibraltars that litter the computer room. The good scripts knock just twice; three failed logons often lock an account and notify folks that someone is strolling along the ethernet paths.
Has your company had layoffs? After big layoffs, many accounts aren't used—empty houses, but still capable of raiding—with no one to complain or care if the account is locked. In some companies, you'll find lots of blank passwords, guest accounts, and silly default accounts with default passwords.
Security investigations often reveal a chain of compromise and not just one portal. Many servers are a joke. The default build for users put most into a default group: Users. The default permissions are set 755, which means that all group members can read every file in every home directory unless the user specifically secures it. (We'll discuss specifics in later articles.) Sometimes you can actually find a box with 775 permissions! It's often an FTP server and web server, and the administrators don't know how to turn on the group write bit for the web site content directories only. They just reset the system umask, and the customers are happy because most don't know anything about UNIX file permissions. (The significance of this problem will be explained later.)
A few machines are 777, which means that they're open to any action done by anyone with access to a system that has blank passwords. Once on this system, all kinds of damage can be done.