Re: [dev] Privilege escalation on remote hosts. MANY remote hosts.

From: Antenore Gatta <>
Date: Fri, 22 Sep 2017 22:18:41 +0200

Back to real life with a real keyboard and a real system!!!
I keep the previous answer to have a context.

On Fri, 22 Sep 2017 16:21:08 +0000
Antenore <> wrote:

> >Now back to PrivEsc, I actually found Antenore's suggestion
> >inspiring. It would work if we could force only part of the command
> >to remain constant, and use the constant part to perform
> >non-interactive authentication (e.g. by verifying a provided
> >secret). Essentially delegate authentication to a sub-command in a
> >Bernstein-style exec chain, like this:
> >
> >$ sudo -n -- verifyme -- ./my-amazing-script
> > ^ substitute doas, sup, etc
> > ^ authn helper, no suid
> > ^ arbitrary; exec only if authn successful
> >
> >Pros:
> >
> >- Can perform non-interactive verification
> >- No new suid cruft on your system; can be written in plain sh
> >- No black magic, keep existing setup almost untouched
> >- Just one extra rule in sudoers / doas.conf / config.h
> >- Reuses and plays nice with existing PrivEsc methods
> >
> >Cons:
> >
> >- ?
> Thank you for clarifying. Later (well I hope) I'll show exactly what
> we do. As we use also the var SSH_ORIGNAL_COMMAND in the remote
> script.
> SSH keys management itself is the cons.
> We've some hundreds of keys, therefore you must keep a good Inventory
> of the keys.

The mechanism I use it's quite simple, but I cannot say if it sucks, in
general, or not ;-)

1. SSH public keys

I forge a special SSH public key like this way:

ssh-rsa AAAAB3NzA..


Connecting to myremotehost, will be executed instead of the
login shell. whatever I put after the ssh command, will be, almost,
ignored, like

    ssh -i ~/.ssh/zus_key myremotehost what is zus

On myremotehost "what is zus" will be not executed, but will be in the
"SSH_ORIGINAL_COMMAND environment variable, that I use in my

   # just a fake example
       what *)
           sudo echo "$SSH_ORIGINAL_COMMAND"
           # or directly (no sudo) a setuid commad
           echo "Permission denied."
           exit 1

You can add whatever layer of security you want, you can even write
your suckless unrestricted magical shell... Up to you.

We have some complex "", also some that are not shell scripts,
but we usually prefer to keep everything simple ( almost simple ) to
avoid security holes.

We have also some desperate case where we build almost a key per
command for our offshore team (they are incompetent and they don't give
a shit if they break anything, this sucks!)

Sometime we build a trow-away key just to give limited unrestricted
access to some consultant.

Well, I hope it's what you are looking for.
Received on Fri Sep 22 2017 - 22:18:41 CEST

This archive was generated by hypermail 2.3.0 : Fri Sep 22 2017 - 22:24:23 CEST