Overconfidence in SSH Protection 194
nitsudima writes to mention a post on the Informit site about the common misunderstandings surrounding SSH, and how well-intentioned admins may be creating holes in their own security by using it. From the article: "In UNIX, all things are files. To send network traffic, UNIX writes the traffic to the network device file. In this case, the connection to Box A (and that private key used for authentication) is a socket file. This file will shuttle the authentication traffic between Box A and Box P. So what's the risk? Maybe the hacker can't get a copy of the private key through the socket file, but something better (from his/her view) can be done. If the hacker has root on Box D, he or she can point a private copy of the agent forwarding software to that socket file and thereby point the authentication process to the administrator's credentials--the ones kept on the 'safe' intranet. What are the chances that the administrator has configured access to all the DMZ servers he controls?"
Huh? What? (Score:5, Insightful)
Re:Huh? What? (Score:4, Interesting)
Re:Huh? What? (Score:4, Insightful)
Re:Huh? What? (Score:2)
Re:Huh? What? (Score:2)
Re:Huh? What? (Score:2)
As for the article, as long as you allow arbitrary connections through the firewall, there simply is no way you can technically prevent tunneling over those connections. You can create an ip tunnel over an
Re:Huh? What? (Score:2)
Laptops would be one of those problems with vastly higher ROI. And I'd consider them a far more common and practical danger than excessive tunneling.
"VPN changes the network topology and can cause havoc and confusion."
I suspect the comparison is usually not with permanent VPN's, but with temporary VPN tunnels that cut off outside access to the host in question.
Re:Huh? What? (Score:2, Insightful)
Re:Huh? What? (Score:2, Interesting)
Re:Huh? What? (Score:5, Informative)
User A on box foo:
foo> ssh-agent xterm
foo> ssh-add
* enters their pass key *
User A can now ssh to any box that has their public key in box:$HOME/.ssh/authorized_keys
User B (evul hacker with root on box foo):
foo# SSH_AGENT_PID=XXXX; export SSH_AGENT_PID
foo# SSH_AUTH_SOCK=/tmp/ssh-YYYY/ZZZZ; export SSH_AUTH_SOCK
User B now can ssh to any box that User A can, as above.
(where XXXX, YYYY, and ZZZZ are determined by evul hacker)
Re:Huh? What? (Score:4, Insightful)
So... how does this even remotely approach being news? Yes, if you type your passwords into a machine on which someone else has root, you have given those passwords to them! The horror! I had no idea!
The best thing I can say about this article summary is that it did not misrepresent the actual piece. The article itself was also muddled tripe, filled with semi-true and completely-irrelevant noise like "in unix, everything is a file..."
It appears that the author is just a firewall admin who's offended that ssh can be used to thwart his precious acls, and invested in giving the tool a bad name.
Re:Huh? What? (Score:5, Informative)
Re:Huh? What? (Score:2)
Only if he specifies -A on the command line -- authentication agent forwarding is disabled by default; any documentation referencing -A and agent forwarding also eplains, in the next paragraph, the peril in using -A with an untrusted host. (Duh)
Re:Huh? What? (Score:3, Insightful)
Sorry, doesn't work.
I'm an 3v1l h4x0r in complete control of untrusted host X. Some poor fool uses SSH to connect to the trusted, firewalled host Haven. At this point, since I'm in complete control of X, I can simply send commands from X to Haven, doing anything the user could - including launching a
Re:Huh? What? (Score:2, Informative)
Re:Huh? What? (Score:2)
What country are you from and what pronoun do you use?
Re:Huh? What? (Score:2)
Which is also why it's generally a lousy idea to allow DMZ hosts to initiate general connections into the intranet in the first place. Defense in depth -- even if the admin screws up and allows agent forwarding to DMZ hosts, an attacker won't immediately be able to use those credentials to ssh from the DMZ into intranet hosts.
Re:Huh? What? (Score:3, Insightful)
Remember the
Re:Huh? What? (Score:2, Insightful)
Re:Huh? What? (Score:2, Interesting)
Wash, rinse, repeat.
Before you know it your whole DMZ is rooted (in more than one sense).
In short:
- If you find a compromised box on your network, assume there's more than one and order pizza... you're in for a long night.
- Segregate your network
Re:Huh? What? (Score:2, Informative)
I think the main point (the one the article submitter picked up on) was that if an attacker can compromise your DMZ box (the most vulnerable box your company owns and hence the least trusted box your company owns) that has no private ssh keys stored on it and can't connect to any other trusted box but does have trusted boxes connecting to it, then he can use that to compromise further trusted boxes inside the organisation.
To put it another way, if you ss
Re:Huh? What? (Score:3, Insightful)
Don't use agent forwarding when connecting to an untrusted box?
Can you just mandate that as a policy or are there times when you absolutely have to use agent forwarding via an untrusted/DMZed machine? I don't think I've ever used a DMZ machine for agent forwarding, but then again it's not really a feature I've used very heavily.
MitM (Score:2)
This is not a vulnerability if you know the other key's hash/residue and compare it each session, as ssh can be configured to do.
Nothing to see here, move along.
Re:Huh? What? (Score:2)
Re:Huh? What? (Score:1)
All I need is root? (Score:5, Insightful)
Re:All I need is root? (Score:3, Funny)
So, the real trick is just to live a life so borring none of these people will care to spy on you. Not all that hard, really. Considering you're on
Re:All I need is root? (Score:2)
Root (Score:3, Insightful)
dont really understand the problem. (Score:5, Insightful)
Any sysadmin who configures sshd to allow direct access to a root account is incompetent and deserves to clean up the resulting mess when they are cracked.
So what should we worry about again?
OpenBSD? (Score:2, Insightful)
So you are calling the OpenBSD guys incompetent? After all, if you enable SSH in the default installation, you can SSH into that machine including as root.
Re:OpenBSD? (Score:1)
I think it was ssh, but frankly... One remote hole in 8 years... I would be confident in that software too!
Re:OpenBSD? (Score:1, Interesting)
Re:OpenBSD? (Score:1)
That's odd, because I installed 3.9 last wednesday and ssh was definately enabled on default install. You don't have to take my word for it, just head over to the Installation FAQ [openbsd.org] and see for yourself:
Start sshd(8) by default? [yes] y
If asking a question that defaults to "yes" isn't "default install", I don't know what it is.
Re:OpenBSD? (Score:2)
Re:dont really understand the problem. (Score:1)
Re:dont really understand the problem. (Score:4, Interesting)
Duh.
Re:dont really understand the problem. (Score:2)
but I suppose you meant "seamlessly" and not a form of "un-seemingly"... it's not entirely unpossible, u kown... no?
Re:dont really understand the problem. (Score:2)
Try adding NOPASSWD to your sudoers file, like this:
admin ALL=NOPASSWD:/usb/local/sbin/foo
Re:dont really understand the problem. (Score:2)
It's interesting that this site is sponsored by Microsoft:
http://www.informit.com/ [informit.com]
Re:dont really understand the problem. (Score:5, Insightful)
The exploit mentioned in the article doesn't rely on ssh being configured to connect directly to root. It relies on the attacker having gained root access on the box being ssh'd to by the sysadmin. Once the sysadmin has ssh'd to the comnpromised box (as any user) the attacker can then ssh to any other box the sysadmin has configured to use agent forwarding.
Two solutions to prevent this compromise of the rest of the network:
1) Don't allow the DMZ box to ssh anywhere; firewall it off. There should be no need to ssh FROM the DMZ box, only TO it.
2) Use a different public/private key pair for each box. That way, if you didn't firewall the DMZ off it would still fail on the key authentication. The drawback of this is a) the attacker can still ssh to your admin box which contains all of the private keys and b) you lose most of the advantage of agent forwarding; the ability to ssh through a chain of boxes without any but the first needing to store the private key.
I suppose the underlying message in the article is "You REALLY can't trust anything in a DMZ that may have been compromised. ssh is a tool that can be turned against you if one of your machines is compromised."
Re:dont really understand the problem. (Score:2, Informative)
Or better yet, don't allow the DMZ host to initiate *any* connection outbound from itself, if the services present on it don't need to do such, or failing that, disallow it initiating any connection that isn't out the internet-only-facing interface(s).
However, that's still not what the attack is exploiting, and wouldn't prevent the attack.
The 'attack' is taking an (I)Internal (S)erver, an
Re:dont really understand the problem. (Score:2)
Re:dont really understand the problem. (Score:2, Insightful)
From the article: (emphasis mine)
Re:dont really understand the problem. (Score:3, Informative)
So... (Score:1, Interesting)
Isn't that why SSH displays that "Private key SO:ME:WE:IR:DL:ET:TE:RS belongs to IP 127.0.0.1" or whatever?
Re:So... (Score:5, Informative)
It's more of a credential hijacking scenario where
the attacker waits for you to authenticate with
the compromised machine, forward your credentials
to that machine, and then the attacker uses those
credentials to reach other machines that honor those
credentials.
This would be more like you signing in, walking
away from your computer, and someone else walkup up
to the computer and doing stuff as you except that
they get to act as you while you're still acting
as you.
Did that help?
Re:So... (Score:2)
Re:So... (Score:2)
In a man in the middle attack, the attacker intercepts the authentication,
and then uses that authentication information to authenticate with the
system that the user thought he was authenticating with in the first place.
In this attack, the attacker waits for the user to authenticate and
receive his authentication credentials, and then the attacker uses those credentials
to connect to other machines as that user. The attacker never intercepts
anything, so this isn't a true man in t
Maybe I'm over-simplifying things (Score:2)
but honestly, is there anything a bit of courteous knocking on the right door [zeroflux.org] can't fix?
Re:Maybe I'm over-simplifying things (Score:1)
The Key is Not Transmitted (Score:5, Insightful)
Re:The Key is Not Transmitted (Score:2)
No, but it would be possible to get the person's key agent to authenticate you on one of their boxes. Of course, this shouldn't be news to anyone. From man ssh(1):
Re:The Key is Not Transmitted (Score:4, Informative)
Perhaps the author of the article should have read the source of the text you quoted [openbsd.org]. The preceding paragraph:
So the only people who will be caught out by this are those who:
Configuring the agent to prompt the user to confirm any signing request can be as complicated as putting the private key on a smart card (which will make the reader prompt for a PIN whenever the card recieves a signing request) or it can be as simple as using the -c option when calling ssh-add; therefore this does not seem like a big deal to me.
Re:The Key is Not Transmitted (Score:2)
Re:The Key is Not Transmitted (Score:2)
He's saying you can use the authentication agent socket dup to forward your own login attempts to the admin's authentication agent. No keys are sent, but the admin's agent will use the admin's key to allow your own surreptious logins.
Not a SSH problem? (Score:3, Interesting)
Re:Not a SSH problem? (Score:2)
Hopefully, a better summary... (Score:3, Informative)
The submitter didn't summarise anything, he cut out a chunk which didn't make much sense on its own. It didn't help that the article was fairly long-winded. This is what I understand the author is trying to say:
As others have commented, this is kind of a "duh" moment. What's the next article?Re:Hopefully, a better summary... (Score:1, Troll)
If you install and enable Apache, people can download arbitrary files from your web root directory! Also, driving cars requires gas, and plastic surgery made Paris Hilton uglier.
Shocking stuff.
Re:Hopefully, a better summary... (Score:2)
Of course, this only adds a layer of obfuscation and effort into an attacker's attack plan, but it's a fairly simple trick to vastly reduce the issues here.
ash
Re:Hopefully, a better summary... (Score:5, Interesting)
It's not quite as straightforward of a duh moment (after all, server A on its own can't log into server B), it's basically just saying "when you log into a server and have agent forwarding turned on, you allow anyone with root access on that server to log into anywhere your agent can log into".
Re:Hopefully, a better summary... (Score:2)
Right, which is why agent forwarding is disabled by default. The only point to this article may be to remind the few users who use an agent and turn forwarding on in their config files that they should use the '-A' flag, instead.
And this sort of thing doesn't matter (Score:1)
Just kinda how it goes if you want to have easy management. The only real prevention for this k
Re:And this sort of thing doesn't matter (Score:2)
The admin-types I know all have their regular user accounts on the LDAP system, so they can do single-sign-on like the rest of us (to t
Re:And this sort of thing doesn't matter (Score:2)
"If only we could make stupidity more painful..."
to my sig file:
"If only we could make poopidity more stainful..."
Re:And this sort of thing doesn't matter (Score:2)
Also, in most cases, you need only find out the root password once. As nice as it is to think amdin can remember 500 different root passwords, they can't. Most of the systems will have o
Re:Hopefully, a better summary... DARPA (Score:2)
You will be recruited shortly. Your fate, should you chose not to accept recruitment, is to see your surfing logs forwarded to your employer...
Basic Stuff (Score:5, Informative)
Anyone who tunnels from the DMZ to a trusted host which can execute commands on a sensitive server can't see the forest for the trees. You've learned how to use SSH and tunnel, but you're lacking some basic common sense.
Also, I don't see what good a socket catching the authentication will do
That whole article seemed a bit of voodoo itself. Many incongruous statements, like "If the hacker has root on Box D, he or she can point a private copy of the agent forwarding software to that socket file and thereby point the authentication process to the administrator's credentials--the ones kept on the "safe" intranet."
What does that mean, exactly? You direct the authentication process to a socket file and point the process to the admin's credentials? If the socket is on the DMZ host, and the credentials are on the private network host, how can you point the authentication process to those credentials?
Maybe I'm stupid, but the article didn't seem to make a lot of sense.
Re:Basic Stuff (Score:4, Informative)
When the admin logs into the DMZ host with agent forwarding turned on, SSH will create a socket to interact with the agent on the admin's machine. Since the wily hacker has root on the DMZ machine, he can write to and read from that socket with no problem, and thus can ask the agent to authenticate to anywhere that the agent is willing to authenticate to (what he actually would do is just set environment variables for SSH that say "I'm using agent forwarding, my agent is located at {admin's agent forwarding socket}").
ssh is not god (Score:2)
When ssh is your inter machine security model, you know something *must* be wrong.
Re:ssh is not god (Score:2)
Clever SSH setups (Score:2)
Interesting read though, made me aware of some security
AgentForwarding AS AN OPTIONAL FEATURE (Score:3, Informative)
Re:AgentForwarding AS AN OPTIONAL FEATURE (Score:4, Informative)
Rather than assume anyone^H^H^H^H^H^Heveryone on slashdot has any brains when it comes to Securing SSH let me give you some tips I/Other people have
Restricted ssh shell for scp/sftp http://sublimation.org/scponly/ [sublimation.org]
Patch to lock out IPs brute forcing passwords http://ethernet.org/~brian/src/timelox/ [ethernet.org]
Can add restrictions to authorized_keys file
from="hostipaddress",command="/usr/local/sbin/ssh
Securing sshd in
Protocol 2
PermitRootLogin without-password
PasswordAuthentication no
ChallengeResponseAuthentication no
ClientAliveInterval 60
ClientAliveCountMax 30
The first line says to stop using the old, lower security ssh protocol-1.
The second line is a hedge that says never allow root logins using the unix password -- always use some other authentication.
The third line says don't allow skey authentication. It is a good idea to turn this off if you aren't using skey at this time. (Skey implements a series of non-reusable, one-time passwords. If you were using it you would know.)
The fourth and fifth lines simply make sure that any connection to a client that doesn't respond at least once each half hour gets closed. After editing the sshd file, restart sshd or reboot for the changes to take effect.
31-12-2004: new rate-limiting feature in -current. This would block hosts that exceed 10 connections per 60 seconds.
pass in on $ext_if proto tcp to $ext_if port ssh flags S/SA \
keep state (max-src-conn-rate 10/60, overload )
block in on $ext_if proto tcp from to $ext_if port ssh
Also my previous post to do with limiting user connections to SSH during the scarey SSH port scanning days of not so long ago...
http://it.slashdot.org/comments.pl?sid=156058&cid
Repeated here for your convenience:
Ways around SSH Brute forcing (Score:1)
by meridian (16189) on 11:06 AM July 17th, 2005 (#13084357)
(http://www.thief.net/)
There are esentially three ways to fix this problem.
The first is to patch sshd which is probably the least preferable way as you would need to continually keep patching with each upgrade. But this seems effective allowing you to exec a system command such as iptables.
http://ethernet.org/~brian/src/timelox/ [ethernet.org] [ethernet.org]
The second is to use iptables to limit connection attempts from an IP address. One problem with this is people who use scp alot may quickly rack up that connection limit.
Here is a recent example from the iptables mailing list
iptables -A INPUT -p tcp --dport 22 -s ! $My_Home_Firewall_IP -m state --state NEW -m recent --name SSH --set --rsource -j SSH_BF
iptables -A SSH_BF -m recent ! --rcheck --seconds 60 --hitcount 3 --name SSH --rsource -j RETURN
iptables -A SSH_BF -j LOG --log-prefix "SSH Brute Force Attempt: "
iptables -A SSH_BF -p tcp -j DROP
The best in my opinion is a pam module found at http://www.kernel.org/pub/linux/libs/pam/modules.
This does not have the problem of the IPTables method that may mistake multiple fast scps etc as an attack attempt, and will not require coninutal repatching of the kernel such as the timelox patches.
There is a reason.... (Score:5, Informative)
>>>
Agent forwarding should be enabled with caution. Users with the
ability to bypass file permissions on the remote host (for the
agent's Unix-domain socket) can access the local agent through
the forwarded connection. An attacker cannot obtain key material
from the agent, however they can perform operations on the keys
that enable them to authenticate using the identities loaded into
the agent.
So wha is slashdot running an article about something where there is an explicit one-paragraph long waring in the man page of program at the option in question.
Yes, no doutbt there are a lot of idiots around, who without understanding,do things which require semantics which leads to a security leak (there is abolutely no way if you want to initiate authenticatication from processes on a machine to avoid root to do the same - as log as you are not asked on the agent's side each time before authentication;
Re:There is a reason.... (Score:1, Interesting)
Re:There is a reason.... (Score:2)
Even more fun, many sites r
Never understood why they invented the SSH-AGENT (Score:2, Insightful)
ssh-agent is a solution to grant any process on the system full access to a means of authenticating through your private key. No comment ! There's nothing difficult in ty
Re:Never understood why they invented the SSH-AGEN (Score:2)
Re:Never understood why they invented the SSH-AGEN (Score:1)
grand parent either hasn't had multiple terminals open to a half dozen (or more) remote clients, or is completely fine with typing a secure passphrase every single time (s)he wants a terminal... if any host is rooted, nothing's guaranteed after that... perhaps a binary has been been swapped out, or if you're running X11 forwarding, you're putting your own X server at risk, but I don't see what that's got to do with ssh... just don't put more faith in it than it deserves... running ssh isn'
Re:Never understood why they invented the SSH-AGEN (Score:1)
Suppose you frequently use a program that communicates over ssh connections, e.g. cvs, rsync, svn, or darcs. You wouldn't want to type your key's passpharse each time you run the program. Of course you never want to leave your key's passphrase null. Therefore, you need ssh-agent.
Because it's useful? (Score:1, Informative)
ssh-agent is a solution to grant any process on the system full access to a means of authenticating through your private key.
Any process? Presumably this is only if you have deliberately made the socket files world-readable?
The alter
Re:Never understood why they invented the SSH-AGEN (Score:1)
mind the ends... (Score:1)
which isn't news to anybody who's in the know about security or ssh... ssh isn't going to butter your bread, or do anything outside of securing end-to-end transmissions... I can't see anything new being introduced here...
another article from... (Score:1)
Trust: same problem as always (Score:2)
The idea of looking at the memory on the ass-end of an SSH connection is stupid. It's one of the ends, where the other trusted party lives. For all you know, your buddy prints your secrets onto nice vellum paper and gives it to the enemy. No electronics can save you if you can't trust the other
They haven't heard of ssh-add -c? (Score:5, Informative)
Re:They haven't heard of ssh-add -c? (Score:2)
I hadn't heard about this feature before, so I looked it up. All it seems to do is ask you for your passphrase every time a key is used. But SSH does this already if it can't find an agent, so I have to ask: Why would you use the agent with -c?
Re:They haven't heard of ssh-add -c? (Score:2)
Bullet proof is hard to come by (Score:3, Insightful)
Anyone with the time and resources is going to find a way into your network. Many times security does not have to be bullet proof. Don't have to be faster than the bear, just faster than the large majority of other networks. Unless there's something really compelling on your system, they're likely to pick an easier target.
I use my home network as an example. I have one copy of XP on my system. What I consider the weak link in the security chain. It's on a NAT'd segment, I don't surf the internet with it and anything sensitive is on a TrueCrypt partition that I only mount when needed. Hardly bullet proof but not bad for Windows.
2004 article mentions this (Score:3, Informative)
1998 CERT advisory (Score:2)
Summary to the Summary (Score:3, Informative)
Home/Office network compromisation in 4 steps (Score:2)
2: L33t Hax0r finds tunnel
3: L33t Hax0r GETS ROOT
4: Profit.
Both steps 2 and 3 in this reductive version seem pretty dubious. If you tunnel in to work, then sure, you're trusting the work network and machine not to be full of malevolent people, but even still, they have to get root on your box. You didn't tunnel in from root, now, did you?
Re:Home/Office network compromisation in 4 steps (Score:3, Insightful)
SSH-AGENT doesn't make a root level exploit worse (Score:3, Interesting)
I've cleaned up boxes that had been rootkitted, and if you can't identify when it happened so you can restore from a known good backup you're best off reinstalling from scratch.
The same thing is true, to a lesser extent, for local user privileges. Do you check that $PATH doesn't go through ~/bin before
Once someone can run unsandboxed code on your computer you're compromised, and any tool you use to examine your computer may be compromised, and ssh-agent make so little difference that it's simply not worth worrying about.
Copying from a man-page is not news (Score:3, Informative)
-A Enables forwarding of the authentication agent connection. This can also be specified on a per-host basis in a configuration file.
Agent forwarding should be enabled with caution. Users with the ability to bypass file permissions on the remote host (for the agent's Unix-domain socket) can access the local agent through the forwarded connection. An attacker cannot obtain key material from the agent, however they can perform operations on the keys that enable them to authenticate using the identities loaded into the agent.
So what's the news?
Re:Copying from a man-page is not news (Score:2, Interesting)
Re:This has nothing to do with ssh per se (Score:1)
If your DMZ box needs access to patches then sort out the patch server *pushing* them out. Or at the very least grab them on your workstation from the patch server, then push them to the DMZ host from there. Under no circumstances do this double-tunnelling tricks to allow the DMZ host *any* direct access to the internal patch server, even if it's to a single port, for a single daemon, that you think is coded corre