Slashdot Mirror
Overconfidence in SSH Protection
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?"
I consider myself fairly competent as far as this kind of stuff goes, but I just couldn't follow that summary at all. Maybe it's just because it's so late. Can someone post a more sensible summary of an attack?
So all I need to do is to get a root access to a Linux server and I can spy normal users there? Whoah, now this is what I call news.
Yep, just gotta get root. Of course, at that point, you probably have more to worry about than someone redirecting your ssh session.
SSH port forwarding can cause trouble. Where is the new?
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?
If I understand correctly, the author is talking about a complicated man-in-the-middle?
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?
I'm not a security professional, but aren't they talking about man in the middle attacks? And then further down in the article, isn't he talking about generic problems with running old, unpatched software on open servers?
but honestly, is there anything a bit of courteous knocking on the right door can't fix?
Error 407 - No creative sig found
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.
Ahhh...the great dumpster continuum. Many a free computer will be found there. -- sowth (748135)
No summary for you. It is like this guy writes cliffhangers for television shows. Maybe next season he'll finish some of his thoughts.
The key is not transmitted or sent to the socket file. This person does not understand anything about private key authentication and should return all of his certifications, and please stop posting stories by them, it is embarassing.
Maybe I read the article wrong but it seems to me like a problem with someones design and not with SSH, a little like saying Unix is insecure because a unwitty sysadmin could try to make his life easier by using a blank root password.
I think part of the article is trying to say that users can enable their own ssh tunnels to home, and thus if their home network is compromised there is an easy route into the office intranet.
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?Gan Family Homepage
I run SSH on Vista... does that mean Vista sucks too?
The article illustrated one very convoluted way to break your DMZ security, but failed to make the simple statement: don't trust anyone, not even root, on your DMZ hosts. Allow SSH logins into the DMZ, and allow the DMZ to pull files from private network patching servers, such as apt repositories, but don't allow anyone to SSH from the DMZ to the intranet. Assume the DMZ is cracked wide open and keystroke logging. No one is going to get past the DMZ by watching you type 'apt-get install squid' but they will by watching you type 'ssh root@creditcarddb.int' and then the root password.
... you can packet sniff the authentication process all day long and you won't get someone's private key.
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.
Here's a summary for you:
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)
It's not just you. I had to re-read it several times.
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 ssh to an attacker's machine using agent forwarding he can probably ssh back to yours.
Sig matters not. Judge me by my sig, do you?
It might be good but it's not god.
When ssh is your inter machine security model, you know something *must* be wrong.
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
I use SSH, I use it for tunelling VNC connections to remote sites for support.
Can't remember which way round it is, it's too early to be doing any serious thinking... but I believe you need both the private and public key at each end to do two way communication i.e. initiate an outbound connection from either host.
So on the DMZ machine you remove the key used to initiate an SSH connection and just leave the key used to check the incoming connections, voila, one way communication...
At least I think that's how it works in principle, certainly works in practice as that's how I've configured and tested it, like I say, too damn early to be thinking about this...
Anyway, on my config it's forced to use key exchange, you can't just login as normal so yeh the attacker can compromise a DMZ server but he cant get back into my central server, anyway, to compromise one of the DMZ servers he would need to be able to gain access to the physical machine as for security reasons all my remote machines are locked down as well, they just route the VNC traffic at the remote site.
Could a hacker get into one of my remote SSH boxes using a first day SSH exploit, errr very doubtful, they only allow incoming SSH connections from specific IP's, controlled by netfilter, not SSH.
Do I think SSH is secure ?, damn right I do...
Basically the article states that with too clever setups of SSH, you're likely just to fool yourself. I agree in one way, since it's true that SSH allows very complex configurations. On the other way, who trusts _any_ daemon that you can talk to from any host on the internet? I certainly don't. The article doesn't really mention the one thing I worry about SSH, a security hole in the server software itself. That's why I use iptables for a first defence.
Interesting read though, made me aware of some security issues I never thought about (probably since I just use SSH for direct host-to-host communication). But really, a more hard to understand article is hard to write. Took me a couple of reads to even grasp how the attacks work.
Maybe this randomly generated summary will help... at least it can't be much confusing :)
"SSH the wonder tool of the security set. I read one article about a vicious cycle! Want to know more? Comment on this article below. We'll skewer FTP and make a mockery of rsh. There are two types of port forwarding: * Local forwarding. Allows the client and the patching server, something normally verboten. The DMZ servers would route through the socket file, but something better (from his/her view) can be done. If the hacker can't get a copy of the agent forwarding risks. Depending on the local host adapter on any port the user chooses."
YES Thats correct you can use AgentForwarding.... If you are stupid enough to use agent forwarding to a host you don't trust or you would consider insecure ITS YOUR OWN STUPID FAULT IF YOU GET HACKED. Now for the evil h4x0rz to use agent forwarding on the host you connect to to hack the machine you are coming in from requires quite a number of things to be done on your stupid behalf that sure wouldnt be enabled by default and you would almost need to set them up purposefully. The only real danger with agent forwarding to an insucure host is that evil h4x0rz on that host can use your forwarded authentication agent to connect to boxes that are set up to both allow connections using that ssh-key AND allow tcp connections from any box that the evil h4x0rz have access to. Aside from that it is only as insecure as establishing a telnet session to the box and having some buffer overflow occur back to the client due to poor code on the client side. I am sure not about to stop using ssh for some "simpler" protocol like telnet but I will sure keep disabling AgentForwarding and any kind of portforwarding the hosts I dont trust and I ASSUME EVERYONE ELSE WILL CONTINUE TO DO THAT AS WELL. Otherwise you might as well start posting your root passwords to slashdot which may or may not matter if you have locked your systems down correctly in the first place.
meridian at tha.net
Why the developers of ssh have an option to forbid agent forwarding. Isn't it off by default? I cite from "man ssh":
>>>
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;
This has everything to do with using tunnels to circumvent network security zones. In this case, if the box you are tunneling through is compromised, this can easily lead to the unauthorized access of the box you are tunneling to.
Personnaly, I never understood how talented SSH developers came to the conclusion that they needed to invent such a crappy thing : ssh-agent. And I've seen people use it, the same people who put their private keys on USB sticks to ensure that nobody will steal them, but who are not afraid of collegues having root access on their machine ...
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 typing
a passphrase each time you connect to a remote site !
--
willy
high performance free load balancing solution - http://w.ods.org/haproxy/
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.
Wow, we're lucky that there's already a fix for this attack. It's called Rockwell Automation's Retro Encabulator.
watch the google video
No, in UNIX, most things are files. In Plan9, all things are files.
And I feel safe here since I don't use unix, I use GNU, and GNU is NOT UNIX!
That's not funny. Some of us actually care about this story. You're just wasting time.
At least in most corperate settings. Why? Central user authentication. You have something like LDAP or AD or whatever that makes it so one login works everywhere. Right, so if someone roots a box, all they need to do is su to a user and change that user's password, which will be propagated back to the authentication server. They now have access to everything, or rather they can log in to any computer as that user.
Just kinda how it goes if you want to have easy management. The only real prevention for this kind of thing is to compartmentalize everything. Each system has different passwords and such. Ok that might work if you have like 3 systems, but if you have 500, forget about it. Best you can do is compartmentalise the real critical stuff.
That's what we do. The somewhat critical stuff is on LDAP, but has no sudo and the root password is different from the normal one and also only allows logins from computer support accounts. The really critical stuff is not on LDAP at all. Works fine, but still using the "root one box, change someone's password" trick you get access to a ton of systems. Just goes with the territory. Good incentive for us to keep our patches up and firewall clamped down.
/me thinks this article is saying "the tunnel may be encrypted, but mind the ends"...
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...
mod parent up...
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't a cure for pop-ups, viruses, trojans, or erectile disfunction...
-yb
In UNIX, all things are files. To send network traffic, UNIX writes the traffic to the network device file.
That's plain wrong to begin with. I stopped reading there.
That's (a) true, but (b) not what the article is about. You are on box A, running ssh-agent. You ssh to box B. If someone on box *B* has root, they could theoretically use the socket file on box B to then ssh to any other boxes C,D,E... on which you have enabled key authentication, but only while you are still ssh'd in from A to B. There's a warning about it in the ssh man page.
If you have to do automated stuff, using the agent is still better than keeping a private key on box B, especially if you need a degree of automation that would entail having a null passphrase on that key.
If someone gets root on one of your boxes, all bets are off as there's a very good chance that they'll get root on another one of them (by keylogging passwords, brute forcing the password on a sudo enabled account, passwordless ssh keys, hijacking a session etc etc)
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 networks so if someone, say, gets at your DMZ there's no way to get into your internal or other production network i.e. no ssh or accessible services on your firewall machines on the DMZ interfaces.
i.e. It's not just an issue with ssh.
Will concentrate on the design flaws of TCP and UDP protocols; because obviously firewall NAT piercing is a security hazard (if you assume a FW equals security) and certainly those protocols are to be blamed (for making it so easy).
Btw I think the submitted part gives the right impression; imo the article doesn't contain much (valid) information, at least not in coherent form.
As far as I can tell, they're just describing an instance of the well-known problem of the man-in-the-middle attack.
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.
"It is our blasphemy which has made us great, and will sustain us, and which the gods secretly admire in us." - Zelazny
Zooooooooonk!
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 guy.
ssh-agent is inevitable.
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.
Overall I like the article for one strong point :
...
ssh allows EASILY circumvent a lot of security measures
Vulnerability requires users stupidity - like in the example here but man, can you honestly tell
you always had separate keys for each security zone ? You never used agent/X forwarding between zones ?
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)
It's worse than this! In your example, the SSH user has the authentication agent running on foo, so it's possible for anyone with root on foo to reuse the agent to authenticate to other machines. However, it's also possible to use the agent on any other machine that the SSH user has connected to, provided that they have enabled agent forwarding.
That's the problem! The administrator thinks he is safe because he is only running the ssh agent on his desktop machine. But he's not read the documentation, or thought about the implications of using agent forwarding. When he has agent forwarding enabled, every machine he connects to gets access to the ssh agent on his own machine. And, effectively, access to his private key.
To be perfectly honest it bothers me to think that there are any Unix administrators who are not already aware of this well-known issue.
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 alternatives to ssh-agent are password authentication and host-based authentication. I'm sure I don't need to remind you about the security issues with those!
If this fella uttered similar statements in the US about the prez, I'm sure the Secret Service would come knocking within the next 5 minutes!
thats the difference between real free speech and the pseudo attempt in the US
The article is about a common misconfiguration with regard to agent forwarding. The DMZ hosts aren't supposed to be safe, that's why they're in the DMZ and not in the intranet. The admin must assume that root on these machines is compromised. Consequently he doesn't store his private keys on any of the DMZ machines. But what many overlook, possibly because they don't use the feature, is agent forwarding. Once the admin has logged into a compromised DMZ host, access to his credentials is extended to the DMZ host by that ominous socket. The file itself never leaves the admin's computer, but if agent forwarding is enabled, root on the DMZ host can now point other hosts on the intranet to the authentication facility on the admin's computer. This misconfiguration enables the attacker to hop from the DMZ to the intranet. The correct way to avoid this is to disable agent forwarding (on the admin's computer, not just on the DMZ hosts, of course).
something like a use-agent is useful for clustering. Programs restricted to user X on the DMZ machine can use the user-agent to launch programs on other machines in their network. Does this undermine the security of the local network? Sure. Does this mean its unnecessary? No. The question really is whether you are willing to let the other machines be compromised. If a machine on the internal network needs special protection (ie it holds customer credit card info) then it most likely doesn't need to be part of the cluster and can be set apart.
Are there alternatives to user-agent for building distributed software? Of course, but they also add a huge security hole for the same reason.
At the end of the day, you could prob just consider the cluster one machine and assume all to be compromised along w/ the DMZ... I just wanted to defend the existence of agents in ssh.
When all else fails, try.
A few versions ago OpenSSH added a -c "Require confirmation to sign using identities" to ssh-add to take care of this. Or using something like SSHKeychain on OS X so it'll ask for confirmation for multi-hop auth, but not for connections direct from your trusted machine.
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.
That's our life, the big wheel of shit. - The Fat Man, Blue Tango Salvage
Tom Anthony
I doubt they came to the conclusion to invent ssh-agent. I imagine they released it to prevent other even more broken systems from being used. By providing a tool that is as good as it can be, no one creates an even crappier version of the same thing, i.e. one that stores the unencrypted key to disk or something.
Nerd rage is the funniest rage.
Don't use SSH to poke a hole in the firewall separating your DMZ from the intranet.
"Draco dormiens nunquam titillandus."
It's hardly news.
Just to state my position:
1. I am a UNIX sysadmin.* I'm paranoid. My worst fear is "Am I paranoid enough?"
2. The only really secure system is one that's been turned off, buried in concrete 100 meters deep, surrounded by 1,000 armed guards... and a minefield. Even then, I wouldn't be sure.
Anyone who believes in some magical security of some software deserves everything they get. Get real! Security (even for *NIX systems) is a dynamic thing. If you're tasked with securing a M$ system - you have my sympathies, but at least you know that one.
* - OK - for those who know me, yeah, yeah - I'm really a biochemist.
I block brute force password attacks on my home system by having a process monitor the sshd logs so that if a host fails to authenticate five times, its IP is added to my firewall's deny list. The attacker then gets to see his future connections time out. I do this rather than reject the connection outright to slow the attacker down. It's fun to think of the attacking system hanging on a partially open socket until it times out. Simply rejecting the connection would be too kind.
Could this setup be used for a joejob? Yeah, particularly since two hosts behind the same NAT system look the same to me. The risk is low though and doesn't matter since I have physical access to the box and nobody else does.
Oy! Slashdot you need to RTFM!
Wow, news flash: Misconfiguring ssh will result in a security hole! Who ever would have guessed?
"Once the admin has logged into a compromised DMZ host, access to his credentials is extended to the DMZ host by that ominous socket"
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)
Weapons of Mass Analysis
1: Enable an SSH tunnel
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?
Returned Peace Corps IT Volunteer
This is the sort of thing George Galloway says, although I sort of agree with him. (Is that a tank I see driving towards my house?)
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 an SSH or telnet client from Haven's command line. What ? Haven doesn't have them ? Then I simply send one, piping encoded data to uudecode, or perhaps a mail client (to send the file to the users own account - if it's machine-local delivery, it propably won't go through the companys mail server and won't be stripped for binaries), or maybe simply through some insane sed script to turn hexcodes back to binary format - but one way or another, I'll get the telnet client to Haven.
Well, now I have telnet in Haven, and can connect to any service running at Haven, with the connection seemingly originating from Haven itself. And of course I can connect to other intranet machines as well. Or I could use some kind of hex-to-bin proxy telnet-like program, and another one on X, to emulate agent forwarding.
The point is that as long as there is a connectiong between X and Haven, and Haven gives the user a command line interface, it is impossible to prevent the user from forwarding arbitrary connections over it. Or at least simply preventing SSHs native support for that won't stop it from happening.
The lesson: any machine that gives shell access to untrusted machines is untrusted.
Forget magic. Any technology distinguishable from divine power is insufficiently advanced.
Okay, so let me just get this straight. Executive summary, "moral of the story," whatever, is...
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.
"Ladies and gentlemen, my killbot features Lotus Notes and a machine gun. It is the finest available."
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 on the system running as you or as root, you mean.
Or as yourself. It will be a real joy for virus writers when they will start to attack unix mail and web clients. We are currently laughing hard at windows with the users' address book sent all over the world by viruses, now you will simply open all your hosts to the rest of the world thanks to your agent and one undetected input relay running in your browser. Kind of smart !
And to reply to the other poster, yes I'm running all days with a dozen of terminals, and quite frankly, typing the same
passphrase 30 times a day trains you enough to type if without even thinking about it.
The author of the article needs a banana. That's one of the most poorly-written articles on security I've ever had the misfortune of reading. Worse, it didn't say anything useful.
Presumably, the sysadmin has also compiled ssh to use tcpwrappers (hosts.allow, etc.). Nobody gets in unless listed by IP. But, of course, tcpwrappers are not mentioned as a security precaution in the article. That would be too obvious. However, there can still be problems if you're foolish enough to allow DMZ boxes that have other security issues on the list. I don't know about you, but I rely on Betty Crocker to secure important web servers. I just smear them with a protective layer of chocolate frosting.
Ssh is enabled by default, you have to say no during the installer to disable it. And inetd is running by default, including several typical unix services. Ones which are considered universally "broken" and "security holes" in linux/unix circles. Despite it being this way for so many years, there's still only that one remote vulnerability.
That's the other way around and not the topic of the article. The article talks about a connection from a safe host to a compromised host. You're talking about connecting from a compromised host X to a safe host Haven. If you're on a compromised host, you cannot safely ssh into another host. That should be obvious. But there is no technical reason why a ssh connection from a safe host to a compromised host should enable the attacker to do anything he couldn't do before. That is, unless agent-forwarding is enabled. With agent forwarding, not only the admin's commands end up on the compromised host but also the admin's authentication power. Sending commands to a compromised host is not a problem, but accepting authentication requests from a compromised host (which is what agent forwarding does) gives the attacker access to other supposedly safe hosts. You wouldn't copy your private keys to an untrusted host, but if you use agent forwarding and ssh into an untrusted host (and not necessarily out again), the effect is very similar.
DMZ hosts are typically configured so that they can NOT connect out to hosts outside the DMZ. This is enforced by firewall restrictions. As long as this is done, there is no problem.
A slashdotter who didn't build his own computer is like a Jedi who didn't build his own lightsaber.
When using SSH tunnels your application and the tunnel are not properly coupled. It is an universal problem with all the solutions where you secure some application by using SSH port forwarding. It can also be extremely dangerous.
The another easy way would be to use OpenSSL sockets. It requires a few lines of code, but not much. And it couples your application with the security methods properly. Yet it is not used commonly. Personally I would call using SSH tunnels incompetence.
No they don't, at least not if configured correctly. If you don't allow split tunneling then once the VPN is established all traffic to the rest of the world is disallowed, this is not possible AFAIK with simple SSH. This only applies to driver based VPN solutions not SSL based ones.
There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
For the number of incorrect restatings and appraisals of an article?
People's working definition of DMZ (De-Militarized Zone) depends greatly on the hardware they use.
If the only network you admin is a Linksys box connected to a few computers and a cable modem/dsl, the DMZ (as defined by Linksys/D-Link/Belkin) is the IP address all incoming packets are forwarded to. Effectively, one of the computers on your internet is directly connected to the internet. Trafic between the 'DMZ Zone' and the rest of your network is unmonitored by the router.
If you use something more sophisticated, such as ipcop.org (runs on any ancient machine and a few network cards) or a true firewall appliance (ShoreWall, Cisco, etc), then you have the option of having the DMZ a seperate segment of the network. You can have incoming connections forwarded to different boxes in the DMZ, all of which can communicate with each other and the outside world, but cannot talk to things on the other zones without explicit permision (called DMZ Pinholes in ipcop).
Of course, you can also achieve this by cascading routers, as one of my friends does. He likes to share the internet freely with his neighbors, so anybody in range can connect to the internet via his wireless router. They cannot connect to his personal hardwired computers, as those are behind a seperate router which is itself plugged into the first router.
"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."
/. stories that started like, "We're setting up a company and would like to know how you would do xyz with "linux" vs Windows, how long you've been using "linux", how you got approval for it, and how long you have successfully maintained security with the limited headcount you have..." that (if you are cynical) sound like big-company-paid-for pieces meant to flush out Unix/Linux-leaning companies that "ought" to be on ms/windows-related stuff.
/. would agree to a reader-demanded aversion to corporate-paid slipstream submissions... (opps, a ladder and mop bucket are being hurled my way...(instead of conference room executive chairs)...)
Remember the
Just from the "in unix, everything is a file...." I started seeing big money funding this article. I could be wrong, though...
I wonder if
Previously: "Linux... Toward the Sunrise..." Now: "Linux... Toward the-- No, now, part of Every Sunrise"
Didn't you KNOW???!!! /. is a DARPA project. They story is a deception piece meant to cull the best of the best among the ./ (yep, ./) crowd on /.
You will be recruited shortly. Your fate, should you chose not to accept recruitment, is to see your surfing logs forwarded to your employer...
Previously: "Linux... Toward the Sunrise..." Now: "Linux... Toward the-- No, now, part of Every Sunrise"
If a bad guy has the ability to bypass local file permissions (whether because he's root or because you screwed up the permissions) then he can steal your credentials by putting a backdoor in the SSH client, the SSH server, the terminal driver, the file system, shared libraries (glibc, for example, is so huge and complex you could hide a trapdoor, magic hat, rabbit, three cages of pigeons, and a performing elephant there and nobody would notice).
/usr/bin before you run ssh?
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.
Of course, any user sufficiently proficient to set up their own ssh tunnel to home will probably be more concerned with opening an easy route into their home network from the office intranet than the other way around (which says more about the state of many office intranets than the ease of ssh tunneling).
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 anything from http through smtp to telnet.
As such, the problem becomes merely a policy issue; tell your 'power users' they're not allowed to create tunnels outside the intranet (and if the firewall policy has them creating tunnels to do their job, there's a serious problem with the firewall policy), and concentrate your efforts on problems with a vastly higher ROI.
There is always ways around the split tunneling problem. USB drives, DVDs, non TCPIP networking, etc..
I don't get this argument. Someone who tunnels to/from the office is no more dangerous than the same person who takes their laptop home and plugs it into their home network. Anyone who is allowed to take an IP enabled device from work to home is an equal security risk. I think that reverse port forwarding to localhost is better than VPN. VPN changes the network topology and can cause havoc and confusion. The amount of beaurocracy involved in VPN configuration is huge in a large organisation. All reverse port forwarding does is presume that if something can get out, then it can get back in. If SSH is sledged because it can do this, then the same userbase will just move to another protocol which can do exactly the same thing.
Being as filled with tripe as you claim, I might have thought I wrote simply enough for you to understand. I guess not? Under agent forwarding, the first hop device doesn't have the private key. You might review the documents on OpenSSH to understand ssh better. In there, you will find big precautions against agent forwarding in an environment that has high potential for compromise. Would you mind posting these enlightening comments of yours on the actual Informit site?
Please explain the details: how they are prevented. If you're talking about a firewall, that is the typical block. The issue is this: Once intranet box a connects to DMZ host, the tunnel can be used by the DMZ host to contact box A. if box a has forwarding rules, dmz host can contact all boxes box a can connect to, including all devices is private IP/RFC 1918/3330 devices. So, here is my point, Organizations switch from ftp to ssh for web content posting, for example. If users don't understand forwarding, their machine may be a portal into the intranet, and if you see the connectivity from the firewall, all you have is an intranet to dmz connection. Indeed a few internal customers were approached by external support staff who wanted to use this design, calling it safe because they'd only have the connection terminating at localhost. However, once one has root or Admin on a box, the actual forwarding rules and cron/at job building outbound ssh connection, well, that exercise is left as a challenge to the student... jt
SSH software, in both the server and client implementations, has the ability to both build an encryption tunnel and then force and forward traffic in thru the tunnel. As you review this ability on the internet, many are advancing a configuration whereby you connect to your home/external SSH server, and you do so with forwarding rules built into your work PC. Once home, you configure the home/external ssh instance to force outbound traffic to Mywork.org into the tunnel. Once the traffic hits your work PC, it is forwarded back into your workplace. This allows you to do support work w/o VPN clearance and the like. It also has been used in unsafe designs such as connecting the dmz host to the intranet patching server. Now, for your firewall's perspective, this is sole an inside to outside initiated ssh connection. This is one of the more difficult abilities in ssh to describe and discuss. I hope this summary helps. jt
No, not at all. When you consider the forwarding abilities of both the ssh client and server implementations, it is possible to build what looks to be an insider-initiated tunnel to the outside. Safe, right? Instead, the tunnel is used to force the traffic from the remote server back into the tunnel, and from there, throughout the intranet, including RFC 1918/3330 addresses normally unreachable from the Internet. Let me know if some kind of video file would help explain a very difficult topic in ssh. Many organizations are swapping out telnet/ftp for ssh. That part's great. It's the uncontrollable forwarding abilities that seem the biggest challenge.
Thanks for your great post. I wouldn't be surprised if most who read it rush over it. You see, ssh's Rep is as a great drop-in for ftp/telnet/r*. Some Unix folks have little networking background (Ahhh, the scourge of DHCP!), so they gloss over the 'other stuff'. This is in the documentation and EVERY vendor is very frank and honest about the risks. But folks get so keyed into the agent forwarding benefits, they write it off. As you review the internet literature on the topic, you'll see the configuration I discuss is commonly recommended for those who want a 'private vpn'. So spread the word about this risk--use small words though. jt
No, as you study ssh, you find the first box has the private key. In agent-forwarding, an intermediary machine will proxy the authentication from the first box to the 3rd and final box. IF someone has root on that intermediary box, without having your private key, without your password, etc, s/he can proxy the authentication from your first box to all other boxen for which you have an account and presence. Admittedly, this is very difficult to understand, but the vendors warn against agent-forwarding in strong language. There are great ssh book by Apress (my fav) and O'Reilly. I hope this helps. If not, leave a comment at the informit site and I'll try a longer follow up. jt
The news is this: 1) organizations are using ssh as a wholesale tradeout of ftp/telnet; 2) support vendors want to use the tunnel to support your intranet PC; 3) there are many articles discussing how to use SSH as a 'private VPN'. At this point, organizations need to ensure all groups in charge of security have thought through the issues. I hope this explains how a common vulnerability is bigger news: it's growing and outside of ssh people like you and me, too many don't know this risk exists. jt
So let's consider a typical ssh configuration. The intranet machine has the admin's private key. S/he connects to the first DMZ machine. Now because agent forwarding is enabled, despite the vendor's strong recommendations, the admin goes to DMZ device c. The Intruder observes this and can misuse agent forwarding's abilities to hit other dmz machines. Why? In the same way box b proxies the authentication to dmz device c, the Intruder can hit other devices and box B will proxy that authentication. Difficult to understand? Sure is! So why don't people just do as the vendors recommend and not use it in high risk environments? Being difficult to understand means this risk is dismissed as irrelevent and admins take the easy route: use agent forwarding. jt
Who on Earth modded this drivel "insightful?"
Here:
$ for host in [100 hosts]; do ssh $host [something useful]; done
Have a nice few hours typing your passphrase.
If you have a video to hand, then share it for I'm sure it will help a lot of people.
Exactly. Great analogy as well. jt
As I review the comment, I find several are insightful and good. Others? People should not have a first beer before posting to slashdot. Here are the issues: 1) many are using ssh as an ftp/telnet drop-in replacement; 2) few understand port forwarding or how agent forwarding works and dismiss vendor recommendations in both their designs, and surprisingly, articles that are available; and 3) there are many articles on using ssh as a private vpn from home. These trends mean there must be greater awareness on SSH security and design. 4) support vendors are asking your organization's users to provide connectivity to their PC's via an outbound ssh tunnel. I'm glad readers like you have studied the risks and the vendor recommendations. Tschuess, JT
You're mixing up agent forwarding and port forwarding. Anyone stupid enough to open a reverse tunnel from an unsafe host gets what he deserves. The article is not about that. It's about the authentication chaining mechanism called "agent forwarding". If you don't know what that is and how it's different from port forwarding, have a look at the OpenSSH documention. Blocking all connections from the DMZ to the intranet indeed removes that attack vector, but if the admin allows connections from the internet to the intranet (because hey, SSH is safe, isn't it), then the attacker can still use the authentication facility which has been forwarded to the compromised DMZ host. Better disable agent forwarding.
You're not stupid by any means. There is a lot of ssh activity nowadays, and many organizations don't understand the problems they've created. The illustration regarding access to an intranet patching server is a great example of the convoluted designs many are proposing. A user group bought a turnkey system from a vendor. how will the vendor support this intranet host? The user is instructed to ssh to the vendor server and . . .
I appreciate your commonsense prohibitions. Now imagine an organization feels people should get outbound ssh to the internet to the degree they get ftp. Better security, right? Hmmmmmmmm, so if Rogue Insider gets connectivity to an ssh server s/he controls? That connection is now an afterhours direct path into the company intranet, and there's little one can do. In this case, your very excellent recommendations seem to apply a little less. This is the ssh challenge: to get all the experts knowledgeable on ALL of ssh's abilities. Get a plan on handling ssh to the dmz and keep folks from using port forwarding in unwise ways. For every ssh expert on this list who was very wise in pointing out the vendor's security statements, I think we can see there are quite a few who struggle with the topic. It's a very difficult topic. I'm glad you took the time to strongly support the solid principle that DMZ hosts need to be contained. Admins who break that rule with any tool jeopardize much. jt
Great response. As you read from other responses, some don't know about the risks of Agent forwarding. They either don't read the vendor's very strong warning against it or they don't understand the full impacts. So they enable it. And I agree with you; enabling it in a DMZ setting makes for very strong risks. And I'm amazed why people don't see the risk as clearly as you do. I _like_ agent forwarding in an intranet setting when I'm working as a basic user. I have my private key on a cdrom. I ssh to a gateway machine, and from there, I can access the other servers, one at a time. Do intranet hosts get hacked? Sure do. But maybe a little less than the DMZ hosts facing the Internet? It helps to have a gateway box with tight security and good logs and IDS... jt
-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?
Right up to and until the machine is infected without using VPN...once they're compromised, bringing up VPN allows that worm to poop out port 80 request through your network all it wants (and hence has two way communication into your soft-chewy center.)
"Draco dormiens nunquam titillandus."
I agree with a lot of this commentary. I can't believe how many root users want '.' in their path. Just as bad? 'su' or 'sudo su' . Add a little dash and get root-appropriate settings--don't inherit the PATH you have as a basic user. I agree that there are many things an intruder can do to a compromised system. That said, I think we should do as the SSH vendors recommend: DON'T use agent forwarding in a potentially high-risk environment. We don't need to add to a hacker's abilities by doing something that risky. I like ssh and think it's a great security AND connectivity tool. Job 1 is ensuring your network, server, etc architects understand all of ssh's abilities before enabling it wholesale. jt
SSH is a great tool, full of great abilities. Any tool with so many abilities is open to misunderstanding, misconfiguration, and misinterpretation. Ditto for Linux. if you felt my article condemns ssh, you're incorrect. jt
Excellent! I'll reconstruct my test environment and make something good happen... jt
They're talking about the ssh Agent, specifically key forwarding and the ssh agent. Key forwarding can be bad if one forwards to an untrusted machine. Very...very bad.
"Someone who tunnels to/from the office is no more dangerous than the same person who takes their laptop home and plugs it into their home network."
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. These tend to be less fraught with beaurocracy and are often used for roaming workers.
Of course, sometimes-on VPN's that just cut the connection to the local network are just as much a viral and intrusion vector as anything else. There's nothing preventing the host from infections and intrustions when the VPN isnt on, and when it is, there's nothing preventing the infected host from punching tunnels through the corporate firewall to the outside.
Like you say, any IP enabled device is a risk, and when I see articles like this one I usually suspect someone's been trying to sell the author something. After all, there's no snake oil like security snake oil.
Actually it's because the article itself is based entirely on "common misunderstandings about Unix"
Seems to be pretty old. Here's a 1998 CERT advisory with the original SSH 1 exploitable under the exact same conditions: http://www.cert.org/advisories/CA-1998-03.html
I read this bit and was a little concerned - but only for a moment
I then saw the light - you're writing about the only non-file component of Unix; the human component. That's what you mean, isn't it?How many beans make five, anyhow ?
A slashdotter who did not build his own computer is like a jedi who did not build his own lightsaber.
So does this apply to the female jedis or are girls only to stand around in skimpy outfits and be oggled by geeks??
I am not a robot. I am a unicorn.
Let me get this straight. Your threat model is an attacker who has root and can therefore hijack your ssh-agent, but is too stupid to grab your password when you type it in one of those 30 TIMES PER DAY?
If your system is rooted, you're toast. It's that simple. Pretty much the only way to defend against malicious root is to used an advanced access control model like MAC, and lock everything down. It takes a fair amount of work to set up, and aside from limited use by security-conscious organizations and overzealous geeks, MAC implementations are practically unused.
> 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
Isn't politically correct writing precious!
The world record for unassisted bench press is a little over 700 pounds. However, the person wishing to bench press more can use a special shirt that binds up the muscles. With this shirt, he or she can lift as much as 1000 lbs. The shirt wraps his or her muscles tightly, preventing the arms from easily lowering the bar to the "down" position.
(-1: Post disagrees with my already-settled worldview) is not a valid mod option.
The DMZ hosts aren't supposed to be safe, that's why they're in the DMZ and not in the intranet.
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.
In American English, there is no gender-neutral pronoun. Most English instructors recommend the author choose whichever pronoun he feels most comfortable using when speaking abstractly.
What country are you from and what pronoun do you use?
A slashdotter who didn't build his own computer is like a Jedi who didn't build his own lightsaber.
root has root access.
um i think this is either a case of
1 ~99.99% of slashdot geeks are in fact male
2 he and his are assumed neutral gender
but i think that getting beaten by a female "warrior" has an extra +20% damage to fame
why does anybody think that a mangled config on any guard software won't cause "issues"
Any person using FTFY or editing my postings agrees to a US$50.00 charge
You might try port forwarding and examine the traffic across your firewall logs. With my pix and IP Tables, the port forwarding traffic simply looks like return encrypted traffic. In the article, I describe how many people implementing ssh are 'mixing it up', using all the abilities in really bad ways. In fact, if you have a working ssh server on the internet, try to connect to it and build the port forwarding scheme I describe. If you can build the outgoing tunnel, the traffic from home will work, despite a firewall's normal restrictions against external-initiated traffic. An internal customer was approached by a support vendor for a turnkey system for just this kind of config. jt
I hope the last line is back on track to discuss ssh. The issue with ssh, for me at least, is how much is 'userspace', right? Ask most UNIX sensei about people building tunnels, and they laugh because the user needs root for many networking functions. The client side abilities and linkage to a user-controlled external box is all it takes to puncture a hole in the perimeter--an unmonitorable one I might add. And if you ban outbound ssh at the firewall, well, that's no good. SSH can run on any TCP port the attacker configures. Allow outbound 80? How about 53 for dns? 25 from any internal host for mail operations open? And now, what about internal users who are duped into building the outbound tunnel so as to enable support for a turnkey system? I admit you are very right. People who go with stupid configs deserve the worst. But the damage doesn't end with them, right? A successful intrusion on one platform soon ripples to others based on what passwords/credentials are harvested from the first.
Sorry, you're wrong. See the singular their.
As I understood it, it's "Don't use agent forwarding when the box you are connecting FROM is untrusted". So, if you don't trust root on your machine, don't use the agent :)
I'd say that if you don't trust your local root, you're in far worse trouble than this.