Slashdot Mirror

As a computer security consultant, this story seems silly to me.

see CERT advisories dating back to 1995... as well as bugraq discussions about it...

This is a very well known "vulnerability". The most famous use of this vulnerability was by Kevin Mitnick to attack Tsutomu Shimomura's computers.

Basically one of Shimomura's unix boxes had root level .rhost that trusted another one. Kevin spoofed packets from the trusted computer to execute a "echo '+ +' >> /.rhosts" then just rlogin. To help the attack Kevin also SYN flooded the the trusted computer so that it would not respond with RST packets. This type of attack is called blind spoofing and is usually difficult to do. There are programs out there that will do this. ie: ADM-rsh

Tools like nmap test for ISN randomness. Just about all unixen are atleast pseudo-random, which makes the attack almost impossible to do to two computers that you can't sniff traffic to or from.

If you can sniff traffic from either box then the problem of hijacking connections becomes much simpler. At this point it doesn't even matter what the ISNs are because you can just sniff them. Tools like: hunt are the preferred tools for session hijacking. hunt even has ARP spoofing so that you can sniff over switched enviornments.

Check out http://insecure.org/nmap/

... when nmap has been testing for it for years.

As a Register article puts it:

CPRM could yet be commonplace in hard disks in the future, implemented through the back door of "Vendor Unique" commands, Hedrick argues. And the task of finding out where CPRM is coming from would permanently impair the performance of non-CPRM operating systems. Like a Smash the Hippo Game, only with an infinite number of Hippos. And he adds, there's really nothing to stop vendors doing this. Much of what your hard drive can really do is not considered or ratified by T.13. This ain't the Supreme Court: it only sets down lowest common denominator interoperability standards. The rest is a free for all. Hedrick's "suggestion" to the T.13 mailing list, promising to give away a command parser that bounces unknown new commands, so obliging a CPRM-vigilant OS to track and reject all such command sets. His threat poses a dilemma for drive manufacturers which may be inclined to sneak CPRM in through the back door: they'll effectively lose the Linux market. Hedrick's parser will include trap-doors for vendors who try to circumvent known command sets, too.

Here is a list of good tools

Making matters worse, these email bugs have moved beyond the domain of "get-rich quick" and porn spam. Even companies you might consider legitimate have been doing this. One would think financial institutions would be particularly concerned about privacy, but I have found email bugs lurking in mail from both E*Trade and American Express.

While these bugs aren't very effective against those of us who use pine, mutt, etc., they set a dangerous precedent. If users tolerate applications retrieving untrusted data from the net without notification or permission, we could see even worse abuses like this in the future.

Unfortunately pressuring application vendors to respect our privacy is not always fruitful. And with closed-souce applications, you often have no idea what they are up to. I was glad to see that some of the Windows "personal firewall" programs such as ZoneAlarm offer features that alert users to unexpected outgoing connections made by applications. Users can define notification policies based on their own privacy concerns. I haven't run across similar software for Linux, although it wouldn't be hard to write. And it isn't quite as important on Linux since fewer users download/buy untrusted binary-only programs.

Cheers,
Fyodor

Concerned about your network security? Try the Free Nmap Security Scanner.

Given that you're posting around here, I'm guessing you have a Linux box handy. Here are some of my favorite sysadmin tools:

• dig - This is a more advanced tool for seeing what's going on with DNS.
• nmap - A great tool for probing your server to make sure you haven't left anything open.
• Apache Bench (ab) - This simple but effective benchmarking tool comes with the Apache server. It's great to see how your site will perform under load.
• wget - a tool for remotely getting web pages; it's very versatile -- you can even use to save a copy of your whole site, just in case.
• Ethereal - Having trouble figuring out what's going on between the browser and your server? This will capture all the packets and decode them into a nice conversation for you.
• vmstat - want to know why your server is slow? Get used to watching the vmstat numbers while it's fast, so you can see what's different when it's slow. It's raw numbers that are hard to interpret, but it's worth getting to know. Maybe this should be another Ask Slashdot question?
• Netsaint - this is my favorite automatic monitoring package. Once your site is in production, you can set this up to patrol things and make sure everything is working. That lets you get on with other stuff, knowing you'll hear about trouble pronto.
• MRTG - A tool that makes excellent long-term graphs of bandwidth use.
• IPtraf - Where MRTG gives you the broad overview, this gives you the second-by-second nitty gritty.
• perl - Last but most is Perl, a Swiss Army chainsaw of languages. If you'll be doing any web stuff, pick up a copy of Learning Perl and spend a little time with it. Once you learn the magic of regular expressions, you will never again say "that's impossible!" to a problem.

As far as non-sysadmin stuff goes, here are some of my other favorites:

• Bugzilla - this is a free and flexible bug tracking system. Highly recommended, especially for those people who don't think they need a bug tracking system. Our designers thought it was silly to start, but even they use it all the time now.
• CVS - Like bug tracking, most web sites don't think they need version control. Most web sites are wrong! CVSweb is also recommended.
• HTML Tidy - bad HTML in, good HTML out.
• WebTV Simulator - Sure, you and I don't use WebTVs, but a lot of people do. Browse your site with this to see how the other half surfs.
• VMWare - Along similar lines, VMWare is a Windows box emulator. I use it to keep a bunch of synthetic windows machines with a variety of OS versions and browser versions. It makes QA much easier.

And if there are particular tasks that have you stumped, come back and ask again. 'Round these parts, we have big toolboxes.

I use the RBL hooks in Postfix, and I find them very useful. This is a bit much, though. While I have enormous respect for Vix & co., I think this is way over the line.

How is software that is designed to send bulk email any "worse" than software that is designed explictly for the purpose of, say sniffing user passwords or performing denial-of-service attacks? Indeed, why aren't we, as the Internet community, tracking down those people arrogant enough to write these tools -- tools that are clearly used to commit all manner of subversion havoc -- and blackholing them?

It's because (most) technical people understand that tools are just tools. Somebody who writes a password grinder is "just" a programmer. The Unix admin who downloads it and runs it against her password file is just doing her job. The peeved help-desk guy who uses the password grinder to get the VP of Finance's Unix password and then uses it to access the nifty Oracle financial system is acting-- in the words of AUPs everywhere-- in excess of his authority, and if caught, will be squashed by the Law.

It's not valid to want it both ways, to want software that you think is "bad for the net" blackholed out of existence, yet allow other software -- arguably more damaging -- to exist unchallenged. If this was, say, WIPO vs. nmap, would those of you in favour of MAPS' stance take offense? Software is speech. Censor it and contribute to the decline of your freedom to write it. I'm sure the brains behind WIPO are very interested in seeing how this plays out; if an .org which essentially controls access to and from the large nationwide ISPs can succesfully censor software without question, then certainly WIPO can.

And finally: simply because MAPS says "These are our guidelines, and we are following them" doesn't mean the guidelines have merit.

• set realistic goals for a release
• defer any further feature creep until the next release
• concentrate on fixing bugs in the pre-release cycle
• aim for modularity, stable interfaces and good documentation to make upgrades and new feature addition easier and the learning curve less steep
• provide robust methods for troubleshooting the system to make development and debugging easier.

A black-hat being investigated by the FBI could possibly turn their tool against them, using *nivore for counter-intelligence. At least the FBI has to pretend to obey the law and respect some limits -- a black-had has no such restrictions.

I wonder if there is enough information in what has been released to be able to identify a carnivore box remotely. Does it use promiscuous mode packet sniffing? Could you detect one with a variant of l0pht's antisniff? Does it exhibit any tcp/ip eccentricities that could be detected with nmap or SATAN?

"It all kind of got out of proportion," Merkey said of the threats. He spoke about them only after some of his private e-mail was intercepted and posted on the Internet.

I don't think the linux-kernel mailing list is exactly "private e-mail". I wouldn't expect Pat to know what a mailing list is, but come on here. It seems as if Pat didn't even bother digging up the post that started it all. I wonder if Pat even asked Merkey about how the incident flared up.

sheesh, basic story research...
-------------

Linux Kernel mailing list archive, with 133 messages from Jeff V. Merkey in the last 26 days, including his posts about Microsoft.
--

-- That whole third paragraph about the linux community helping Microsoft is hogwash.

Though this reply isn't about the Linux Community, per se, the people as nmap believe that Windows 2000 is using NetBSD's IP stack ;)

TCP Initial Window -- This simply involves checking the window size on returned packets. Older scanners simply used a non-zero window on a RST packet to mean "BSD 4.4 derived". Newer scanners such as queso and nmap keep track of the exact window since it is actually pretty constant by OS type. This test actually gives us a lot of information, since some operating systems can be uniquely identified by the window alone (for example, AIX is the only OS I have seen which uses 0x3F25). In their "completely rewritten" TCP stack for NT5, Microsoft uses 0x402E. Interestingly, that is exactly the number used by OpenBSD and FreeBSD.

http://www.insecure.o rg/nmap/nmap-fingerprinting-article.html

Ron Gula already posted DefCon8 data along with DC7 and SANS ID-Net dumps several weeks ago. The page says Toorcon captures will be available shortly.

--
Frustrated by firewalls? Try the Nmap Security Scanner

Ron Gula already posted DefCon8 data along with DC7 and SANS ID-Net dumps several weeks ago. The page says Toorcon captures will be available shortly.

--
Frustrated by firewalls? Try the Nmap Security Scanner

anyone care to run one of those tcp signature OS-guessing programs on www.hotmail.com?

I've just tried that (using nmap). But we don't get much info:

TCP Sequence Prediction: Class=truly random
Difficulty=9999999 (Good luck!)
Remote operating system guess: Cisco Localdirector 430, running OS 2.1

This is the same sort of hole as, say, the old bsd mmap problem. Just as user/supervisor modes make it possible to write a system which puts processes in sandboxes, the JVM security system makes it possible to put applets into sandboxes. But in both cases, getting the security checks correct is a non-trivial exercise.

Well, this article from the author of nmap does note that Win2000 uses the same TCP Initial Window value as FreeBSD and OpenBSD (the NT4 value is different). Hardly conclusive, but an interesting coincidence.

Yeah, maybe if it were open source, they wouldn't be so tempted to put in blatant backdoors.
---

Hackers have been known to attempt to undermine your business interests with subversive activities like replacing IIS with Apache, and porting your product to Linux. Here's what we offer for protection:

• Instant Apache uninstall - we keep secured backup tapes that let you go back to your secure, responsive IIS environment instantly!
• Linux replacement - with proprietary tools we can search out Linux computers connected to your network and replace them with secured NT workstations!
• Source code security - we offer to help you write Windows-specific code so your developers can never switch to Linux if their hacker instincts flair up! As you can see, hacker insurance has many benifits. Protect your business investments today!

Fyodar's exploit world has a good collection of scanners, articles, and known exploits (if that's what you want).

Word of advice though, don't ask about the back doors in the various Quakes (here and here) during interviews on /. unless you've got Karma to spare . . . ouch.

It's mostly a conglomerate of different sources, but a number of the articles are kinda interesting. Keeping up with CERT advisories would probably be better for self defense though (always good to know what they do though). The scanners are pretty good, especially if your, um, on the "testing" end and the the detection end . . .

Fyodar's exploit world has a good collection of scanners, articles, and known exploits (if that's what you want).

Word of advice though, don't ask about the back doors in the various Quakes (here and here) during interviews on /. unless you've got Karma to spare . . . ouch.

It's mostly a conglomerate of different sources, but a number of the articles are kinda interesting. Keeping up with CERT advisories would probably be better for self defense though (always good to know what they do though). The scanners are pretty good, especially if your, um, on the "testing" end and the the detection end . . .

Fyodar's exploit world has a good collection of scanners, articles, and known exploits (if that's what you want).

Word of advice though, don't ask about the back doors in the various Quakes (here and here) during interviews on /. unless you've got Karma to spare . . . ouch.

It's mostly a conglomerate of different sources, but a number of the articles are kinda interesting. Keeping up with CERT advisories would probably be better for self defense though (always good to know what they do though). The scanners are pretty good, especially if your, um, on the "testing" end and the the detection end . . .

Hey, is NT still using the same TCP stack as Windows 95?
--

Try securing your systems BEFORE they get cracked. A good few places to start:

Insecure.org, especially this top 50 security tools page.
SecurityFocus the disseminators of the BUGTRAQ list among others.
Attrition.org, especially their security page.
And of course 2600, the l0pht, and Phrack for the latest tasty street info....

#include "disclaim.h"
"All the best people in life seem to like LINUX." - Steve Wozniak

Try securing your systems BEFORE they get cracked. A good few places to start:

Insecure.org, especially this top 50 security tools page.
SecurityFocus the disseminators of the BUGTRAQ list among others.
Attrition.org, especially their security page.
And of course 2600, the l0pht, and Phrack for the latest tasty street info....

#include "disclaim.h"
"All the best people in life seem to like LINUX." - Steve Wozniak

So if it's going to be cheap enough to spray on a car and possibly create an anti-collision system. How long will it take before the hackers will be able to hack into my car and make it burst into flames.

This is just another case of technology jut for the sake of technology

Also, since I can't even get DSL where I live, and this technology is supposed to be out by 2005, does this mean I will finally get DSL in 2005?

Will my new X-Box use this great technology, oh wait, I have to buy the proprietary MS-ETH/OPT-CHP conversion cable. Maybe I'll just hack my I-Opener and hook this thing on to the back as well.

Those who claim to be something often aren't:

• How many dishonest salesmen haven't told you how honest they were?
• "It is better to be described as a hacker by others than to describe oneself that way." (From the hacker Jargon File entry.)

And i'm beginning to think people who really are Christians don't say so.

But bashing everyone to whom that label could be attached is like bashing...

• all *BSD users because of the Linux haters among them.
• all Linux users because of the MS haters among them.
• all competent sys-admins who check their networks with nmap because of the script kiddies who use it.

cheers,
sklein

(For the record, the day my library installs filtering software is the day they loose my services as volunteer technical coordinator.

I argued that C, C++, or Perl might be more appropriate depending on the performance (and other) requirements of the application. I think the developer who dreamed up the application should decide what language is best suited for the given task. It should not be dictated in advance based on the founder's pet language.

Unfortunately it seems that Python promotion is the primary goal of the project, even though their $860,000 government grant is supposed to be used for creating new open source development tools.

Is it any surprise that Greg recently chose Guido van Rossum (Python author) as one of the judges? Speaking of which, I wish they would disclose whether (and how much) the judges are paid.

Don't get me wrong, I have nothing against Python. It is a wonderful language. And if the competition $$$ was raised from Python users' groups, I would be cheering them on. My problem is that they appear to be using $860K tax dollars to support Python even though the grant was for a completely different purpose.

Sure, some of you may be thinking that spending tax money to promote Python is not so bad. But imagine if they were spending your tax dollars to promote another language -- like Visual Basic!

I urge them to drop the biases and let the developers choose the most appropriate language. And may be best program win!

-Fyodor (fyodor@insecure.org)
Try the free Nmap Security Scanner: http://www.insecure.org/nmap/

See "ID games Backdoor in quake"

Do a search in page for quake at:

http://www.insecure.org/sploits_linux.ht ml

Don't get me wrong, I love id. I think Carmak is one of the greatest game developers out there, but I'm really curious about what appears to be very evil behavior on id's part.

Someone who has downloaded the code should grep it for "tms", or "192.246.40." and see what they find.

You make a very, very good point. Isn't there a way the Linux and *BSD kernel could be patched to disallow execution from a stack? I know there's plenty of memory protection and such in there, so can't we put in one more layer of protection?

So, let's just change chips. :-) Of course, that's hardly enough. Can't we clear up a lot of these exploits by fixing the stack? The answer is yes, we could clear up a lot of them. But that sadly, it's not going to cure the class of problem completely.

Why should stack and data pages be executable? Why are any pages that are executable also writable? Well, there are a couple reasons for that. Certainly it hasn't always been that way. But the signal trampoline code from gcc(1) makes this very attractive, and it's a bit annoying to change. You still have to deal with issues of mmap(2), which can ask for pages with any access bits it cares for.

And let's not pretend please that C is the issue here. It's not. You're diddling the instruction set. I don't care if you used a Pascal compiler. You could still diddle it. Then again, there's something to be said for having a cleaner library. See the end of this missive for a simple, elegant, and effective approach to one class of these problems in C by someone famously inclined toward the simple and elegant.

What I strongly suggest that anyone interested in this do is read existing literature on this. Yes, it's work, but it's really, really good for you. Start with the paper StackGuard: Automatic Adaptive Detection and Prevention of Buffer-Overflow Attacks. And yes, the buffer overrun in the version of Perl referenced by this paper has long since been fixed. But then read about how to defeat this. You can also check out disabling an executable stack on Solaris, and why this isn't a cure-all.

Even with a non-executable stack, you can still be bitten. Several such exploits have appeared on bugtrak. Here's one. The short explanation for why this isn't a panacea is that if I push a pointer to "/bin/sh" and a (char *)0 on the stack in a place right before an system(3) (well, or or execl(3) or execve(2) or whatever) then it'll still suck to be you. Notice I haven't executed any code that I put on the stack. I just managed to change some of the arguments to existing calls.

Let me put up a copy of some mail from Ted T'so, who said it well:

Well with a non-executable stack most security conscious system administrators will sleep better :) I can guarantee that. (Not too much better as holes always exist but quite a lot).

The advantage of the patch is that it will stop the current set of attacks that take the form of "find buffer overrun in a program", followed by "apply standard toolkit to exploit buffer overrun by putting executable code on the stack".

The disadvantage of the patch is that after we apply, within a few months we will see a new toolkit of the form "corrupt the stack to point the return address into someplace entertaining in libc --- like right before an an execl call in the implementation of popen()."

The danger is people thinking that with this patch, they don't need to worry about finding and fixing buffer overrun bugs in their code....

Here's the promised gem of insight from Dennis:

> ..... If most implementers will ship gets() anyway,
> there's little practical effect to eliminating it from the Standard.

On the other hand, we removed it from our library about a week after the Internet worm. Of course, some couldn't afford to do that.

Dennis

A line by line code review is great, and I would agree that OpenBSD is the most secure OS you can get your hands on, but it cannot prevent all possible exploits

If you think you can just install OpenBSD and not have to know a thing about security, you need to get you head checked.

Be your own judge, and while this was very serious, I don't believe that this latest foul-up is very bad.
...

While I'm encouraged that they are fixing the problems with the package, I wish there were an easy way to deal with the inherent problems with the protocol itself. It's still fairly trivial to poison DNS caches, and lookups are still not encrypted, which although not much of a security issue by itself, it's a bit of a privacy issue. We've come to a point where if a program relies on reverse DNS lookups, any DNS expoit used against it is considered a security problem with the program, not DNS. The truth is, however, that the DNS system should be reliable enough that these types of attacks wouldn't even exist. Don't get me wrong, I applaud their work for fixing the bugs that they have, but there is some basic protocol work that needs to be done before I'm happy with it. Here is a interesting example of DNS quirks.

If you need to point-and-click to administer a machine,

I was wondering if it would have the same features as Q1 and Q2.

In otherwords, is it finally safe to run on a server open to the world?

According to this article, quake is "a bad thing" (TM)

>example: how do you prove that Win2K doesn't use some modified Linux IP stack? Nobody's allowed to
>see the source so nobody will ever find out right?

Someone's already thought of that.

An excerpt from http://www.phrack.com/search. phtml?view&article=p54-9 which describes nmap, an OS fingerprinting-by-TCP/IP-stack-details tool:

TCP Initial Window -- This simply involves checking the window size on
returned packets. Older scanners simply used a non-zero window on
a RST packet to mean "BSD 4.4 derived". Newer scanners such as
queso and nmap keep track of the exact window since it is actually
pretty constant by OS type. This test actually gives us a lot of
information, since some operating systems can be uniquely
identified by the window alone (for example, AIX is the only OS I
have seen which uses 0x3F25). In their "completely rewritten"
TCP stack for NT5, Microsoft uses 0x402E. Interestingly, that is
exactly the number used by OpenBSD and FreeBSD.

-----------------

Interesting indeed! Hmmm, looks like MS has been caught with their pants down and their finger in the pie and their hand in the till. :)

mentaldent

There's such thing as IP stack fingerprinting. It's what programs like nmap do to figure out what the target system is running.

If Microsoft were to copy Linux's TCP/IP stack, their fingerprint would match as well. It's not easy to change your fingerprint without changing the code to generate what it is you're fingerprinting.

Well, you could use nmap to figure out which OS the computer in question is running, but as to which Windows version and patch level, I haven't a clue. nmap doesn't support that, yet. There are programs out there that do, but I can't remember any right now.

'Q2 had several releases forced out because of malicious attacks on all the public servers'.

Uh, maybe this was because 'ID software blatantly put a backdoor in Quake 1/2 and QuakeWorld including both the Linux/Solaris Quake2. RCON commands sent from the subnet 192.246.40.0/24 and containing the password "tms" are automaticly executed on the server without being logged.'

'Vulnerable Systems: Those running Quake 1, QuakeWorld, Quake 2, Quake 2 Linux and Quake 2 Solaris, all versions. Thus many Windows and UNIX boxes are affected.'

'Compromise: root (remote).'

'Notes: Quake was always a horrible security hole, but I never thought Id would stoop to introducing an intentional backdoor to allow them access to systems running Quake. I am surprised this didn't get more publicity.'

The exploit was discovered by Mark Zielinski and is documented at www.insecure.org. You can find the fix here, but if you're looking for a patch, dream on...

'Q2 had several releases forced out because of malicious attacks on all the public servers'.

Uh, maybe this was because 'ID software blatantly put a backdoor in Quake 1/2 and QuakeWorld including both the Linux/Solaris Quake2. RCON commands sent from the subnet 192.246.40.0/24 and containing the password "tms" are automaticly executed on the server without being logged.'

'Vulnerable Systems: Those running Quake 1, QuakeWorld, Quake 2, Quake 2 Linux and Quake 2 Solaris, all versions. Thus many Windows and UNIX boxes are affected.'

'Compromise: root (remote).'

'Notes: Quake was always a horrible security hole, but I never thought Id would stoop to introducing an intentional backdoor to allow them access to systems running Quake. I am surprised this didn't get more publicity.'

The exploit was discovered by Mark Zielinski and is documented at www.insecure.org. You can find the fix here, but if you're looking for a patch, dream on...

you should try fyodor's
Nmap

# nmap -sT -p80 -O -vv 194.112.94.251

Starting nmap V. 2.08 by Fyodor (fyodor@dhp.com, www.insecure.org/nmap/)
Host (194.112.94.251) appears to be up ... good.
Initiating TCP connect() scan against (194.112.94.251)
Adding TCP port 80 (state Open).
The TCP connect scan took 1 seconds to scan 1 ports.
For OSScan assuming that port 80 is open and port 42349 is closed and neither ar
e firewalled
Interesting ports on (194.112.94.251):
Port State Protocol Service
80 open tcp http

TCP Sequence Prediction: Class=truly random
Difficulty=9999999 (Good luck!)

Sequence numbers: 85F8984B 390BA429 F5B7DF23 FDC0076C 3DB9689F 1D11DFE1
Remote operating system guess: Linux 2.0.35-36
OS Fingerprint:
TSeq(Class=TR)
T1(Resp=Y%DF=N%W=7FE0%ACK=S++%Flags=AS%Ops=ME)
T2(Resp=N)
T3(Resp=Y%DF=N%W=7FE0%ACK=S++%Flags=ASF%Ops=ME)
T4(Resp=Y%DF=N%W=0%ACK=O%Flags=R%Ops=)
T5(Resp=Y%DF=N%W=0%ACK=S++%Flags=AR%Ops=)
T6(Resp=Y%DF=N%W=0%ACK=O%Flags=R%Ops=)
T7(Resp=Y%DF=N%W=0%ACK=S%Flags=AR%Ops=)
PU(Resp=Y%DF=N%TOS=C0%IPLEN=164%RIPTL=148%RID=E% RIPCK=E%UCK=E%ULEN=134%DAT=E)


Nmap run completed -- 1 IP address (1 host up) scanned in 1 second