Slashdot Mirror
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!
Really you can never know if you are currently vulnerable with a system that's been active for ages. As Rootprompt.org's Cracked! series of articles shows, the first thing script kiddies and crackers do is start replacing standard system utilities. I've seen on Linux various hacks to hide processes, kernel modules, etc. So just doing lsmod suddenly means very little. :)
Your best bet is to start with a fresh install. I'd say there's 99.99% chance that your standard Mandrake, Redhat, Debian, etc don't have these rootkit bins on their CDs. I have taken to running tcpdump on my little ppp connection (damn phone company refuses to put DSL here) whenever I am online. It is quite interesting seeing just how many attempts people make to various things, SMB is the most common, telnet, linuxconf, imap, etc are all attempted.
Perhaps the best method would be to find an old 486, P90 or whatever, and run one of those floppy setups like the Linux Router Project. Poke a couple holes for the services you need to pass through to a full Linux server (web, mail, etc). With the system running fully in memory, any bins a cracker replaces get restored by a mere reboot. And by having a very limited number of bins on the system, that gives crackers vastly less chance to successfully getting into your system. You will still have to keep abreast on security notices for the things you do have.
A good read on the damage one cracker can cause with a sniffer, check RootPrompt's Cracked! series of articles.
I never said I was. In fact, for all you know I might be a raving postfix fan, or maybe I've written my own mailer in 80 lines of awk and refuse to use anything else. The point is that the post was based on personal bias. To get back on topic somewhat, it should be noted that the sendmail exploit described in the list is for a version that shipped years ago and has since been superceded many times. Invulnerable? Surely not. But I am willing to trust the recent versions. I'm certain that if another mailer was as widely used as sendmail the reward would have been paid many times over by now.
One workaround for this is to use ssh tunnels for things like an IMAP connection. Although, obviously the long-term fix is for all sensitive daemons to use encryption. I hope the expiration of the RSA patent in September makes this easier to implement.
--
Your best bet is a Virtual Private Network.
kindbud wrote:
I can hardly say enough good things about Dan's suite of DNS servers and client programs.
Having gone through the annoyance of administering a qmail site, I don't suffer from this disability.
dnscache, dnsfilter, tinydns, pickdns, walldns, rbldns, axfrdns, axfr-get, and the sundry associated libraries are just yet more screwball non-free software from Bernstein: He can keep 'em, and all his other non-FHS-compliant offerings. If I switch to anything, it'll be the GPLed Dents package.
Rick Moen
rick@linuxmafia.com
I found out when I noticed that /root/.bash_history was linked to /dev/null. DOH!
Ok, ok, a more realistic danger: not caring about security. It's one thing to say, "yeah, we're secure," just because you don't think you've ever been hacked. It's something completely different to actually have someone look around for exploits to use against your site or products...
More often security is perceived to be "costly". Companies that are slaves to the accounting department see what looks like a lot of money spent on a non-revenue source, so the budget gets cut.
Then the admin(s) don't have the manpower and/or tools to do the job properly, so when something bad happens the finger gets pointed at them as "inefficient" and they're fired en masse.
Then a whole new crop of freshly-minted "security experts" come in, with no idea where the grue in the system is lurking and waiting to eat the unwary who insist on pressing ahead into the darkness.
(This is obviously an extreme case, but companies run by beancounters do essentially this kind of stuff all the time.)
Then something really nasty happens and the company gets a lot of bad press over it, after which the severed heads end up stacked chest-deep at the main gates and the drains are clogged with the blood of the accounting department. OK, the last part never really happens, no matter how much the original team wishes it would.
An alternate scenario is a company whose marketing department or top management is actively antagonistic to strong security, perceiving it as a stumbling block to customers or themselves, respectively.
And sometimes you get management who, despite having zero actual knowledge of security practices, think their rank in the organization translates into authority to set security policy. This is a recipe for disasters that make the other two possibilities look like playtime on Romper Room.
-- Old Man Kensey
Hmm, the 8.22-P5 bind can be found on rpmfind.net, if you want rpms... Made by redhat.
I have seen *good* NT admins who understood the strengths and weaknesses of the system do some great things. And the same with *good* *nix admins. I think the reason NT gets such a bad namme is that the GUI makes it too easy to *think* you know what you are doing without understanding what is really going on in the background. There are a lot of mediocre NT admins who don't know that there is more to the system then rebooting it.
The second problem is that most (not the good ones) NT admins believe that the box can run an infinite number of services all at the same time without effecting the system. Hah. NT is very stable if you do a default install, patch it , run 1 service, and leave the monitor disconnected so it is harder for a junior admin to try to install a new screen saver :-)
BTW, before the coyotes nip at my heals I am a Sun/Linux/AIX admin, not NT... just work in the real world where you use the best tool for the job.
Can't sleep, clowns will eat me....
It's incredible to see the 8th reason is:
8. User IDs, especially root/administrator with no passwords or weak passwords.
The worst of this is, if an admin uses a blank or weak password for the admin user or install services with pre-installed passwords, it's very possible that this admin will never take care about patching or fixing the other affected services in the list, so their hosts can be a real mess.
Another thing to note is the more or less common proposed fixes in propietary systems (disable the service, like in IIS) and the solutions offered for free systems (upgrade to bar version or use foo patch).
Destination unreachable can be used to confuse some routers ... check on bugtraq archives for more info (dynamic routing?)
.. if you dont need it, why enable it?
ICMP is generally a bad idea, as it is not necessary for core services to run, and can be used to sniff system settings out
--
Anil Madhavapeddy, http://recoil.org
The Five Worst Security Mistakes End Users Make
:). If this was in the IT section, I might be inclined to agree with you. However, end users tend to use a modem for one of two reasons - to connect to Internet resources their firewall blocks, or to get them into their system without a VPN or sanctioned dial-up.
5. Using a modem while connected through a local area network.
Hmm? What's wrong with being connected, as long as you don't allow incoming connections from the Internet? Setting all your daemons to only bind to eth0 isn't that hard, once you've disabled the ones you don't need anyway.
I readded the heading from that section (I should have put the headings in bold, but I didn't think of it in time
In the former case, they typically don't do anything to protect themselves or the corporate network - they just use DUN to connect to their ISP of choice.
In the latter case, they will usually stick PCAnyware or something similar on their system and set it to auto-answer, with a poor (or no) password.
In either case, the end user has made the network security like a chain link hospital gown - string from in front, but baring all.
--
http://www.aikiweb.com - AikiWeb Aikido Information
Mention two Linux companies merging.
Mention Microsoft acquiring anything, even if Bill Gates just acquired a box of cereal for his morning breakfast.
Mention the words "Open Source." Anywhere. (Note -- this has worked. I've posted two articles, one that mentioned Open Source and one that didn't, on the exact same topic. Guess which got accepted =P)
Use a three-letter acronym, such as RMS or ESR. It doesn't matter if it has any relevance to anything you're talking about.
-- BlueCalx | http://nickd.org/
This breaks down the # of known vunerabilities, not the number of unpatched ones. Linux is open source, and new exploits are pointed out, discussed, and patched almost daily. Searching the source is the easiest way to find an exploit, so what I'd like to know is why NT/95 show equivalent numbers? There must be far, far more potential exploits for them.
.sig: Now legally binding!
But there are fewer and fewer exploits in the 'stable branches' For crying out loud, there are currently two activly patched stable trees and one unstable! I'd doubt you could even find a working exploit in 1.2.xx or 2.0.xx!! (Unlike Windows 95, which is of the same vintage, and still has some nagging exploits from as far back as 1997.)
BSD and Debian are different. They've been sitting in 'beta' forever, feature frozen, much like their commercial counterparts. The same commercial counterparts who can't keep their numbers below a known unstable..
And all those counting on the new kernels to be bug free are fools. You need secure, use the LAST stable branch.
.sig: Now legally binding!
>I also think sendmail seemed out of place on the
>list. There hasn't been a root exploit on
>sendmail in what, three years?
The problem is there are still 10's of thousands of systems out there (mostly old Sun workstations and the like) still running vulnerable versions.
>ICMP is generally a bad idea, as it is not necessary for core services to run, and can be used to sniff system settings out .. if you dont need it, why enable it?
Because its an essential part of the protocol. As said before ICMP unreachable is used for MTU discovery. If you block it all, things will break. Furthermore it can be very usefull to see if a host is up with ping. Like all things with system/network administration you must know what your doing. Filtering out suspicious/dangerous ICMP is good (you don't want your network to become a smurf amplifier for example). Blocking everything is bad.
What you are saying sounds to me like: "Power steering in cars is generaly a bad idea, it can break at the wrong time.. if you don't need it, why enable it ?
Because it's fscking usefull
A big part of this is that places like L0pht make programs for the Windows exploits, which means any kiddie can use a simple program to find and exploit the problem. There are far less of these programs for *NIX exploits (either because the *NIX exploits would be harder to create a program for, or because more people hate MS and focus on them). Just because it's popular to bash MS doesn't make it a fact everything said about MS is true.
"Information wants to be expensive" - Stewart Brand, the same guy who said "Information wants to be free"
Huh. Now all they need is to post the sploits. Then we'd have even more ereet kiddies running around.
Any halfway-competant script kiddie knows to read Bugtraq and NT Bugtraq. SANS didn't need to produce the exploit. Anyway, they were pretty vauge in places (especially about the POP/IMAP vulnerabilities).
Last time I tried an exploit, it was a real mess. People screaming, parents covering their kids' eyes, the embarassing arrest by the cops....
Wait, I'm thinking 'exhibition'. Nevermind.
-Denor
Read this before deciding to use postfix.
Edith Keeler Must Die
Is that these holes still exist on systems because admins are being LAZY. Lazy thinking 'I am running a *nix-based system and therefor I am more secure than Winblowze.'
...
Here's a nice reminder: if you aren't constantly working on your security, SOMEONE ELSE IS! And I am not refering to your assistant admin, either.
Maintaining box/network security is a full-time job. And its a case of constant vigilence. You cant operate on the rules of it 'cant happen to me.' One look at Attrition.org's mirror site should prove you otherwise.
So take this as a wake up call. Before you get woken with a call
*more ramblings - can you tell its a slow day at work?*
Check out Magic Firesheep!
- 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.
Sigh. We've been losing this battle for twenty years now.It should be safe to run untrusted executable code because such code should be run in a sandbox enforced by the operating system and the hardware. By this I mean a set of restrictions similar to those applied to sandboxed Java code.
Browsers don't need much in the way of privileges. The worst that should happen because of a security hole in a browser is that the browser's current state and cache are messed up. Restarting the browser and flushing its cache should cure any problems. Preferences should be changed through a separate program that the user can invoke, but the browser itself can't, and should be stored in a compartment the browser can't write.
Office has to do more, but only a few parts of Office need to be trusted at all.
Neither a screen saver nor a game needs much in the way of privileges.
If you are worried about rootkits (like a fake version of top, who, users, w, etc) you can reinstall those program from you read-only installation medium (ussually a cd-rom) or download and compile them directly from the site (ftp.gnu.org is a great place to start) and turn on a hell of a lot of logging and see if anything pops up.
If you aren't sure or not, backup your data (not programs or config) and reinstall, get lastest patches, configure, secure, test then bring back online
Ussually with linux, if you had your system online for a year, you might want to upgrade any way to your current distro lastest version, just to get the newest and coolest feartures. (Note newest and coolest feartures will have bugs (Note some bugs can be exploited for malice purposes))
If you are unsure, check it out. It is better to find no security holes, then "think" there is no security holes.
"`Ford, you're turning into a penguin. Stop it.'" -THHGTTG
There was notice sent to Bugtraq several weeks ago. The text of it is below.
p /wkshp/download.htm
L WARE.chm");',15000);
Date: Mon, 15 May 2000 18:37:31 -0700
From: "http-equiv@excite.com"
To: BUGTRAQ@SECURITYFOCUS.COM
Subject: MICROSOFT SECURITY FLAW?
Saturday, May 13, 2000=20
MICROSOFT SECURITY FLAW?
Silent delivery and installation of an executable on a target computer. No
client input other than opening an email or newsgroup post.
1. Using the following this can be accomplished with the default
installation of Windows 95 and 98 and Internet Explorer 5 browsers and
accompanying mail/news clients
2. The key component from Georgi Guninski=20
http://www.nat.bg/~joro/wordpad-desc.html
3. Secondary component comprises a pre-installed ActiveX control directly
from Microsoft. This control and a variety of similar demonstrations have
been shown to Microsoft over 18 months ago
What to do:
A
(a) Manufacture a *.chm file. The following kit from Microsoft is free and
very easy to use Microsoft=AE HTML Help:
http://msdn.microsoft.com/library/tools/htmlhel
(b) Construct a new *.chm file inputting the ActiveX link control as
follows:
AA.Click();
=20
(c) The control itself is quite sensitive to manipulation, the above
represents the bare minimum to run.=20
(d) Input the path of the executable you intend to run as in PARAM
name=3D"Item1" above. In order to disguise the running of the executable it=
is
suggested to not to give it a silly name, rather something that is familiar
to the operating system e.g. microsoftagent.exe etc.=20
(e) While constructing the *.chm, it is possible to both minimise and offse=
t
the location of the *.chm file once opened. For example while under
construction you can set the size of the help window and its location -
using the auto resizer in Microsoft=AE HTML Help, drag the sizer to the
smallest possible size. Although setting the size requires clicking OK
inside the autosizer, dragging to minimal size and hitting ENTER will
register the setting. Secondly offset the location of the file by inputting
say 2000 , 2000, this should suffice in it opening off-screen on any size
monitor.=20
(f) Once you have compiled the *.chm test its functionality by placing the
executable in your temp file and open the *.chm - it should run the
executable.=20
Now how do we place this on the target computer?
B.
(a) Simply by opening an email message or newsgroup post. The client does
nothing. They receive an email open it or read a newsgroup post and that i=
s
all. Both the *.exe and *.chm are transferred silently and immediately to
the temp folder once the email or newsgroup post is open.
How so?
(b) It is possible to embed almost anything in both html email and html
news. Current versions of Outlook Express 5 inspect what is being embedded
is in fact the correct file e.g. will not embed becau=
se
a *.doc is obviously not an image file. Internet Explorer 4 and accompanyin=
g
Outlook Express 4 does allow for this, similarly Netscape Messenger also
allows for this. Nevertheless, through proprietary JavaScript and VBscript,
it is possible to deliver an intact file to the target computer's temp
folder, however with a file name given by the computer e.g. 000321.doc. Thi=
s
does not serve the purpose of running the *.chm with the file name explicit
as above.=20
(c) The Microsoft Active Movie Control (AMC) pre-registered and
pre-installed on all Internet Explorer 5 computers does. The very simple
scripting to do this is as follows:=20
=20
(d) This control too is very sensitive and the complete path must be
inserted in order for it to embed in the html email message or html news
post.
(e) Finally, in the body of the html email or html news post the following
simple JavaScript is required to set off everything:
setTimeout('window.showHelp("c:/windows/temp/MA
Sufficient delay must be allowed for the news post or email message and
transference of both the executable and *.chm files to be delivered to the
target computers temp file before execution is called.
What will happen?
When the email or news post is opened, the embedded *.chm and *.exe will
automatically and silently be transferred to the client temp folder, intact
and with the given names. Default locations on all machines calls for the
temp folder to be at C:\windows\temp. The AMC control, will deposit the two
files to wherever the temp folder is located, if you have changed the
location, these two files will still be delivered there, however because th=
e
*.chm file is constructed to seek out the *.exe in the default location, it
will fail. Likewise so will the script in the html email message or news
post. Hence, this will only work on default OS installs.=20
Once the news post or email has been opened or even previewed via Outlook o=
r
Outlook Express preview pane, the two files are delivered to the temp
folder, sufficient time elapses when the script in the html message calls
the *.chm which opens silently and minimised in the task bar (because we
have instructed it to open at the minimum size and off-set 2000, 2000), onc=
e
opened it, the ActiveX link control in it, runs the executable.=20
Everything is instantaneous, no need for a reboot and no need for user
interaction other than opening the email (or simply previewing it) or the
newsgroup post. Needless to say once the executable is running, the damage
is done. And no Windows Scripting Host (WSH) involved.=20
The only solution is to relocate the temp folder and/or set scripting and
ActiveX controls to the highest possible settings. The default settings do
not ask for permission.=20
Below represents a working example. The executable incorporated is a
harmless joke program. In order to run it, save the entire example as eithe=
r
*.nws or *.eml and click on it:=20
note: 1/ on high speed machines and i-connections with IE5, clicking the
links below will allow for viewing of these news and mail files in the
browser (technically known as mhtml), with the same effect. Slower machines
and i-connections might want to save to disk and open from there.
Additionally saving to disk and opening will allow for viewing in the mail
or news client.
note: 2/ it is not necessary to run this through html mail or news, applyin=
g
all the above directly on the web results in the same.
Right-click and save to desktop
Mail: http://members.xoom.com/malware/help.eml 89KB
News: http://members.xoom.com/malware/help.nws 89KB
=20
=2E
Hmm. I have two problems with your argument.
First, the Netcraft survey you cite makes no attempt to correlate IP address to MAC address. The vast majority of IP addresses are on multi-addressed boxes in ISP server farms; those boxes tend to run Unix or Linux. This has two consequences: first, we can't determine the relative frequencies of NT boxes and *n.x boxes on the net, and, second, we can assume that the ISP farms are reasonably well-secured. (After all, that's what they do full time.) This would tend to indicate that NT sites would be more likely to be administered by people who aren't quite as attuned to keeping up with the necessary patches, and hence would be more likely to be vulnerable.
Second, though, these vulnerabilities refer to machines on the network generally, and not to web servers in particular. So the frequency with which IIS-based servers are compromised has little or nothing to do with the vulnerabilities of the systems on the Web. How many people still run naked Win98 boxes with always-on connections? Similarly, how many people run unhardened Linux on the network? These vulnerabilities are still there, even if they're not visible on attrition.org.
This list is a bit misleading. You'll notice that they give a BSD(aggr) and Linux(aggr). That means that they're lumping together all flavors of BSD into a single category, and all Linux distributions into a single category (although they do count an exploit only once if it appears in multiple distros).
That means that if RedHat has vulnerability A but not B or C, Suse has vulnerability B but not A or C, and Debian has vulnerability C but not A or B, Linux(aggr) is counted as having three exploits. In reality, if you're using just one distribution you'll only experience one of the three, and Slackware might not have any of those exploits.
The following looks a lot more favorable for Linux:
OS 97 98 99 00
Debian 2 2 29 5
RedHat 5 10 38 17
Slackware 3 8 10 0
Suse 0 0 21 5
Win NT 4 6 99 37
There's no point in questioning authority if you aren't going to listen to the answers.
An excellent point. There is only one problem, however. I have been an NT admin for 5 years. Currently I work for a consulting company, and am one of the few NT people willing to do tech reviews. In the last year I have done over 100 tech reviews for NT admins, with probably 50% of them having an MCSE. Out of that 100, only two have I recommended for hire. My point is only that while I agree that a quality NT person can get an NT box running pretty reliably and securely, there are VERY FEW quality NT people out there. Most of them, as you said, are just too comfy with the GUI to learn anything about the system. (and here is a simple question for all of you hiring types: What is the difference between regedit.exe and regedt32.exe? answer: regedit.exe enjoys a better search engine, but only regedt32.exe can edit the registry key permissions. - if someone can't answer this, they haven't a clue about NT security) The two I recommended for hire were the only two able to answer that question. I would say about 30% didn't even know what patch level their servers were at. And just in case you didn't know, the MCSE teaches NOTHING that is important (hot fixes and security are NOT part of the curriculum, although I think this is starting to change for 2000).
I hope my point was obvious, even though my grammer sucked.
Politics, Culture, Food?
What ever happened to sheer user stupidity? Calling employees in a company and asking them for their username and password... Especially in a university/educational setting with poorly trained and underfunded technology groups.
Hello?
Yes, this is (technology support group name) calling, we're currently working on testing a (fancy acronym here) upgrade, and we were wondering if you could help us. We'll need your username and password...
--You will rephrase your request for me to go to hell. Goto statements are not acceptable programming constructs
It's very slow (don't slashdot it please) but you may want to check out/ stats.html
/. Linux freaks will be suprised as to where Linux sits in (hint pretty much the same as Windows). Here's a small snippit before everyone slashdot's the poor website...
http://www.securityfocus.com/frames/?content=/vdb
What they've done is count up the number of root level compromises on a per OS level on the bugtraq mailing list and ordered them up on a per year basis. Most
OS 97 98 99 00
-------------------
BSD (aggr) 8 8 26 7
Linux (aggr) 10 23 84 30
Win 3.-98 1 1 46 13
Win NT 4 6 99 37
Further down the page Linux gets some better positioning as it breaks down categories, etc.
posting these isn't going to hurt security meaures at all. crackers already know all these holes, thats why their crackers, and most network security sites(and hacker/cracker sites) maintain a list of exploits far more comprehensive and specific than this. However, taking the advice in this article will make 90% of those exploits useless, making it that much easier for sysadmins who dont spend a lot of time securing their systems and just want a few tips to help secure their systems. Very good job by sans.org i think.
The biggest omission from the list was wuftpd <2.6.0 (and derivatives). This deserved to be number 2 on the list, after BIND, as it shipped enabled by default on every RedHat up to 6.0.
I generally recommend that Linux users replace wuftpd with ftpd-BSD, the Linux port of OpenBSD ftpd. It's not as featureful, but it's a lot easier to use, and the code has been audited.
I also think sendmail seemed out of place on the list. There hasn't been a root exploit on sendmail in what, three years?
--
Up until a few months ago I was doing some sys admin work. At the time I was pretty happy with the way I set up systems, and I still think they were reasonably secure. However, articles like this have convinced me the best way to have peace of mind is to set up OpenBSD firewalls.
Is Linux more secure than other operating systems? Yes. Is it easy to shoot yourself in the foot and make the system easy to exploit? Definitely. There's an excellent article over at Security Focus that every Linux sys admin must read.
Of course if there were no users, user accounts, or traffic on the wire I'd feel even better.
----- obSig
I find it amusing that I saw ">Download this document in MS Word format" on that page. I mean, there's a security risk right there!
More amusing is that I often see electronic resume requests for that "universal" document format, known as MS Word ".doc", rather than something not subjectable to macro virii, like PDF, Postscript, or good old PLainText.
Ok, so let's say (hypothetically, of course....) that you've been running a low-profile Linux system on the 'net for a while. At first, you just got IP Masqing up and turned off unused services. Later, you did some better firewalling. Then you started using SSH... added back in some services you needed...
But the thing is, it's been out there, in various states of lockdown, for at least the better part of a year.
How to know if you've already been compromised? Is there any way? Or is a fresh, secure install the only way to go?
I'm scared by the root kits that replace top, who, users, etc to make the intrusion undetectable. (Yeah, time to make that read-only floppy...)
---
"Secure by Default"
The default installation of OpenBSD is secure - it takes a careless sysadmin to mess it up. If anyone is truly concerned with security, this is the easiest and best choice.
Features:
And considering there is a reward to anyone who finds a exploit in Qmail, you can actually make money on it (if you can find any).
Now, does anyone feel secure enought to put up a reward for sendmail exploits?
Je ne parle pas francais.
The article is a bit self-agrandizing, but putting the most common holes out where everyone can see them is not a bad thing.
Now, Network Admins have no excuse but to fix things, rather than hoping no one 'figures out' where the holes are. The fixes for the 'ten most common' problems are not hard, and they're readily available.
Exposing security holes and avenues of attack to public review does make it a bit more possible that a cracker will learn something new, but the dangerous guys already know about all of this. Hiding this sort of information is like installing a car alarm - you'll keep the amateurs away, and you'll give the pros a chuckle while they make off with your goods.
If there is some unique set of conditions that make YOUR system vulnerable, and these conditions are very obscure and virtually impossible to 'guess', AND expensive to fix - by all means, keep them a secret as long as you can - but be ready when the hammer hits.
The problems outlined in the article are common-place, and in most cases common-sense. What 'advantage' does a cracker get from knowing that easily guessed passwords are a weakness? What does he gain from an Admin being educated to remove sample CGI scripts and default accounts off of commercial products??
-- What you do today will cost you a day of your life.
stunnel or using ssh as a tunnel is your better bet
---
-
ping -f 255.255.255.255 # if only
The plan is for this to be a living document - as responsible admins (and vendors) close these holes, new items will go into the Top Ten list. If you check out the Top Ten page, you'll see that there have been three revisions today.
Most of the vulnerabilities listed have beed known for years, and have easy fixes available, but admins haven't known what ones were most important. This is an attempt to help prioritize things.
This list completely ignores one of the most common security flaws in computer systems: Cleartext passwords sent over the wire.
It does and it doesn't. This list focuses on exploits, but there is an associated list, mentioned by the CNN article, of IT mistakes. Among the IT mistakes are using telnet and other unencrypted protocols.
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.
Several of the compromises are multi-platform, not specifically NT or *nix. Categories like the CGI/ColdFusion exploits make up a large percentage of the NT attacks. However, it is probably fair to say that most of us who were asked to participate probably have a *nix background, and are therefore more familiar with *nix exploits. Also, we were looking for remotely exploitable, directed attacks, and the background of *nix as a multi-user, network operating system gives more avenue of attack than an operating system with a single user, stand-alone heritage. Our list of end-user security mistakes (not yet released), on the other hand, is much more Microsoft-heavy.
Programs running as root are the problem.
//--thogard this will allow any user to open any port which cooresponds
// to a group they belong in. apaches user should be in group 80 and 443
// this should be linked moreinto capabile(CAP_NET_BIND_???)
Due to the stupid requirement that you have to root to bind to a port <1024 is a major problem. Its nailed bind, sendmail, ncsa httpd, poper, ftp....
Its time this stupid stuff stoped.
The fix is very simple. In 2.2.15 about line 543 of net/ipv4/af_inet.c put make the following change and it will allow group 53 to open port 53. So you can put bind in group 53, run it as a user with no other access and then the exploits won't have root.
if (snum && !in_group_p(snum) && snum < PROT_SOCK && !capable(CAP_NET_BIND_SERVICE))
return(-EACCES);
7. Design a computer case someone made out of something weird. Suitcase, plant pot, cow skin, matchbox, etc.
8. Claim to have instructions for playing DVD's on your linux box.
9. Port yet another windows game to Linux.
10. Claim BSD is better than Linux.
http://packetnexus.com
Generally are put out by some publication like Computer World or a web site like ZD. You know what drives me crazy? There is usually some 40-something, bearded yahoo in a suit whose weekly/monthly articles are all about how MegaCorp just decided to move from their IBM mainframes purchased in 1978 to NT servers running IIS.
And then they go on with and interview with some reject from a barnyard with bright red hair in a bowl haircut whose title is CIO/Chief Technologist who describes the methodology for choosing these systems based upon vendors taking them to lunch, boardroom pitches, white papers and indepth studies of competing megacorps' IT organizations.
And it always boils down to a two page ad for MS with a singular paragraph busting Unix as being unscalable and unsupportable and too hard for the desktop users to understand (like they do anything else besides making Excel spreadsheets and Project reports).
The next year, there is an article about how MegaCorp' IIS servers crapped out when a DOS took place or when more than 2 people decided to buy one of their widgets online and the whole system died.
They all learn in the end.
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?
Linux MAPI Server!
http://www.openone.com/software/MailOne/
(Exchange Migration HOWTO coming soon)
Important security features in its design:
- Client resolver is a separate process from the authoritative NS. Reduces damage potential should cache poisoning occur.
- 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.
- Client resolver sets TTL in responses to zero. Helps prevent client mischief. Does not return additionals or authorities to clients.
- All programs run chrooted as a non-priv uid.
- Discards all queries in classes other than IN. No CHAOS or HS classes. No "version.bind" stupidity.
- 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:- Authoritative server gives immediate feedback in the event of typos or syntax errors. No grepping log files looking for problems.
- Erroneous data is rejected. Previous data is used until the error is corrected.
- Reads zone info directly from a fast database, memory requirements are very small compared to BIND.
- 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.
- 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.Edith Keeler Must Die
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.
Politics, Culture, Food?
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...
-- Old Man Kensey
- 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:
- 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.#!/bin/sh
/root/suids
/root/suids` ; do
find / -type f -perm +6000 >
for a in `cat
done
- Sam
The secret to enjoying Slashdot is to realize that it should not be taken too seriously.
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.
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.
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?
---- I made the Kessel Run in under 11 parsecs.
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.
.bat files opened without examining content.
1. MCSE.
2. NT admins without MCSE.
3. NT admins without a driver's license.
4. NT users.
5. VBScript.
6.
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".