[HN Gopher] Traitor: Linux privilege escalation made easy
       ___________________________________________________________________
        
       Traitor: Linux privilege escalation made easy
        
       Author : draugadrotten
       Score  : 193 points
       Date   : 2021-02-22 14:12 UTC (8 hours ago)
        
 (HTM) web link (github.com)
 (TXT) w3m dump (github.com)
        
       | easterncalculus wrote:
       | Seems interesting with the Docker exploit I guess. I would still
       | recommend linpeas: https://github.com/carlospolop/privilege-
       | escalation-awesome-...
       | 
       | Most of these tricks are listed here at GTFOBins:
       | https://gtfobins.github.io/ which is based on LOLBAS for Windows:
       | https://lolbas-project.github.io/#
        
       | iso1631 wrote:
       | Well that failed rather misterably                 package
       | github.com/liamg/traitor/cmd/traitor: mkdir /home/test/go: not a
       | directory
       | 
       | Does go assume that you have a directory in $HOME that is for
       | it's own personal use?
        
         | oauea wrote:
         | Not since 2019: https://blog.golang.org/using-go-modules
         | 
         | The project has to opt into it, which appears to be the case
         | here since there is a `go.mod` file. Are you using a modern
         | version of Go?
        
           | axaxs wrote:
           | If you opt into modules, modules get stored in GOPATH. If you
           | don't use modules...source gets downloaded into GOPATH. If
           | GOPATH is unset, it uses ~/go.
        
             | arghwhat wrote:
             | 1. If you opt into modules, $GOMODCACHE is used for go mod
             | downloads. It defaults to $GOPATH/pkg/mod.
             | 
             | 2. If you don't use modules, $GOPATH is used.
             | 
             | 3. If $GOPATH isn't set, it defaults to ~/go.
        
           | tsimionescu wrote:
           | Actually, modules are still downloaded to a global location,
           | they are not copied locally to your project by default.
        
         | axaxs wrote:
         | Yes, that's precisely what it does.
        
           | Filligree wrote:
           | And good luck making it fit in a multi-language project of
           | any kind.
        
             | smokey_circles wrote:
             | well, no. that's just default behavior.
             | 
             | and it's also just for depedencies it downloads.
             | 
             | _your_ code lives where you put it
        
               | Filligree wrote:
               | I spent days, a few years ago, trying to figure out how
               | to do that. When I asked on the IRC channel, they just
               | made fun of me.
               | 
               | Perhaps that's changed, but it put me off the language
               | entirely.
        
               | axaxs wrote:
               | Not just you. I've been using Go for many years, and
               | while I enjoy the language I always found the environment
               | of it awkward and unfriendly. Envvars on top of envvars.
               | Work only in GOPATH, no wait, stop working in GOPATH.
               | Vendor things...no wait don't do that either.
               | 
               | I think a lot of it is just growing pains, but it still
               | feels clunky. My system has a .cache folder that
               | everything already uses, why does Go need a special
               | cache?
        
               | tinco wrote:
               | They didn't consider it a cache, they consider your
               | gopath to be the place where you put all source code,
               | your own, and that of all your dependencies.
        
               | colejohnson66 wrote:
               | That seems... a bit much IMO. I personally prefer
               | containerizing things. Such as Node.js' way with
               | node_modules. Then I can put my project wherever I want.
               | Downloaded dependencies can also go in ~/.cache because I
               | don't plan on editing them.
        
               | tinco wrote:
               | Everyone had this experience, that's why after years and
               | years they finally changed that behaviour.
        
         | spinny wrote:
         | Go uses $GOPATH to save it's own packages/binaries but uses
         | $HOME/go if $GOPATH is not set. Originally needed $GOPATH to be
         | set, but that changed later
        
         | z3t4 wrote:
         | I guess if it can't write to /home/test your system is safe...
        
           | iso1631 wrote:
           | I have a file - /home/test/go, which consisted of some script
           | I'd knocked up a few months ago
        
       | larpnet wrote:
       | How do you plan to use this universally across compromised
       | systems, if they don't have Go to compile this?
       | 
       | A better solution might be https://github.com/Frissi0n/GTFONow
       | which is written in python without dependencies and supports
       | Py2/3. I would expect this to work on more hosts.
        
         | gpm wrote:
         | You ship binaries not source code.
        
           | seniorivn wrote:
           | you can always ship compiler with source code
        
             | dbrgn wrote:
             | That is... not wrong.
        
               | qubex wrote:
               | "Not wrong" is the best kind of correctness.
        
               | nayuki wrote:
               | "Not even wrong" is a great sort of wrongness
        
         | dbrgn wrote:
         | I'm confused. Why should you need Go on the target system? Go
         | generates a static binary, that runs anywhere as long as the
         | architecture matches.
        
           | sharpnet wrote:
           | Responding here under a new account since due to being banned
           | for all the downvotes.
           | 
           | People here are viewing this with their developer hat on,
           | download a static binary? Sure what's the issue?
           | 
           | For people who work in security will know that you encounter
           | systems with all sorts of architectures and operating
           | systems.
           | 
           | As a pentester do you want to keep 14 different binaries for
           | each security tool you have so that you are prepared for all
           | platforms and architectures?
           | 
           | As a CTF player do you want to afford the time to compile
           | this for whatever platform you encounter?
           | 
           | That's why tools like linenum.sh and linpeas.sh are written
           | in bash.
           | 
           | They run on anything.
        
             | 0x003 wrote:
             | I mean typically yes, I keep binaries around for whatever
             | system I'm targeting. 32+64bit binaries for linux and
             | windows (4 total) will cover about 99% of any machines
             | you're likely to come across. I think you've taken more of
             | an issue with this than is necessary, seeing as if I can
             | run linpeas or linenum I am probably not going to have an
             | issue running a static binary, and it's really a matter of
             | personal choice.
        
       | guenthert wrote:
       | From the readme (saves you the trip to github): "It'll exploit
       | most sudo privileges listed in GTFOBins to pop a root shell, as
       | well as exploiting issues like a writable docker.sock. More
       | routes to root will be added over time too."
        
         | 0x003 wrote:
         | It's a cool idea and I like the execution but if I'm at the
         | point where I've uploaded the binary over and executed it I've
         | already run `sudo -l` and checked my permissions (and I could
         | be wrong but from my brief scan of the source code I don't
         | think it attempts to exploit SUID but just sudo permissions).
         | Probably would save a little bit of time with docker escalation
         | but again pretty standard enumeration would've revealed that
         | vector by then.
        
       | Deukhoofd wrote:
       | Looks interesting for testing local server security. A useful
       | feature to add might be a link to an explanation of the exploited
       | vulnerability, and how to resolve it.
        
         | tyingq wrote:
         | Sounds like a good suggestion. In the meantime...
         | 
         | It looks like there's basically 2 types of local privilege
         | exploits used.
         | 
         | https://github.com/liamg/traitor/tree/main/pkg/exploits
         | 
         | 1) Writeable Docker Socket: https://www.exploit-
         | db.com/exploits/42356
         | 
         | 2) GTFObins: https://gtfobins.github.io/
        
       ___________________________________________________________________
       (page generated 2021-02-22 23:00 UTC)