
Pwning your web server the easy way or why exposing –/.ssh/ is a bad idea - gehaxelt
https://0day.work/pwning-your-web-server-and-network-the-easy-way-or-why-exposing-ssh-is-a-bad-idea/
======
pdkl95
> For some of them, the www-data's home directory is the DocumentRoot

“Well, there’s your problem.”

Don't expose any ${HOME} to the world! SSH keys are not the only exploitable
file in a typical homedir (or even auto-generated from /etc/skel/)! A few
files that come to mind:

    
    
        # other keys
        ~/.gnupg/
    
        # probably lots of app-specific risks
        # (e.g. saved login info)
        ~/.cache/
        ~/.config/
        ~/.local/share/
    
        # if it's also a desktop system running X
        ~/.Xauthority
        ~/.mozilla/
    

Yes, protecting ~/.id* with a passphrase is important and leaking
~/.ssh/known_hosts can have consequences, but this type of exploit shouldn't
even be possible. Don't share your homedir - which contains most user-level
config files on UNIX systems - with the world. DocumentRoot needs to be
contained in a subdir. (edit: or even better, contained somewhere outside of
/home where it won't overlap with common file paths)

~~~
jmole
why would www-data need a private key though?

~~~
sowbug
It doesn't, but if someone is shelling around on the server, they might throw
a key in there for convenience, maybe in order to scp something from another
machine, and then forget to remove it when they're done.

One can debate whether the root cause is forgetfulness, or rather that people
shouldn't be sshing into prod servers to begin with.

~~~
im3w1l
Ever putting private data in a public place, is an unacceptable risk. Even if
you remember to remove it there is a window of vulnerability. And there are
people out there constantly probing for weaknesses.

------
jrochkind1
Exposing a private key to the world is a security problem? No kidding?

~~~
the_alchemist
As long as you keep the public part private, there is no issue ;)

~~~
MaxBarraclough
From what I see on StackExchange [0] that's probably untrue.

[0]
[https://security.stackexchange.com/q/172274/](https://security.stackexchange.com/q/172274/)

------
danielparks
The www-data user (or whatever the web server is running as) should not own
any files that are served by the web server. The user should not be able to
log in either (its shell should be /bin/false or something similar).

Use an entirely different user for file ownership.

------
AdmiralAsshat
The files in ~/.ssh are usually initialized with restrictive permissions, so
how do they end up getting exposed? The only way I can think off-the-bat is
that someone absent-mindedly commits them to their git dotfiles and ends up
copying them over to another machine when they do a `git clone` command.

~~~
znpy
> so how do they end up getting exposed?

the author cites "allowing developers to connect to the host with the www-data
user", and this is a very specific form of incompetence.

www-data is the name commonly used by debian and debian-based distros to run
apache and other http servers. it's literally, just designed to run the
executable, not to upload new version of webpages or anything.

there are countless ways to avoid this pitfall, the simplest that comes to my
mind is creating another user for uploading stuff and adding such user to the
www-data group.

at the end of the day... meh. people might start a campaign about how not to
use the www-data or something else, but not-very-techy people will find
another way to misuse a webserver.

------
coldtea
Next up "Leaving your Ferrari parked with its doors open and loaded with new
iPhones in Downtown L.A. can incur a theft problem"...

------
closeparen
You do not need to put keys on the web sever’s disk to SSH onward from it. Use
agent forwarding instead.

~~~
egwynn
Or even use `ProxyJump`, which doesn’t put as much trust on the jump host!

~~~
gehaxelt
Good points!

I've updated the post.

Thanks!

------
terlisimo
Sane nginx default for 99.999% sites out there:

# prevent access to any file/dir beginning with a dot

location ~ /\\. { return 404; }

------
Scarbutt
You really have to go out of your way to make the www-data user available
through ssh, weird some do this.

~~~
kjs3
I can tell you exactly how it happened: someone thought that this was the most
expedient way to do something they wanted to do, they unfortunately had rights
to do it, and they just did it without considering for a minute the
consequences. Happens all the time.

------
eqqn
You can sometimes grab these ssh keys if the server has a severe directory
traversal, local-file-inclusion vulnerability(run server/DB as root) , or to
use for pivoting to different user/machine... But never heard of these being
exposed outright.

------
maury91
Or "how leaving the keys in the lock when you are not a home is a bad idea"

------
OrgNet
lol...

in other news: Pwning your passwordless web server the easy way

------
DaniloDias
TL;DR: Antipattern: pointing web server config to any files based in /home.

~~~
asveikau
Not just that. Even if you don't make that mistake, having servers ssh into
other hosts and leaving keys on them for this purpose means if one machine is
compromised, others can be too. And they can use known_hosts to discover which
ones.

~~~
arpa
ssh -A is a thing. A risky thing, but so much better than keeping private keys
on server.

------
bfgpereira
This is what I have learned in many years of work: people who know systems
should be let to handle those systems.

This is what happens when a developer is left to do the work that a system
administrator should be trained to do - not all are -.

For a developer, in most cases, "just works" is the end goal, when referring
to systems. Not "how it works", and what are the implications of making it
work like this.

This really makes me sad.

~~~
scarejunba
Sys admins are dead. I have GKE now via a reliable Terraform module. None of
my production instances can be logged onto.

~~~
haydn3
Are you sure about that?

~~~
scarejunba
Only time will tell if I _am_ in fact right. I'm counting on being more right
than the guys who have dedicated staff who routinely shell into their servers.

I suppose we'll see if companies with sysadmins have more breaches than the
guys who run their own ops using container orchestration etc. I think I'd go
even odds $1k that over the next five years, most large scale data breaches
will be at organizations where sys admins run the majority of ops.

There's a whole new category of errors you can make (making your bucket open,
etc.) with cloud providers but the tooling has better defaults.

~~~
bfgpereira
> Only time will tell if I am in fact right.

I guess you prove a point here: you trust that the deployment of your GKE
module allows you to be safe, so your investment vs risk trade seems to
satisfy you. But you, yourself, cannot even predict how insecure you are at
the moment due to the complexity of the software solutions you are using.

> I suppose we'll see if companies with sysadmins have more breaches than the
> guys who run their own ops using container orchestration etc.

Oh, I do agree, at least with the current state of sysadmins out there.

But the problem is that you loose control of the integrity of your system once
you reach a point where software complexity becomes your security entry point.

If you are sure the containers you will be using are secure, have sane
defaults, are up to date, etc, then fine, good job! I just don't trust that
most people will be able to reassure me that. And please keep in mind that in
your case, the target is not your container platform, the target would be the
containers in that platform, and the services they run.

~~~
wwright
No one can really predict their security accurately.

Say you maintain a bare-metal server in a data center that your company
controls.

How much do you know about its physical security? The protocols for admitting
new staff? Do you rely on your company’s physical security team and HR? Are
any of those functions contracted externally, even partially?

How much do you know about the network security? Do you rely on a networking
team? Is any of their work contracted externally? What about the link to the
outside world?

How much do you know about the sourcing of the physical hardware?

How much of the source have you audited? How about firmware source?

GKE obviously introduces new factors and vectors, but it also simplifies many
of these and adds elements of herd immunity. And it’s also the same as the
rest: your system was built by many people, it will be used by many people,
and it will be maintained by many people. You can spend all of your time
verifying every link, or you can help them do something in the world.

~~~
spc476
How well do you vet your IT staff? I was once the recipient of an inside job:
[http://boston.conman.org/2004/09/19.1](http://boston.conman.org/2004/09/19.1)

