Traitor: Linux privilege escalation made easy(github.com)
github.com
Traitor: Linux privilege escalation made easy
https://github.com/liamg/traitor
39 comments
Well that failed rather misterably
package github.com/liamg/traitor/cmd/traitor: mkdir /home/test/go: not a directory
He obviously wasn't clear enough about this, but if you're just trying to use the tool, download the binary release. Don't use go get as an installer. They're trying to be multi-OS compatible, an autotools that doesn't assume every system has a /usr/local or whatever the Windows equivalent but not assuming everyone has a %USERPROFILE%\AppData\Local\Low\Roaming or whatever. It does assume everyone has a home directory and an environment variable indicating where that is.
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?
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?
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.
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.
2. If you don't use modules, $GOPATH is used.
3. If $GOPATH isn't set, it defaults to ~/go.
Actually, modules are still downloaded to a global location, they are not copied locally to your project by default.
Well yes, but most languages have some kind of cache in the home folder.
So yes, go does "assume that you have a directory in $HOME that is for it's own personal use?"
Yes, that's precisely what it does.
And good luck making it fit in a multi-language project of any kind.
well, no. that's just default behavior.
and it's also just for depedencies it downloads.
_your_ code lives where you put it
and it's also just for depedencies it downloads.
_your_ code lives where you put it
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.
Perhaps that's changed, but it put me off the language entirely.
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?
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?
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.
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.
Everyone had this experience, that's why after years and years they finally changed that behaviour.
Go projects using modules are permissive about where you put them (e.g. they don't have to be inside a GOPATH at the right location). It does still use a GOPATH for caching directories though, which seems normal enough. They have to go somewhere, usually declared in some env variable, or they have to have a default location and silently spread files all over. `go get` is not a binary installer, it's a go-project-downloader that happens to also be able to install binaries, so this is IMO expected as it doesn't toss the intermediate products (i.e. a temp folder is not a reasonable choice).
As for multi-language projects and conflicting layout needs: oh yeah, that's still terrible. Maybe try Bazel? It can break `go`(the CLI binary)'s rules and build any package from any source files, regardless of their locations. None of that is part of the language spec, `go` is just opinionated and inflexible (probably for simplicity).
As for multi-language projects and conflicting layout needs: oh yeah, that's still terrible. Maybe try Bazel? It can break `go`(the CLI binary)'s rules and build any package from any source files, regardless of their locations. None of that is part of the language spec, `go` is just opinionated and inflexible (probably for simplicity).
[deleted]
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
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.
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/
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/
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."
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.
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.
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.
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.
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.
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.
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.
Unlike most of compiled languages Go have no-effort cross-compile for different architecture. All you need is to specify GOARCH. So what's problem with compiling different binaries?
There's no way to achieve this...even writing things in POSIX is going to be incompatible on some systems. Having a different binary for different systems is necessary. Even writing things in an interpreted language e.g. Python still requires at least Python binaries on all your systems, and that's ignoring dependencies. It doesn't get much more convenient than Golang's cross compilation.
>That’s why tools like linenum.sh and linpeas.sh are written in bash.
I've encountered many systems without bash.
I've encountered many systems without bash.
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/#