Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

35-year-old vulnerability discovered in scp

sintonen.fi

Post reply on HN
Print view View original

41–50 of 158 posts

Re: 35-year-old vulnerability discovered in scp

#41

Post by leni536 »

reacweb wrote: post #21
leni536 wrote: post #7

Earlier quoted context omitted.

> The attacker controlled server [...] drops .bash_aliases file to victim's home directory This can only happen if scp is invoked from the home directory (or from root or /home).

The server could also drop a "ls" file with execution rights in current directory. If "." is in your path before /usr/bin (I have already encounter that), it may be called as soon as you type ls (generally just after the scp).

Sure, it can also drop filenames starting with a dash, filenames with spaces/newlines in it and all sorts of stuff. These can cause all kind of havoc in poorly written scripts. Having "." in your path is an obvious misconfiguration too.

Re: 35-year-old vulnerability discovered in scp

#42

Post by close04 »

jedberg wrote: post #24
rocqua wrote: post #20

Earlier quoted context omitted.

> the server your home directory is on is compromised The attack presumes your home directory is client side, and you use SCP to connect to any kind of server, whilst ~ is the client side open directory. Thus, any server you might SCP to could write to your local home dir. In university, I did this with compute clusters, servers of my association and other servers. This breaks the SCP security model because it means…

Right I get all that (I updated to clarify that I understand the attack is against your local home dir, but I assume you have one on the remote side). I just don’t understand the use case of scp’ing from an untrusted host.

> I just don’t understand the use case of scp’ing from an untrusted host

You are SCPing to an untrusted machine, not from. Your client is trusted, the server you are connecting to is not.

Sometimes circumstances push you to connect to a server that is "semi-trusted" as described in the comments above.

Re: 35-year-old vulnerability discovered in scp

#43

Post by h1d »

jedberg wrote: post #10

I think I'm missing something. Step one is getting you to use a compromised server. Which either means the server your home directory is on is compromised (I’m assuming you have a login on the box, separate from your local home dir), in which case scp is the least of your worries, or they get you to bounce through a MITM server, in which case you have to accept an incorrect host key. If you're accepting incorrect hos…

In my honest opinion, delegating the trust model down to the user to figure out which host key is trusted or not is the broken model. I always blindly accept the key because I have no way of knowing what is good or bad by looking at the prompt with random letters telling me it could be bad and in my life 100% of those alerts are false positives and I got used to accepting those alerts.

Re: 35-year-old vulnerability discovered in scp

#44

Post by hkt »

jedberg wrote: post #10

I think I'm missing something. Step one is getting you to use a compromised server. Which either means the server your home directory is on is compromised (I’m assuming you have a login on the box, separate from your local home dir), in which case scp is the least of your worries, or they get you to bounce through a MITM server, in which case you have to accept an incorrect host key. If you're accepting incorrect hos…

Honestly, I revisited my old sdf.org shell account last night - this could have got a lot of people on shell providers and similar down the years. Keys wouldn't need to change in the event of a compromise.

Re: 35-year-old vulnerability discovered in scp

#45

Post by zwp »

jedberg wrote: post #24
rocqua wrote: post #20

Earlier quoted context omitted.

> the server your home directory is on is compromised The attack presumes your home directory is client side, and you use SCP to connect to any kind of server, whilst ~ is the client side open directory. Thus, any server you might SCP to could write to your local home dir. In university, I did this with compute clusters, servers of my association and other servers. This breaks the SCP security model because it means…

Right I get all that (I updated to clarify that I understand the attack is against your local home dir, but I assume you have one on the remote side). I just don’t understand the use case of scp’ing from an untrusted host.

In the B2B world there is a perhaps surprising amount of ad hoc data transfer (transactions, statements) between separate entities using scp/sftp from a cron'ed ksh script written by a junior sysadmin 8 years ago.

Throw a Tectia server in the DMZ, fix the firewall, manage some keys (never change them) and you're good to go! Data at rest security via Zip or PGP for the ambitious.

Occasionally a big enough entity will mandate "everyone will use our data xfer spec" (and it's typically some gnarly XML-infested SOAPy animal). But there's a whole lot of automated business processes doing CSV-over-scp both intra- and inter-company.

Don't even get me started on FTP.

Re: 35-year-old vulnerability discovered in scp

#47

Post by unilynx »

kurlberg wrote: post #37
jedberg wrote: post #24

Earlier quoted context omitted.

Right I get all that (I updated to clarify that I understand the attack is against your local home dir, but I assume you have one on the remote side). I just don’t understand the use case of scp’ing from an untrusted host.

Throughout the years my employers have reinstalled servers and consequently changed host keys. I believe many users just accept the new key without realizing what they might get themselves into. Ideally your organization should keep updated (public) host keys somewhere, say on some https-protected website so you can double check yourself. How common is this? (I mainly use ssh for interactive/tunneling use, but with a…

Ideally they set up SSHFP dns records with the hostkey fingerprints

Haven't yet encountered it in the wild though

Re: 35-year-old vulnerability discovered in scp

#48

Post by h1d »

jakobegger wrote: post #16
korpiq wrote: post #8

Earlier quoted context omitted.

I read it as being MitM and manipulating target (final, originally intended server) directories and files only, and in addition to spoof output to client to hide the fact it's doing so. In that case it does not matter where you run the client. What makes MitMs possible is that checking fingerprint of new host is left to user. Instead we should have processes to automatically 1. acquire via other means and add fingerp…

There is already a solution to this problem, which is host key certificates. All you need to do is configure your SSH client to accept only host keys signed by your CA. However, setting that up is complicated. You need a lot of knowledge to set that up securely. On the other hand, manual verification of host keys is trivial -- anybody can compare a short string of characters.

Trivial but who does that when? I never even learnt what I should compare that with and just accepted everything (and have been safe that way).

Re: 35-year-old vulnerability discovered in scp

#49

Post by 0x0 »

jedberg wrote: post #24
rocqua wrote: post #20

Earlier quoted context omitted.

> the server your home directory is on is compromised The attack presumes your home directory is client side, and you use SCP to connect to any kind of server, whilst ~ is the client side open directory. Thus, any server you might SCP to could write to your local home dir. In university, I did this with compute clusters, servers of my association and other servers. This breaks the SCP security model because it means…

Right I get all that (I updated to clarify that I understand the attack is against your local home dir, but I assume you have one on the remote side). I just don’t understand the use case of scp’ing from an untrusted host.

Because the remote host could be compromised/hacked even when you "trust" it, this could easily be used to jump from a compromised auxiliary external server to owning the internal laptop/desktop of a domain-wide administrator, for example.

Re: 35-year-old vulnerability discovered in scp

#50

Post by Kovah »

h1d wrote: post #43
jedberg wrote: post #10

I think I'm missing something. Step one is getting you to use a compromised server. Which either means the server your home directory is on is compromised (I’m assuming you have a login on the box, separate from your local home dir), in which case scp is the least of your worries, or they get you to bounce through a MITM server, in which case you have to accept an incorrect host key. If you're accepting incorrect hos…

In my honest opinion, delegating the trust model down to the user to figure out which host key is trusted or not is the broken model. I always blindly accept the key because I have no way of knowing what is good or bad by looking at the prompt with random letters telling me it could be bad and in my life 100% of those alerts are false positives and I got used to accepting those alerts.

Could someone elaborate on how to find out the correct key of a host that was recently setup, like a new Digitalocean instance? Is there even a method?
Post reply on HN