Just a dash o pepper with my repo, thanks

Full article

I was doing some React training early this week, following the author's lead and writing a tiny app to load GitHub users' profiles. Truly awesome shtuff. I tested it out with a few real names, a random key mashing, and finally a single hyphen. I don't know why, it's unlikely to be a username. Or is it? dun dun DUNNN

A single hyphen for a username? πŸ€”

Well, for someone stuck inside with nowhere to go, that just begs to be looked into further. Is this an early user? A hidden test account of some sort? I immediately went to view their profile, but.. um... it can't be found. Oddness.

Yet I could find other people who had followed this slickest of peppers, and I was able to follow it too. But hovering over the profile name shows nothing, and in fact throws a 404 error in the console. More oddness.

At this point, I decided to leave the finicky front-end to its own devices, and see what I could see with the GitHub API. First stop, a simple request to grab user info. There's quite a few other endpoints in the response that may shed more light on just who this mystery pepper is.

curl GET 'https://api.github.com/users/-'

{
    "login": "-",
    "id": 75544,
    "node_id": "MDQ6VXNlcjc1NTQ0",
    "avatar_url": "https://avatars2.githubusercontent.com/u/75544?v=4",
    "gravatar_id": "",
    "url": "https://api.github.com/users/-",
    "html_url": "https://github.com/-",
    "followers_url": "https://api.github.com/users/-/followers",
    "following_url": "https://api.github.com/users/-/following{/other_user}",
    "gists_url": "https://api.github.com/users/-/gists{/gist_id}",
    "starred_url": "https://api.github.com/users/-/starred{/owner}{/repo}",
    "subscriptions_url": "https://api.github.com/users/-/subscriptions",
    "organizations_url": "https://api.github.com/users/-/orgs",
    "repos_url": "https://api.github.com/users/-/repos",
    "events_url": "https://api.github.com/users/-/events{/privacy}",
    "received_events_url": "https://api.github.com/users/-/received_events",
    "type": "User",
    "site_admin": false,
    "name": "Dash O'Pepper",
    "company": null,
    "blog": "",
    "location": null,
    "email": null,
    "hireable": null,
    "bio": null,
    "public_repos": 1,
    "public_gists": 0,
    "followers": 123,
    "following": 0,
    "created_at": "2009-04-19T23:52:47Z",
    "updated_at": "2014-04-11T21:48:45Z"
}

It might be interesting to see who the account was following (pinch o salt? side o garnish?), but unfortunately a call to the /following endpoint returns an empty result set. Likewise, there are no gists or starred repos, organizations or events.

There is a single repo though, named "test". πŸ™‚

curl GET 'https://api.github.com/users/-/repos'

[
    {
        "id": 45484796,
        "node_id": "MDEwOlJlcG9zaXRvcnk0NTQ4NDc5Ng==",
        "name": "test",
        "full_name": "-/test",
        "private": false,
        "owner": {
            "login": "-",
            "id": 75544,
            ...,
            ...
        },
        ...
        "forks_url": "https://api.github.com/repos/-/test/forks",
        ...,
        ...
    }
]

Which I couldn't clone. πŸ˜”

$ git clone git@github.com:-/test.git
Cloning into 'test'...
fatal: strange pathname '-/test.git' blocked

But there were a couple forks of it! πŸ˜ƒ

curl GET 'https://api.github.com/repos/-/test/forks'

Which I couldn't open in the UI. 😒

But I could clone the fork! πŸ˜…

$ git clone git@github.com:brunoduran/test.git
Cloning into 'test'...
remote: Enumerating objects: 3, done.
remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 3
Receiving objects: 100% (3/3), done.

Nothing left but a git log to check the commit history, and hope it doesn't cause a cascade of system failures that takes all of github.com down.

$ git log
commit f031d18ae6b9074d1449099ddc4f5d547d15ee2e (HEAD -> master, origin/master, origin/HEAD)
Author: Rogelio J. Samour <rogelio@therubymug.com>
Date:   Tue Nov 3 09:49:29 2015 -0800

    Create README.md

    Yeehaw

Ah. Could Mr Samour be the infamous Dash O Pepper? His account existed a year before it, so it was probably just a test account he made. But I take pride in my investigative work, so let's confirm it. You know, without actually just reaching out and asking him. That'd be too easy.

Dash O Pepper didn't have much, but it was watching some repos (aka subscriptions), 5 of which belonged to Acumen Brands Inc, WHICH! just happens to be... um, well.. a place Rogelio Samour worked aaand that's enough yikes I'm stopping right now before I creep myself out anymore. Suffice to say, I feel confident that it was him. Is him. Whatever.

therubymug - Overview
Human. Programmer. Director of Engineering at @goldstar in Portland, Oregon. Formerly: @hashrocket. - therubymug

What a roller coaster of emotions, huh? No? Anyway, I mirrored the repo, with its one file and one commit, and I'll try not to convey any disappointment that it held no answers to the mysteries of our universe. Here it is. πŸ₯±


There is one thing I was left wondering though. How was a username like this possible in the first place? And if it was before, why not now? Why is GitHub's front-end sploding every which way when trying to access it?

After a little google-fu I found a high-security bug, found by employees of GitLab and GitHub, and patched a few years back (details here and here). Seems there were really bad potential side effects for host names starting with a hyphen. To play it safe, they disabled using a hyphen elsewhere too.

A malicious third-party can give a crafted "ssh://..." URL to an
unsuspecting victim, and an attempt to visit the URL can result in
any program that exists on the victim's machine being executed.
Such a URL could be placed in the .gitmodules file of a malicious
project, and an unsuspecting victim could be tricked into running
"git clone --recurse-submodules" to trigger the vulnerability.

Credits to find and fix the issue go to Brian Neel at GitLab, Joern
Schneeweisz of Recurity Labs and Jeff King at GitHub.

 * A "ssh://..." URL can result in a "ssh" command line with a
   hostname that begins with a dash "-", which would cause the "ssh"
   command to instead (mis)treat it as an option.  This is now
   prevented by forbidding such a hostname (which should not impact
   any real-world usage).

 * Similarly, when GIT_PROXY_COMMAND is configured, the command is
   run with host and port that are parsed out from "ssh://..." URL;
   a poorly written GIT_PROXY_COMMAND could be tricked into treating
   a string that begins with a dash "-" as an option.  This is now
   prevented by forbidding such a hostname and port number (again,
   which should not impact any real-world usage).

 * In the same spirit, a repository name that begins with a dash "-"
   is also forbidden now.

Not in the naming of a repo apparently, unless internally a repo includes your username. And if you take another look at what the API returns, the "full_name" of a repo does include your username, which they no longer allow to begin with a hyphen. So... there you have it, another mystery solved. You're welcome. πŸ™„

[
    {
        "id": 45484796,
        "name": "test",
        "full_name": "-/test",
        "private": false,
        "owner": {
            "login": "-",
            "id": 75544,

As for the whole weird system behavior, it's probably just the code running into various checks and balances and whatever else, when what should've happened was that user was renamed to something that's considered valid in the system.

Wonder what other user names starting with a hyphen are still hanging out there?

Author

Grant Winney

I write when I've got something to share - a personal project, a solution to a difficult problem, or just an idea. We learn by doing and sharing. We've all got something to contribute.


Comments / Reactions