[SLUG] Re: Re: Preventing attacks
On Tue, Nov 09, 2004 at 06:14:23PM +1100, [EMAIL PROTECTED] wrote: On Tue, Nov 09, 2004 at 02:25:22PM +1100, James Gregory wrote: On Tue, Nov 09, 2004 at 03:31:50PM +1100, Toliman wrote: and it is 'relatively' secure, in that it would hopefully take a p4 a few hours to brute force... more likely in minutes. How long is 'a few hours'? I didn't think things were that dire. Are you talking about a straight brute force or some kind of known-plaintext attack or what? Isn't the kerberos ticket only valid for a few minutes anyway? Only if you want to be re-typing your password every few minutes. One of the features of Kerberos was supposed to be a single sign-on -- obtain a TGT (Ticket-Granting Ticket) and then use that as a password-equivalent until it times out, after which time you need to get another TGT by resupplying your credential (password). Think of it as longer-lived one-time passwords -- you don't have to keep typing your password all the time, but the password you do pass around has a limited life and gets recreated every few hours. - Matt signature.asc Description: Digital signature -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
[SLUG] Re: Re: Preventing attacks
[Don't Cc me, I'm the list FFS] On Mon, Nov 08, 2004 at 09:08:23PM +1100, O Plameras wrote: Matthew Palmer wrote: On Mon, Nov 08, 2004 at 01:31:51PM +1100, O Plameras wrote: Ken Foskey wrote: I am unsure how this would have prevented the attack on the kernel that was applied? Please explain. With the intruder having acquired unprivileged access to system, he/she could have been confined to limited sets of functions because that is one of the things that SELinux does. Because he/she is restricted in what can be done it will take a bit longer to figure out ( I assume ) how to escalate privileges to root. In Only if the set of privileges granted to the program didn't include access to the flawed function. It was ptrace(), so an allow only that which is really required policy would have probably blocked the access, there's no guarantee. I cannot comment on this because I do not know what you are talking about. If you can be clearer. SELinux works by by restricting access to what can be done by a program. If the exploit program couldn't run the flawed code, then no exploit would be possible. If SELinux allows access to the flawed code, then the flaw can still be exploited to obtain elevated privileges. 2. Would 'kerberos' have prevented this sort of break-in ? The initial attack was by social engineering. One developers key was compromised due to their lack of security thought. With one weak link in the chain then it all comes down. Now, I posed the problem without really knowing the complete details of the circumstances because 'kerberos' is meant to be the strongest security protection against this sort of attacks. Where the hell did you pick that up from? This sort of attacks could be one of: I got it from people who should know. Care to name names? Voices in Oscar's Head don't count, by the way. 1) Sniff the entry of a password on a previously compromised host: hmm, no, Kerberos doesn't protect against r00ted boxen. Can you elaborate how kerberos and r00ted boxen works and where the latter will be able to trick kerberos ? Does that sound like something from Eliza to anyone else? tricking Kerberos has nothing to do with it. If I've got a keylogger on your computer, logging every keystroke you type, whether you type the password into a Kerberised application or not, you're toast. Kerberos is nothing, and I do mean *nothing*, more than a heavily overengineered (though still probably the best-of-breed) untrusted-network authentication system. 2) Exploitation of a kernel vulnerability to obtain escalated privileges: riiight. I do not quite follow this. You probably did not read the circumstance surrounding the Debian Break-In. (http://www.wiggy.net/debian/explanation/) ptrace vulnerability -- ring any bells? And yes, I read the circumstances surrounding the Debian Break-in. Quite closely. 3) Use of a stored authentication credential to gain access to a system account on another system: probably not, and Kerberos is a real pest in this situation. You are saying things about kerberos without knowing what kerberos is, what it is not, and what it can do. I did the initial setup and 3 years of ongoing maintenance of a 400 user Kerberos realm. Whilst I will profess to not be an almighty god on the issue, I think it's fair to say I've got some degree of experience with it. I note here some differences between ssh and kerberos: 1. SSH needs local identity files whilst kerberos does not You mean known_hosts? No, kerberos just restricts you to a small set of hosts which you can access (without setting up cross-domain trust relationships). And after all, if an attacker has just sniffed your password, he'd be very, very unlucky not to get the hast you connected as well. Everything in ~/.ssh directory. Which is, in the basic case, just known_hosts. That keystroke logger got the login command as well as the password, you know. 2. SSH does not impose time restrictions on a session whilst kerberos does (Prevents replay attacks) From memory, SSH uses some form of challenge/response to set things up, so a replay attack wouldn't be feasible. From this response, it appears you do not understand what is a 'replay attack'. If you can explain perhaps. Your not as clear as can be. Replay attack: a means of doing unpleasant things by resending previously captured information in the hope it will continue to elicit the same response as the initial transmission of the captured information. 3. In SSH the client decides what tools and application to run on the server I call 'horseshit'. Should have done it two days ago, but there you are. What you have above is the real 'horseshit' because in SSH once a client connects there is no mechanism to restrict the user to a subset of commands or functions. Whereas with Kerberos, there is a
[SLUG] Re: Re: Preventing attacks
On Mon, Nov 08, 2004 at 09:19:32PM +1100, O Plameras wrote: Matthew Palmer wrote: But that's not Kerberos doing that, it's whatever application has been taken to with a bandsaw to make it do the Kerberos Dance. The point here is having a connection ( established through kerberised telnet), and once that connection is established, the messages exchanged between the two computers are encrypted. Not necessarily. Only if both ends of the connection negotiated some sort of stream encryption after the authentication has taken place. Please feel free to use your sexy Kerberized telnet service to connect to your server next time I'm nearby with dsniff. I do now believe you do not know what Kerberos is, what it does, what it can do, and why people love it. I do know what Kerberos is, I know what it does, I certainly know what it can do. However, I have a bit of a hard time working out why people love it. - Matt signature.asc Description: Digital signature -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] Re: Re: Preventing attacks
On Mon, 2004-11-08 at 21:39 +1100, Matthew Palmer wrote: Care to name names? Voices in Oscar's Head don't count, by the way. Matt, I think this is a little over the top. Rob -- GPG key available at: http://www.robertcollins.net/keys.txt. signature.asc Description: This is a digitally signed message part -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] Re: Re: Preventing attacks
Matthew Palmer wrote: The point here is having a connection ( established through kerberised telnet), and once that connection is established, the messages exchanged between the two computers are encrypted. Not necessarily. Only if both ends of the connection negotiated some sort of stream encryption after the authentication has taken place. This is certainly wrong. Once connection is established in the Kerberos Realm all communications and messages exchanges are encrypted in accordance with the rules as specified in Kerberos. I do know what Kerberos is, I know what it does, I certainly know what it can do. However, I have a bit of a hard time working out why people love it. You are just saying without elaborating. It is one thing to say for you someone is wrong but you have not been forthcoming why you are right; no logical explanation. -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] Re: Re: Preventing attacks
On Mon, 2004-11-08 at 21:55 +1100, O Plameras wrote: Matthew Palmer wrote: The point here is having a connection ( established through kerberised telnet), and once that connection is established, the messages exchanged between the two computers are encrypted. Not necessarily. Only if both ends of the connection negotiated some sort of stream encryption after the authentication has taken place. This is certainly wrong. Once connection is established in the Kerberos Realm all communications and messages exchanges are encrypted in accordance with the rules as specified in Kerberos. Actually, you are wrong, according to my Kerberos the definitive guide book here. The exact things that are encrypted, and how, depend on which kerberos implementation and version you are using, but regardless of that, kerberos itself only specifies the encryption for the AS handshake to get a TGT, and the TGS handshake for getting a ticket for a specific service. Rob -- GPG key available at: http://www.robertcollins.net/keys.txt. signature.asc Description: This is a digitally signed message part -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
