The types of issues you see when managing a bug bounty program vary widely, but every now and then a trend appears where multiple researchers submit the same issue. One day I received several reports regarding "World-editable GitHub Repository Wiki Pages" and it made me scratch my head at first. GitHub repos have wiki pages? Aren't wiki pages supposed to be collaborative and editable by nature? So I decided to look into it.
The Problem
All GitHub repositories have the ability to have associated wiki pages, which could potentially be world-editable (anyone with a GitHub account):
The issue here is that most developers and engineers at large companies don't know a setting to control this exists. This results in wiki pages which anyone with a GitHub account can modify. So is this really a security issue? Yes...if allowing anyone to edit the wiki pages was unintentional. So why does this occur? I've typically found one of the main causes is engineers open sourcing a project, changing the repository from private to public. The enabled wiki setting stays the same, allowing anyone, not just collaborators or internal employees, to edit the wiki page. It's also worth noting it's hard for repo owners to know when changes are made to their wiki pages because they don't get notified when it occurs and notifications can't be inherently configured.
The Impact
The impact of this is pretty straightforward. Any GitHub user, even without being a collaborator or having any association with the account, can create or edit wiki pages. On these pages they could include hyperlinks, images, and more using markdown. It would be fairly easy to create a simple wiki page to social engineer people to install malicious libraries or navigate them to a malicious page owned by the attacker.
Another aspect to the impact of this issue is reputational damage. It's very easy to automate the editing of these wiki pages and would allow a nefarious actor to quickly add text and imagery which does not conform to the companies' principles.
The Fix
Unfortunately for large companies with a lot of public repos, there doesn't appear to be an account-level setting which can manage all repository wiki settings. This means they have to control this on a per-repo basis with the "Restrict editing to collaborators only" setting (see, Changing access permissions for wikis).
Other solutions could include:
- Disable the wiki altogether, if you don't need it.
- Engineer education about this issue and the related wiki settings.
- Periodically auditing your account's repositories with my script
github-wiki-auditor.py. - Create a plugin or service which notifies you have changes to your wiki pages.
The Script
I wrote github-wiki-auditor.py which iterates over a list of GitHub accounts, and for each account, iterates through each repository. For each repository it checks if the wiki page is enabled, and if so, will send a request to create a new page. If the request is successful the user is notified and the next repository is checked. This script never actually modifies the wiki pages because the ability to edit can be confirmed without doing so.
Usage:
github-wiki-auditor.py [-h] --accounts_file ACCOUNTS_FILE [--username USERNAME] [--password PASSWORD] [--output_file OUTPUT_FILE]
Sample output:
The Bounty
As this is an issue I thought a lot of companies might have, I created a modified version of my script which creates a bounty report submission based on the found editable wikis. I then collected a list of about 100 unique companies from HackerOne and BugCrowd and found their GitHub accounts. This allowed me to quickly scan multiple accounts and submit bounty reports for each.
I started off by submitting about 10 separate reports. The feedback I received at first wasn't great. Most bug bounty program managers responded with either annoyance, as I wasn't the first person to submit this issue, or they responded by stating it wasn't an actual risk. I did receive a positive response from 2 companies and they had something in common: they ran their own program and weren't on a bounty platform. I believe the companies who run their own programs don't get targeted as much with common or low severity issues. So...Success!? I received my first bounty of $500 and a certificate from the other company. At this point I had proven the capabilities of the script, received my first bounty, and called it a day.
