SANS Releases Top Ten Exploits

Lizard_King writes: "System Administration, Networking and Security (SANS) Institute published a list of exploits most often used to gain illegal access to network servers. View the list here." This is really a very good list, compiled from the viewpoint of fixing the potential forthcoming breach. Good work!

Comments

Bad statistical reasoning

[FascDot Killed My Pr]

Don't think of this list as being "most widely used cracks" but as "cracks that have the worst effect". Unix runs the Internet, therefore Unix cracks 0wn the Internet.
--
Have Exchange users? Want to run Linux? Can't afford OpenMail?

DJB's dnscache server/client suite

[kindbud]

You know Dan Berstein as the author of Qmail. Perhaps you did not know that he has also written a secure alternative to BIND, which is quite capable of handling the largest and most active domains on the net. See cr.yp.to.

Important security features in its design:

1. Client resolver is a separate process from the authoritative NS. Reduces damage potential should cache poisoning occur.
2. Client resolver does not cache out-of-zone additionals. For a dot-com domain, it only believes answers from the root servers, the com servers and the auth NS for the dot-com domain, and only if those answers are in the zone it's asking about. More proof against poisoning.
3. Client resolver sets TTL in responses to zero. Helps prevent client mischief. Does not return additionals or authorities to clients.
4. All programs run chrooted as a non-priv uid.
5. Discards all queries in classes other than IN. No CHAOS or HS classes. No "version.bind" stupidity.
6. Its "hints" file is not really taken as "hints". It believes you when you tell it who the roots are, it does not go ask the servers in the hints file who the real roots are.

Design features that are admin-friendly:

1. Authoritative server gives immediate feedback in the event of typos or syntax errors. No grepping log files looking for problems.
2. Erroneous data is rejected. Previous data is used until the error is corrected.
3. Reads zone info directly from a fast database, memory requirements are very small compared to BIND.
4. All zone data is contained in a single database file, which is easily rsync'd to slaves. Zone transfers are supported for compatibility with BIND, but it's not necessary to use it.
5. Client resolver can be set to ask certain servers about certain domains, ignoring the roots. This is great for split DNS setups.

I can hardly say enough good things about Dan's suite of DNS servers and client programs. I will be BIND-free very soon.

This looks inacurate...

[null_session]

I saw this list last night, and my first thought was that it couldn't possibly be right, as most of the compromises on this list are UNIX related. NT accounts for twice as many web server compromises as every other OS combined, even though it holds only 21% of the Internet web server market. (look at http://www.netcraft.com and http://www.attrition.org for verification of these figures) Therefore, the most popular attacks should almost all be NT related. I brought this up to a friend, and he proposed that only the good sysadmins (read:mostly unix) actually either detected the intrusions, or bothered to report them. I can accept that, but I'm interested to hear other opinions.

Re:This looks inacurate...

[jbarnett]

Personally (myself included in this) *nix system admin starting working for a complete *nix server farm, management buys into Microsofts PR engine and decides to bring NT into the picture. These *nix system admins (my self included in this) ared pushed into an NT envoriment without an formal or unformal training and have to try and port their "unix skills" over onto NT adminastoration, some unwilling to expect change and re-learn things for this new NT system, and then that is where the shit hits the fan.

The same thing happens if you put an NT admin in front of a Unix box, or a VMS admin in front of a MVS system. They where trained and self-studied and focused on this "type" of system, then for stupid or illogical reasons (read: managment) the admin is forced into a computer envoirment s/he was never trained or studied in, or even claim to know.

I didn't put NT on my resume, because I don't know it that well and I really don't want to or even work with it. When I was hired for the job is was %100 Unix, they asked me "Do you know how to work with NT?" "Nope", "Would you be willing to learn", "Nope"

I know this is close mind but I am a zealot and have a hard on for Unix or Unix like systems. When put in front of an NT machine I don't know the first thing to do, and have you ever tried to configure an NT box though `command.com` and `vim` (Win32 edition)?

If companies would be highly trained and CLUED NT admins (not *nix admins ported to NT admin) in front of the NT boxes and trained *nix admins in front of the *nix boxes, less exploits would happen across the board.

This happens alot, my freinds old college roomate is an NT admin (and a dam good one) and was working for a company with all NT boxes. He did a good job to, everything worked and it had a tight config. Then management decided to throw in 5 Sun Solaris boxes, and didn't hire a *nix admin for it. This NT Admin (which never put any *nix experince on his resume) was required to maintain these boxes. He got a "Unix for dummies" book and installed Red Hat on his home computer. Now lets think about this, when you where first learning your OS of choice, it was hard and you screwed up a lot, right? Everyone does this ... now put them in a productive envoriment and that is where it starts going down hill.

royally fscking your home PC is one thing, but taking down a productive server in peak hours without a back up is another thing...

For some reason managment has a hard time understanding things like:

NT admins work on NT boxes. Unix admins work on Unix boxes. Perl programers, program in Perl. Visual Basic programmers, program in VB.

It gets messed up in managements head and comes out all messed up.

J(ust)MHO

Good old social engineering

[Old Man Kensey]

...as seen all the time in movies where intruders gain access to the military compound by barking orders and threatening to call superior officers. See also the recent reports of "high security" government installations that were penetrated by a security task force purely through social-engineering their way through the front door.

A friend of mine claims to have had a lot of fun during "interview day" on his college's campus. He was wearing a blue suit and the interview hall was right next to the Naval ROTC building. Apparently NROTC middies (?) don't take chances -- when some guy in a blue suit says "Drop and give me 50!" they figure better safe than sorry.

Half of social engineering is attitude. If you act like you belong there, people will usually assume you do. It's just taking advantage of most people's fundamental desire not to cause trouble. Conversely, running across the office's cranky senior staffer, who's had a bad day and is looking for a reason to take it out on someone, can be really bad news for a would-be penetrator.

Even today, people send spam to AOL customers asking for the user's name and password "so we can repair damage to your account that occurred during a server upgrade" and net thousands of logins, giving them access to that many credit cards, despite the text at the top of the AOL mail window that says "REMINDER: AOL staff will never ask for your password or billing information."

As long as there are newbies, there will be trouble with social engineering. The best you can do is make sure that anybody who administers a system you're dependent on understands the concept of verifying identity.

That all said, social engineering isn't really an "exploit" in the classic sense -- it's merely overly lax granting of access rights, akin to leaving your root account passwordless.

My favorite examples of overly permissive systems were the RS/6000's at UVa, on which all the tty's were permissioned -rw--w--w- (I think this was AIX 3.2 - they upgraded to 4.0 later on with a new crop of boxen and I don't know what they're up to now). That's right, anybody could write to any terminal. I didn't do anything truly damaging with it, just pranked a friend into thinking he was getting a talk request from another person who wasn't logged on at the time...

How to secure your Linux system

[Kiwi]

Since we are talking about security here, here are some things Linux (and other UNIX) admins should keep in mind to keep their systems secure:

• Use qmail or postfix instead of Sendamil.
• Make sure you have all security patches for your system installed. Redhat users, for example, can find those patches here.
• Linux users can read Linux weekly news for security updates.
• Manage your SUIDs. Make sure you keep a close eye on all your suids. For example, I use this script to put all my suid in the directory /suid/bin:

  #!/bin/sh
  
  find / -type f -perm +6000 > /root/suids
  
  for a in `cat /root/suids` ; do
  

  mv $a /suid/bin
  ln -s /suid/bin/`echo $a | awk -F/ '{print $NF}'` $a
  

  
  done
  
• Obviously, turn off all unneeded network services in /etc/inetd.conf and (usually) /etc/rc.d/rc3.d. You can see what services are running on your machine with netstat -na.
• For a UNIX that is free and (hopefully) secure out of the box, check out OpenBSD or Trustix.

The advantage of an open-source solution is that we have greater control over our systems, and can better optimize our systems for security.

- Sam

Password Sniffing

[The Dev]

This list completely ignores one of the most common security flaws in computer systems: Cleartext passwords sent over the wire.

Even using ssh is not enough if you still use ftp or imap. Assume those accounts are compromised.

And here are the other lists.

[StenD]

I've been told that they will be on the SANS web site Real Soon Now.

Mistakes People Make That Lead To Security Breaches

Technological holes account for a great number of the successful break-ins, but people do their share, as well. Here are the SANS Institute's lists of silly thinks people do that enable attackers to succeed.

The Five Worst Security Mistakes End Users Make

1. Opening unsolicited e-mail attachments without verifying their source and checking their content first.

2. Failing to install security patches - especially for Microsoft Office, Microsoft Internet Explorer, and Netscape.

3. Installing screen savers or games from unknown sources.

4. Not making and testing backups.

5. Using a modem while connected through a local area network.

The Seven Worst Security Mistakes Senior Executives Make

1. Assigning untrained people to maintain security and providing neither the training nor the time to make it possible to learn and do the job.

2. Failing to understand the relationship of information security to the business problem-they understand physical security but do not see the consequences of poor information security.

3. Failing to deal with the operational aspects of security: making a few fixes and then not allowing the follow through necessary to ensure the problems stay fixed

4. Relying primarily on a firewall.

5. Failing to realize how much money their information and organizational reputations are worth.

6. Authorizing reactive, short-term fixes so problems re-emerge rapidly.

7. Pretending the problem will go away if they ignore it.

The Ten Worst Security Mistakes Information Technology People Make

1. Connecting systems to the Internet before hardening them.

2. Connecting test systems to the Internet with default accounts/passwords

3. Failing to update systems when security holes are found.

4. Using telnet and other unencrypted protocols for managing systems, routers, firewalls, and PKI.

5. Giving users passwords over the phone or changing user passwords in response to telephone or personal requests when the requester is not authenticated.

6. Failing to maintain and test backups.

7. Running unnecessary services, especially ftpd, telnetd, finger, rpc, mail, rservices

8. Implementing firewalls with rules that don't stop malicious or dangerous traffic- incoming or outgoing.

9. Failing to implement or update virus detection software

10. Failing to educate users on what to look for and what to do when they see a potential security problem.

And a bonus, number 11:

Allowing untrained, uncertified people to take responsibility for securing important systems.

Top Ten Ways to Get Slashdotted

[levendis]

1. Claim to be running a web server off a Palm Pilot, furby, Commodore 64, or even a bunch of potatoes. (Bonus points if its a port of Apache).

2. Write an article on DeCSS, Napster, MPAA, RIAA, and/or Metallica.

3. Publish a benchmark comparison of Linux and Windows, making sure that Windows scores best in all categories. (Bonus points if your test team is made up of 12 MCSEs and 1 dude who installed Red Hat 5.2 once before).

4. Title your article "X Violating the GPL?" It doesn't matter what the article actually says; it could just be a description of ancient Bulgarian goat herding. You're sure to get all the Slashdotters riled up regardless.

5. Write something about "Geek Sex".

6. Produce blurry, unenlightening satellite pictures of a secret government compound. Bonus points if the site mysteriously disappears in a few hours - the paranoid Slashdotters will have a field day with that one.

... all out of ideas... anyone else?

What /. wanted to see....

[blogan]

While alot of items on the list were UNIX/Linux, they did have a few Windows problems. I think it's probably because they would've felt ashamed to put what the slashdot community wants to hear.

1. MCSE.
2. NT admins without MCSE.
3. NT admins without a driver's license.
4. NT users.
5. VBScript.
6. .bat files opened without examining content.
7. Running files from http://www.geocities.com/..../3488/kewlstuf.htm as "admin" on NT systems.
8. Giving out admin password on Comic Chat to "AdminDood283" to help you out with constant down time.
9. Innovation anal probes.
10. Putting NT server in a kiosk and still logged in as "admin".