Attacking Linux, Part 1

The movie Tron recently helped put me in the proper frame of mind for a

security discussion -- once you correct the movie's minor flaw of

depicting the wrong side as the heroes. In a nutshell, you (the system

administrator) are in the villain's role in that computerist's classic,

the Master Control Program. Your problem: How do you keep out Jeff

Bridges (the outside attacker)?

Sniff, sniff

The attacker may use specialized network-vulnerability scanners:

Nessus, the older SATAN and SAINT packages, Firewalk (which probes and

identifies a network's firewall ruleset), or proprietary scanners such

as Internet Security Systems' Internet Scanner and Axxent Technologies'

NetRecon -- as well as checking Websites on the target network for

known-exploitable CGI scripts.

Or the attacker may skip the fancy network scanners and concentrate on

stealing one of your passwords. In my experience, that is the bad guys'

usual way in and absurdly easy on most systems. If one of your users

uses Telnet or (nonanonymous) FTP, or POP3 to reach your system

remotely, the user's login name and password can be snagged with

trivial effort at any point between the two machines. Alternatively,

the malefactor may use as low-tech a means as shoulder surfing

(watching the login as it's being typed in), or a variety of social

engineering techniques. People are often astonishingly willing to give

their passwords over the telephone to a stranger with a plausible

reason for asking. Or they email passwords and other confidential data

across the open Internet, ripe for interception.1 At the minimum, the

attacker may telephone the firm to glean people's names and positions,

or get that information from the company Webpages. He may then be able

to predict valid usernames and try them with likely password


Then there are the truly embarrassing password techniques that amount

to walking into an open, unguarded bank vault. There are still services

that ship with default remote administrative passwords, as evidenced by

Red Hat Software's recent Piranha gaffe, as well as sites reckless

enough to use null passwords, the username as the password, or the

username reversed (e.g., toor for the root account). Or the attacker

may use remote techniques to read a copy of /etc/passwd (on systems

without shadow passwords enabled). Many such past exploits have relied

on insecure CGI scripts provided by default with Web servers that are

also unnecessarily running with root authority. (The Apache Web server

most commonly used on Linux no longer ships with either of those


Any attacker who can grab an unshadowed password file has hit the

jackpot because he can then crack your passwords in private, at his

leisure. That is done by automatically encrypting large lists of words

in various permutations and comparing the crypted versions against the

target password entries, looking for matches. The traditional tool for

that task, crack, now has a next-generation replacement, John the

Ripper, with better performance and a broader reach of target

passwords. But the real clincher is the advent of distributed password-

crackers such as mio-star, saltine-cracker, and slurpie, which can make

entire networks of machines work cooperatively on cracking your

password file via those dictionary attacks.

Mr. Insider

Why all that firepower concentrated on cracking your password files?

Because, once the attacker is on your machine, posing as a legitimate

shell user, vastly greater avenues towards total control of your

machine (root access) beckon: he can attempt that through manipulation

of any of your system's privileged programs, instead of just those

advertising remote network services. That is what I call Moen's First

Law of Security: "It's easier to break in from the inside."

If the attacker is not able to pose as a legitimate user, then his

avenues of attack are more limited but still numerous. Every month,

security advisories about new holes in network software are issued,

more often than not in the form of buffer overflows: examples of poor

input validation that permit running attacker-specified code as if it

were part of the program, abusing its authority. Some overflow-based

attacks directly open shells or other direct access mechanisms for the

attacker; others act more indirectly by yielding the contents

of /etc/passwd or /etc/shadow, creating a new account, changing the

password of an existing account, creating a custom .rhosts file, and so


Next Week: Attacking Linux, Part 2


1. In accordance with Moen's Second Law of Security: "A system can

be only as secure as the dumbest action it permits its dumbest

user to perform."

From CIO: 8 Free Online Courses to Grow Your Tech Skills
Join the discussion
Be the first to comment on this article. Our Commenting Policies