Slashdot Mirror

Anyhow, if you could spoof BGP traffic from a trusted IP address to a backbone router, you could probably do a lot of harm. I'm not sure that it's possible, but if it is, perhaps that's what the Guardent advisory is about. Phil

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.

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.

About 80% of the people in this field seem utterly clueless about security. And this is being charitable. Most developers I have talked to these days are astounding in their lack of knowledge about real security attacks. Some even whine about why things don't work when they try to loosen security. This is utterly mind-boggling!

Java doesn't cut it here. The simple reason why is due to the overhead in loading in all the security classes. There was an excellent and simple example of some JSSE code in Dr. Dobbs recently; try downloading and running the code with TSL turned on - you'll see what I mean.

Another sad reason is the lack of algorithm support in Java. Yes, it's a start; and yes, it has a LONG way to go to get up to speed with OpenSSL. I daresay it will take years to develop the same breadth and confidence as OpenSSL.

OpenSSL is the best thing out there, and it needs a serious rewrite. I don't wish to belittle the excellent work done by Eric, Ben, Ralph and many others. But let's be honest here. OpenSSL has evolved into a mishmash, and it's time to rewrite it. Of course, by the time that's done, then Java will probably have come up to speed. I doubt it will be as fast, but I'd like to be optimistic here.

The biggest security flaw in ebiz is conveniently overlooked. People seem to be litterly sticking their heads in the sand on this one. It was reported last summer on bugtraq , and yet, almost no one seems to be paying attention to it.

Many people are trying to implement security models using Java applets. This is a fatal mistake, and will leave you or your clients rather vulnerable.

The simple reason why is because if your browser gets hit with a rogue applet, you are screwed. Not only can a reverse-tunnel to a hostile site be set up, but under some circumstances, the applet can initiate a secure connection to (say) your bank, using your password from the cache!!!

You get NO warning that this has happened; and the bank thinks that it really was from you. Good luck disproving this one in court. And most firewalls won't protect you.

The potential for serious damage here has not been fully exploited, thank God. But it's only a matter of time. Especially when people highjack a sites' DNS server, and point it to a hostile look-alike. Ugh.

What's also scary is the number of sites using pure Java or Javascript. Javascript is even worse, and IMHO can't be fixed security-wise without a complete rewrite.

But the bottom-line is that Java and Javascript leave you vulnerable; and it's only a matter of time before this hits the fan. Sun has as big an exposure as MS (with IE and Outlook virii) - it's only a matter of time before this is exposed.

Just turn off Java. This might protect you (though I suspect that actually even this may not help).

But the products which are coming out using applets for security is of real concern. In fact, it might well seriously hinder the new move to application servers, depending on how things are done.

This is frighteningly fertile ground for exploits.

So, yes, the bottom line is that PKI has a VERY long way to go. This is surprising given that people have been working on it for eons. IMHO, the lack of progress here is the best example of how the U.S. export restrictions have hurt business.

And, if you really want to put this in perspective, take a look at InfoSec's recent study, they noted that only 2/3 of all ebiz transactions are done with encryption (and this is an *improvement*!?!).

I'm guessing that rfp said it best...
Yes, it's likely entrapment. No, no one's really sure whether it'll hold up in court. No, you don't know what you're hoping to accomplish. Yes, it's a really bad idea. Worry about getting your IDS and firewall rules up to date and your security policies and tripwires strictly monitored before you bother with nonsense like a honeypot.

Well damn Netscape for taking an "Enter" as "Submit." :)

Anyways, maybe not Linux but ftp.exe is definately stolen from BSD. Run strings on it or look at this (Googled since I don't have ftp.exe handy for a proof-of-concept) if you don't believe me:

http://archives .ne ohapsis.com/archives/bugtraq/1999-q3/0523.html

Cheers,
*bewm*

Let's see what WebFerret (The only way to search the Web!) makes of "nohican"..

[time passes..]

Ha!

1. http://www.hideaway.net/vuln-dev/j uly /66.html

nohican@MARCELLA.NIETS.ORG

Kind Regards,
Joost Pol aka Nohican
Root66

2. http://www.voy.com/5188/1/52.html

mailto:nohican@niets.org

Joost Pol
IRIS International

3. http://archive s.n eohapsis.com/archives/vuln-dev/2000-q2/0453.html

Subject: Re: The Million Dollar Solution (NOT?)
From: Nohican (nohican@NIETS.ORG)
Date: Sat May 06 2000 - 20:20:55 CDT

ps: read his posts; I think from the context, and from the fact that this is the only "nohican" that came back, that...

...oh, let's not jump to any conclusions!

t_t_b
--
I think not; therefore I ain't®

There was this little item in Bugtraq that I stumbled across while trying to hit thier site (doing a Google search for "DNS tunnel")- seems someone previously did a demo of this exploit with the intents of putting in Phrack, deciding to put it up in Bugtraq instead.

Look here for the info in question.

Letsee now...

HTTP Tunnel.
Mail Tunnel.
Now, DNS Tunnel.

Wonder what wonders they'll come up with next.

You're not following Bugtraq closely enough then.

http://archives.ne ohapsis.com/archives/bugtraq/2000-08/0457.html describes a format string vulnerability (and sample exploit code) in the locale system of most Unixes; OpenBSD appears not to be vulnerable, and FreeBSD is not remotely exploitable, but all other major Unixes appear to be vulnerable.

This isn't FUD; the article is pretty dead-on.


--

If you read the Microsoft NT C2 Configuration article closely, with comprehension, you'll find that it speaks of NT 4.0 being evaluated, but never certified, as being C2 compliant. This was addressed in this BugTraq post. Believe you me, if NT 4.0 had been certified, Microsoft would be singing it to the heavens. But they don't want you to know that. You'll also note that "The C2 Administrator's and User's Security Guide" is itself a MS Windows executable (http://www.microsoft.c om/technet/security/exe/C2SecGuide.exe), hardly the most secure and safe way to transmit data around the Internet. Anyone got an open-standards version of this document?

They also don't want you to know about the man they killed after he first got WinNT 3.51 C2 certified, then told Microsoft that it would not be possible to get C2 certification for WinNT 4.0. Ed Curry, military man, NSA-certified technician, and a former independent contractor for Microsoft first had his business, health, and ultimately life destroyed. I knew Ed only from online encounters in Nick Petreley's InfoWorld forums, but the man was a friend, willing and capable of sharing fascinating information. Ed Curry died in December of 1999 of a stress-induced stroke. He is survived by a wife and young daughter.

What part of "Gestalt" don't you understand?