SANS/FBI Release Top 20 Security Vulnerabilities
theBraindonor writes "SANS Institute and the FBI have compiled a listing of the The Twenty Most Critical Internet Security Vulnerabilities. The list is broken down into two groups: Windows Systems and Unix Systems." The list of Unix vulnerabilities is also a list of the network programs I (and presumably many others) use most. It's a good thing there's BugTraq.
IIS!!
Not any particular 'sploit, but on the page, IIS is THE NUMBER ONE vulnerability for Windows boxen.
Like Mr. Valentine said, "[Microsoft's] products are not engineered for security". Or something like that.
--j
#8 is listed here.
If you are using IE, your computer is vunerable to numerous security breaches.
If this is installed on EVERY Windows computer by default, I believe that this should be rated higher than those vunerabilities in applications that are only installed by default on SOME Windows versions (IIS).
And if memory serves, the Unix list is exactly the same, with perhaps the exception of Apache. The r* services, sendmail, yep, all still there. Who in their right mind uses r* and sendmail on anything connected to the public internet?
Anyone correct me on whether the others have changed? They all look familiar to me.
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
They are exactly equal because they chose 10 windows exploits and 10 *nix exploits. If they had chosen 20 exploits from both windows and *nix they would have numbered from 1 to 20.
I do security
...is Apache listed as #2 under UNIX? It's not exactly bug-rittled doom-ware like IIS. A few mistakes every now and then hardly qualifies for a #2 rateing. it's not like, 50 new exploits are found a month or something. and as for RPC at #1...you get what you ask for.
They left Outlook and it's derivatives off the Windows list. Nevermind the root VBS cause.
But they seem to have really had to reach to get 10 for Unix.
Man... how much did this 'study' cost?
when a vendor installs an application BY DEFAULT on EVERY single version they ship and it is considered at top 10 vundeability I would say that is more important (see previous comment here) than individual applications that are GENERALLY not installed by default on UNIX based OSs.
.02
Just my worthless
I think every user having the equivalent of "root" by default is probably far worse.
This sig is xenon coated, and will glow red when in the presence of aliens
They forgot to list one of the most obvious ways of breaching computer security measures: social engineering.
If you can get the information that you want (eg passwords) from a person who knows the information, all the patches in the world won't protect your network...
--
http://www.aikiweb.com - AikiWeb Aikido Information
At the end of the document, you'll find an extra section offering a list of the ports used by commonly probed and attacked services. By blocking traffic to these ports at the firewall or other network perimeter protection devices, you add an extra layer of defense that helps protect you from configuration mistake
This seems like a really bad idea. Giving people a list of port they should block traffic to implies that they needn't properly lock down their rulesets properly, andd have accept as the default policy.
Plus, you don't even need to spend on AV software from snake oil vendors.
All that's needed is to make the 'Edit' command the default in the registry for all types of WSH-recognized extensions, such as .js and .wsh. Unfortunately the default is 'Open', which executes the script.
Once you do this you can simply sit there and watch the script worms hit - the only thing you'll see are instances of Notepad all over the place (with the code, to boot). Quite funny (in a sick sort of way).
Free Clue: if you didn't get in on the first 2000 tries, go waste someone else's bandwidth!
take a look
http://www.sans.org/top20/top20_Oct01.htm is the list from 2001
http://www.sans.org/topten.htm is the list from 2000
Version number hiding is not the way to go. And let me explain why: Nimda / Code Red. ISS only. Certain versions of ISS only. And do you think that the virus checks for the HTTP Server-string before it sends it payload? No way. Brute force. Just send the exploit and check later if it was successfull. I have the logs of my Apache webservers to show this behaviour.
Same with the bugbear[sp] worm at this moment. "Check all the shares on the system. Found one! Let's copy to there." Zwoooosh there goes another sheet of paper through the printer.
For administrative purposes, being able to find out what version of software is running is essential. In a company with tens of locations and thousands of computers, nobody will be able to keep a list of software installed on all these things, let alone keep track of the versions.
A weekly scan by the corperate IT department and they know what MTAs and versions are there, what FTP servers and version, what DNS servers and versions are there. An update is released? Just inform the right people (i.e. the LAN administrators, not the people who own these servers). An exploit has become known? At least you know how vulnerable you are instead of panicing and trying to get (obsolete) lists from all over the place.
So yeah, version number hiding doesn't reduce the attackrate but does reduce the ability to act.
bash$
I thought it was kind of amusing, the list being broken up into 2 catagories. Without a doubt, the highest number of vunerabilities are on the Windows side, especially in IE and VBScript. But lets not forget that Apache isnt immune either.. and for that matter, who can forget the infamous sendmail vunerability, and also dont forget misconfigured sendmails from our friends in the East are what allow so many of those cute spam messages we all love so much to get to us. And hell, I can remember stealing password lists with a nice PHP vunerability for years (goes to show that once you get used to an attack, you stick with it).luckily with IDS systems like Snort (http://www.snort.org) companie can monitor attacks as they happen (be sure to compare the size of the Web-Vunerabilities and Virus Rules files with the others...). But either way, the higher count is definitly on the Windows side.
Not only is Apache very widely deployed, it is also quite easy to misconfigure it. If you read the article, they're not talking about software insecurities alone: they're talking about misconfiguration and bad management of machines. For example, weak/non-existant passwords is on both lists.
They're not saying that Apache is insecure but rather that it is a potential risk if the admin is not sufficiently competent.
In Soviet Russia, hot grits put YOU down THEIR pants.
I have to disagree with their evaluation of item W10, Windows Scripting Host. They're essentially blaming it for improper use by mail clients (I never heard of anything other than Outlook or Outlook Express having problems with .vbs scripts run through WSH -- Word macros, while VB, are not VBScript, and don't go through WSH. IE embeds vbscript and jscript, again not through WSH, so while I guess you could download a .vbs, you'd have to be a moron to tell it to run automatically). Sure, they do include the line, "While administrators should always keep applications like browsers, mail clients and productivity suites patched and updated, patching these applications to eliminate their susceptibility to a particular worm is an incomplete (and no better than reactive) solution to the risks posed by scripting," but that's paramount to suggesting all scripting is bad. Would it be bash's fault if mutt auto-ran .sh extensions? Or would it be perl's fault if mutt did the same thing with .pl extensions? No, it wouldn't, so to fault WSH for Outlook/OE problems is pretty ludicrous.
WSH is a very useful tool when used properly, just as bash or perl are very useful when used properly. Misuse by one or several applications does not mean the tool itself is at fault. A better thing to blame would be running as administrator (in NT-based Windows systems) full-time, rather than as a non-admin user. Again, this is directly parallel to running as root 24/7 in a unix system. You wouldn't do it there, so why do it in Windows? (Win9x is dead, let it rest in peace.)
Saying that "The Twenty Most Critical Internet Security Vulnerabilities" is the same as the top ten Windows vulnerabilities plus the top ten Unix vulnerabilities, is just plain stupid.
the "Slashdot Effect" DOS did not make the top 20.
Never answer an anonymous letter. - Yogi Berra
Apache is optimized and was originally designed for Unix. FTP is a standard Internet protocol that likely had its origins in Unix. While the problems you state afflict Windows and Unix alike, they cannot be "traced to Windows." They should be under a generic category for all systems, as HTTP and FTP servers are, in general, large security risks, if caused by nothing more than improper setup.
Misconfigured webservers. Formail.pl, things run using suexec, and other problems are the #1 way to get into a system using a webserver. Chunked encoding and OpenSSL are just core problems, the fact is that most people don't know how to configure it at all.
Obviously there is a large enough portion to support spammers, otherwise I'd not be getting so many requests for formail.pl in my logs (always set to email from some aol.com email address, most recently f2@aol.com, and sending to another fake address, most recently phishtank@yahoo.com, with a subject of my server name and a body of "w00t").
--
Internet Explorer (n): Another bug -- that is, a feature that can't be turned off -- in Windows.
Although the *nix exploits may exist in M$ too, it is possible that they decided that the *worst* M$ exploits were the ones listed. So, maybe FTP is on the list--just at #12 or something for M$. I don't know if I agree with that...but it is a thought...
Do you have a full list of those extensions, or do I need to dig through the "File Types" list?
Boobies never hurt anyone. - Sherry Glaser.
What we need is a greater knee-jerk reaction. A few months ago I got rid of WSH using "format c: /q /u". Now running OSX on new iMac, and old PC is a lovely Linux firewall. I think the top 10 Windows problems might not bother me now. ;)
Top 10 Windows Vulnerabilities:
1. Windows
2. Windows
3. Windows
4. Windows
5. Windows
6. Windows
7. Windows
8. Windows
9. Windows
10. Windows
Table-ized A.I.
The user. Windows OR Unix.
What's in a Sig?
So according to these lists, Linux is 2^20 times better than Windows.
Now just learn to interject "Security through obscurity doesn't work!" and "Security is a process, not a product!" whenever they seem like they might be relevant and you could be a /. security expert like me.
What I'm listening to now on Pandora...
They're all security holes, if they aren't patched. Very few of the things that they listed aren't completely patchable (yes, including IIS). Keep up with the patches, and don't do stupid things, and you'll be fine.
There is no "blaim" intended in making those lists. It's not a "Top 10 programs whose creators and users should be punished for being insecure". It is merely a list to help admins maintain secure machines. As far as these lists go, "fault" doesn't enter in to it, therefore there is no "fair" or "Unfair" to their contents.
Contrary to popular belief, coding is not all free blow-jobs and beer. Those things cost MONEY!
No. Didn't think so.
-WS
An operating system should be like a light switch... simple, effective, easy to use, and designed for everyone.
So what to do with FTP?
The openSSH sftp client really sucks, it's barely usable, no frills, almost seems like a "proof of concept" as it were. It gets the job done, barely.
So our customers need to upload files. With FTP in IE and Netscape and Mozilla, they can drag and drop the files into the browser and log in and send the files.
Another option is to use HTTP PUT, but since our clients are uploading 50 meg files, no progress feedback is a killer there. Is there some open source client-side-java-pretty-HTTP-PUT-uploader out there? Even then you have to have your clients have Java installed, something that can't really be counted on.
Other options.... Put putty on the site and make them install it and use sftp.. Not an ideal option, but somewhat workable.
So where is the drop in replacement for FTP? Why isn't anyone working on this?
I've had enough abrasive sigs. Kittens are cute and fuzzy.
Here's a note I just sent to their web master (they had no other place to send "comments"):
Overall the top20 list is a good summary as always.
However, I can't believe the lack of knowledge about at least the SNMP portion of it. SNMP *used to use* clear-text community strings in the first and second versions of the protocols. The following statement, along with others in the section:
'SNMP uses an unencrypted "community string" as its only authentication mechanism. Lack of encryption is bad enough...'
Is spreading simply incomplete information. At a minimum, it should be suggested that all users upgrade their SNMP enabled software to version 3 compliant SNMP agents and to disable the version 1 and version 2 SNMP protocols. All of the major network vendors, as well as software vendors implement the v3 protocol so there is very little excuse for not using it (and, worst case you can deploy v3->v1 proxies near v1-devices to minimize the transmision distance of clear-text v1 community strings). *Please* change the wording to suggest that people upgrade their equipment to SNMPv3 compliant software, which will take care of at least the insecure problems with the protocol.
The next site to slashdot will be ready soon, but subscribers can beat the rush and start slashdotting it early!
However, 4(w4, w5, w7, w10) of the Win vulnerabilities are integral parts of the OS so you can't remove/fix them without hosing your PC.
Gee, which OS is more secure...looks like *nix again. So no, they are completely different.
I think its rather interesting that bind was included on this list, especially ironic because it was listed as number "9". Bind 8 did have a terrible security reputation, but all of the bind 9 releases have been essentially bug-free. I believe there have been one or two denial-of-service exploites released, but nothing that would bring the internet's name services crashing down. Additionally, bind 9 has the ability to run as the permissions of another user -and- in a chroot'd environment, which makes the box worthless to the attacker even if they are able to break in (can we say "ls: command not found").
"Quoting famous computer scientists out of context is the root of all evil (or at least most of it) in programming." - K
Guess i was wrong. I found this.
Go to --> Administrative Tools --> Local Security Settings --> Local Policies --> Security Options
Select "Additional restrictions of anonymous connections" in the Policy pane on the right
From the pull down menu labeled "Local policy setting", select "No access without explicit anonymous permissions"
Click OK
Users and administrators.
Either base system can be secure or as full of holes as your mother. Apply the relevant patches in a timely manner, and you're mostly ok (so far).
Clueful users do not generally get rooted. In either system.
Given that Win doesn't have group ownership for files, it really doesn't matter if your running as admin or guest. You can still use WSH as a guest and be able to fuck with system files, you just can't play with the registry...nice security model, it doesn't exist for files on Win systems.
Perl on the other hand can't mess with files if the UID for the process doesn't have permission to...ooohhh, file security.
We had to install a virus checker on our Unix boxes at work. In the manual they ask the question 'Why a virus checker for Unix?'. Their reply was 'because of all the Windows viruses'. Seems they thought it a good idea to catch them before they got to the Windows boxes. They are the professionals, I have to believe them.
Just to be a /bot for a second, I thought it was funny that the primary concern with Apache was insecure CGI scripts. And the point about "even Apache's own website was defaced" says nothing about boxes being 0wned. Just a chrooted nobody user account. (And yes, I assume that Apache runs their own server chrooted)
As to the submitter saying the vulnerable UNIX apps are basically a laundry list of apps he uses daily, that's too bad. Never once have I needed to put NFS, rlogin, or FTP into production. I was always taught that the "r" meant "raped".
Intelligent Life on Earth
You'd be right, if your system is using FAT16/32, though why you'd ever use that on an NT-based system (note my comment about NT-based Windows systems, and Win9x being dead), I don't know. Use NTFS, setup proper permissions (should be setup by default, if you installed using NTFS), and you have a better ACL system than the default user/group/other UNIX permission system (yes, I know various unices have better ACL systems, and various filesystems for Linux do as well, but most people use ext2 at the moment, which just does ugo by default -- you can add patches that do real ACLs, but last I checked that wasn't part of 2.4).
Just taking a quick look of C:\Windows on my XP system, I see:
So how is it, again, that Windows doesn't have group ownership?
Actually, my list of 10 would be: IIS, IE, Outlook, Apache, random UNIX services you don't mean to have, sendmail, bind, sshd, plaintext passwords, ftpd. There's only 3 Windows ones, because you can probably break into more Windows boxes than you want to with just those 3. None of the other Windows vulnerabilities matter much, because you can't use them to break into UNIX systems.
I love W5. It implies that the vulnerability is the leakage of information to an intruder.
It seems to me that, since it points out the the scans are often run as "System" by the legitimate users, then by properly crafting a response to an inquiry, and puttting my machine out there, the real vulnerability is to the systems, like the domain controllers, which scan (potentially trojaned) remote machine, without dropping "System" priviledge first.
It seems to me that an exploit using SAMBA source code ought not to be that hard to write...
-- Terry
Nearly all Linux systems and many other Unix systems come with Apache installed and often by fault enabled.
Although I presume that they meant to say 'by default enabled', I (like many others) feel that it is an error to have most facilities enabled by default. Thus the default is IMHO a fault.
I would much rather have various facilities disabled by default, with easily-accessible tools which enable those facilities (and give appropriate security warnings). Manufacturers, like sun, who ship machines with everything and their dogs enabled should be hung by their toes and beaten mercilessly with burnt-out '286s.
The standard defence that most of these systems ship to sites with well-traind sysadmins who know what to disable is silly. If a site has well-trained sysadmins, then they should know how to enable the required facilities. Sites without well trained sysadmins probably don't have good security, either, and most desparately need to have all of those holes covered when the system ships.
For admins who care more about getting a system running easily than they do about security, vendors like sun could have a program (named 'goahead-shootme') that enables all facilities just like the old (de)fault had it. Better yet, of course, would be a simple menu-driven / GUI program that allowed you to turn on/of various facilites and daemons (and possibly even provided an explanation of why). -- Bastille Linux comes to mind...
Sometimes boldness is in fashion. Sometimes only the brave will be bold.
Yes, I have looked at the logs for an Apache server we run at work, and it's hilarious. One can merely politely ask for access to various memory locations. It's a terrible joke; if it wasn't reality, and gaining market share, it would be really funny.
It's been a long time.
Even aside from applications that still limit passwords to 8 characters, wimpy passwords are a real problem. Wimpy root passwords are the worst (do the password utilities still let root assign wimpy passwords?) but wimpy user passwords let attackers break into user accounts, which is a starting point for attacks on more serious weaknesses.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
This is not really a plea for "security through obscurity". It's more a plea for common sense. Feeding disinformation to the black-het crowd is always a good idea. Returning a server string of "jkxyzxpl version 7.35.-1" hurts none of the legitimate users, but it completely hides the server name and version from the bad guys. They MAY be able to overcome the obstacles, but they have to work a little harder to do it. MOST crackers will look for easier targets instead.
utter rubbish
- Buffer Overflows! If people are going to insist on using C to write important applications, they need to use libraries that check input properly if they're not going to do the job themselves! This is about the most basic bug you learn to avoid when you learn arrays, and C's pointers don't give you protection so you're warned to do it yourself where you need it.
- Not Checking Input for Validity! This is about the second lesson in CS100 classes, or was back when I took them - Never Never Never trust that your program has been given correct input, especially input that cares about size and type.
- Not checking for Cleverly Malicious Domain-Dependant Input - OK, some kinds of input checking go beyond the basics, but at least make sure not to let users provide input that uses ".." in directory paths or lets unauthorized people store important data.
- Running things are ROOT that don't critically need to - Mail doesn't need to run as root just to deliver mail to mailboxes - group permissions with the application running as group mail works just fine. Web Servers doesn't need to be root, and DNS doesn't need to be root, and Printer Daemons don't need to be, and most ftp servers don't need to be (a few might). SSH probably does, but there may be ways to work around that.
- Operating Systems that force applications to user root privileges - TCP and UDP well-known ports shouldn't need root permissions to run them, except perhaps in very special cases, and forcing them to have root permissions increases the probability that an inadequately-written application will be running as root instead of chroot-jailed.
- Applications writing over their own configuration files - if you take advantage of operating system permissions, that reduces your need to defend against cleverly malicious input. Be careful out there, and use them.
- Applications that force users to use too-short passwords - 8-character passwords have been obsolete for years. Even if you let users pick wimpy ones, at least don't *force* them to.
That's certainly not everything, but it's an appallingly high fraction. Making sure applications don't run as root doesn't prevent things like mail viruses or web server viruses from flooding the net with bogus emails, but it makes it harder, and reduces the potential damage. At least practice enough basic hygiene that attackers have to be careful, creative, and hardworking....Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
Somebody mod up the parent of this comment.
"lugonn" has apparently never used an NT-based Windows.
That's Media Player, not IE. The two pieces of software are not the same.
There has never been, to my knowledge, any clause in a security update for IE that changed the EULA in such a negative manner.
I wholly agree with flacco that such clauses in security updates are unacceptable.
Web administrators too often conclude that since Microsoft's Internet Information Server (IIS) is exceptionally prone to compromise (see W1. Internet Information Server), the open-source Apache web server is completely secure. While the comparison with IIS may be true, and although Apache has a well-deserved reputation for security, it has not proved invulnerable under scrutiny.
It amazes me how often these vulnerabilities are caused by things that they teach in beginning programming classes, like bulletproofing your code.
C'mon...the snmp one should be thrown off the unix list. Winders has snmp, and network devices have snmp. Just because you can do snmp stuff with Unix doesn't make it a unix vulnerability anymore than a windows one.
As for userid's and passwords - I've seen equally week NT setups - even more common for people to use no passwords on NT, since Win clients are connecting. As for tracking what a user is doing - ps anyone? Lets see you track what an authenticated user can do with RPC on a windows network.
Shatter Exploit?? Come on. This exploit is worse than any of the ones listed.
Those other flaws are weak in comparison to one where someone can own your university network.
-- -=innocent ramblings from the mind of an insomniatic programmer=-
Windows!
:)
deus does not exist but if he does
Hmm. NT Authentication is encrypted. SQL Authentication is not. It's a no brainer to me.
"I will trust Google to 'do no evil' until the founders no longer run it." Hello Alphabet.
You sez:
"...the fact that only one(u10) Unix vulnerablity has to do with
the OS itself, and the rest are program related. All of which can
easily be removed without harm to your boxen."
While the above is TECHNICALLY CORRECT, please remember, when it comes to VULNERABILITY, even ONE is TOO MANY !
Muchas Gracias, Señor Edward Snowden !
The register points to the 2002-09-27 SANS/FBI top 20 most critical internet security vulnerabilities. 2000's top vulnerability, BIND weaknesses, dropped to Unix number 3 last year, and number 9 this year.
CowboyNeal for president!
"Hit any user to continue."
Yeah, and on Unix, Apache is #2, and ssh is #3. It amazes me how hard this seems to be to grasp for most unix administrators...
Well, IIS is no more installed by default on w2k, than rpc, apache or ssh is installed by default on linux systems. I have never had much of a problem not installing either of them.
Well, outlook would have to come before IE. Sure, stupid users can be prompted to execute any trojan in IE (and it has some very bad security faults as well). But with Outlook, you simply send them a mail, and you're in...
Unlike most UNIX-based distributions, Mac OS X client arrives with its root account disabled (users are lower level admins or normal users) and all of its external services disabled by default. The root account can be enabled if necessary, but at least root breaches aren't immediately possible out of the box.
That doesn't make Mac OS X immune from common UNIX vulnerabilities, but it does mean administrators have fewer worries from these systems on setup since Apache, SSL, Windows File Sharing, FTP, printer sharing, Apple File Sharing, and Remote Apple Events are inactive, providing less of a target.
Mac OS X 10.2 finally provides a GUI for its ipfw firewall settings to lock out these ports, automatically preventing these ports from being open unless the user activates the service.
Vos teneo officium eram periculosus ut vos recipero is.
To quote: (for those thinking that the report criticized apache and IIS equally)
"Web administrators too often conclude that since Microsoft's Internet Information Server (IIS) is exceptionally prone to compromise (see W1. Internet Information Server), the open-source Apache web server is completely secure. While the comparison with IIS may be true, and although Apache has a well-deserved reputation for security, it has not proved invulnerable under scrutiny."
Now that that's out of the way. It is very easy to build an active X control that can bypass login sytems on Win boxes. I know becuase this box I'm posting from was cracked that way...many moons ago. File permissions on NTFS mean nothing when the OS controlling them gives full access to programs that are running, even if they were started by a guest/user.
"Flesh(Win) is a trap...and Magic(*nix) sets us free." -Dorthea Swan
i hope somebody gets the inside *nix joke
I meant that the group permissions in Win are a joke, and they don't really protect anything from a serious attack. They were designed to prevent unauthorized software from being installed by non-admins on a domain. It was a convienence thing for admins, not especially for security. They aren't intergral to the OS, just the file system, you can end run around the file permissions through the OS via escalation.
Which is why WSH is dangerous. You don't have to be admin to make WSH start erasing .dll's on the machine. The group settings under windows are for users convienence, not security. It is not group permissions in the same sense as *nix group permissions, it's a cheesy fake-out labled 'group permissions' by marketing dips so they can 'claim' Win is secure. It doesn't really matter if it is or not to them.
However, to get Perl to do admin things on a *nix box, you have to start the process as admin/root/whatever or else it can't access the files, and the OS won't let you escalate. That's security, not marketing spin.