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
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)
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
The SANS have been doing this for years, this is just the updated version of it. Come on slashdot, do at least a little fact checking.
read the post again. Think about what you said. Realize you are bad at comprehension.
This has NOTHING to do with IIS. What the poster said was that IE was installed on all versions. IIS is only installed on some.
There, a quick lesson in comprehension.
I could be running a totally unpatched client that's vulnerable six ways to Sunday, but if I don't surf to your site (or open a local infected file with the client) then I can't be infected.
True, but keep in mind that since Outlook/Outlook Express use IE to render HTML content, email is an attack vector for a lot of IE vulnerabilities. For example, check out the Technical Details sections of these two security bulletins. This is pretty significant, as "open[ing] a local infected file" becomes very easy for the average user to do without realizing it.
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
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
How about - MS can at any time DL and install security updates on your system without your knowledge/input.
And the implementation of DRM in media player upgrades (which if you want 'secure' you need to upgrade).
- 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
at their solutions for the Unix's Weaknesses. That is don't run them. Such as Sendmail. It has accounted for major cracks a number of years ago, but it has been working well for the last 2 years. Do they suggest stopping IIS, or IE, or Outlook, or SQL Server???? No. Personally, if I had a a few millions hanging around or was a lawyer, I would sue a few major companies that got cracked who were running MS.
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=-
If you have ActivePerl installed (recent build) you might want to do the same to the .pl extension, just in case.
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."