GHE Decryption Vulnerability — **Note: this is old and out of date.**

Home   »   GHE Decryption Vulnerability — **Note: this is old and out of date.**

Affected Target
Per `github/github/`:

> This is and GitHub Enterprise.

But note I would have selected 'Enterprise' if it were an option.
It could also be said to be Gist, or API, etc.

Vulnerability Class
I think probably:

  - Other

But also might be considered any/all of:

  - Security Misconfiguration
  - Sensitive Data Exposure
  - Using Components with Known Vulnerabilities
  - Broken Authentication or Session Management
  - Missing Function Level Access Control
  - Insecure Direct Object Reference

And possibly/indirectly/recursively:

  - More.

Vulnerability Description
There are a couple of interlinked issues at play. Broken down:

1. The Github Enterprise images can be accessed and retrieved by anyone, without registration.
  - This is particularly egregious with the EC2 AMIs, as
    - the AMIs are public, and can be spun up quickly and anonymously, and
    - the ssh key for a passwordless `sudoer` is immediately usable, and
    - it is more or less trivial to retrieve the AMI for use outside AWS.
  - It is also possible with the `.ova` files, but its a slightly less appealing vector, as
    - although no authentication is required to [retrieve the files][1], 
    - these links are only found after one registers at ``, and
    - it is more work to obtain SSH access.

2. It is *extremely* trivial to "deobfuscate" the application code, and when "decrypted", the code is fully commented and is *not* obfuscated. While this appears to be acknowledged to **some** extent (see comments in script), the caveat explicitly mentions its intent is to "discourage _GitHub Enterprise customers_ ..." — that is, it does not account for the above issue. It is most definitely **not** limited to Enterprise customers.

3. There are also some copyright/legal issues that arise: virtually none of the (assumedly private, closed source) code mentions copyright or license, and when accessed via public AMI in the manner described above, there are no requisite terms of service.

To Reproduce / Proof of Concept

1. Spin up an instance of Github Enterprise in AWS. You have a very nice guide on how to do this [here, no registration necessary][2]. The AMI IDs also appear in the EC2 console with a simple search. (yes, this might cost a few cents due to requisite image size/instance type.)

2. `ssh -p122 -i key.pem [email protected]` ...

3. And,
    #!/usr/bin/sudo bash
    #-----> not sh (dash) because rbenv is *incredibly* bash-y.
    set -o pipefail # So if it fails on a file, don't overwrite.

    ### `strings`:
    ## > This obfuscation is intended to discourage GitHub Enterprise customers
    #    from making modifications to the VM.
    # You sure that's all its intended to do? Not, say, assert copyright for DMCA?
    ## > We know this 'encryption' is easily broken.
    # Yeah, what, its zlib, force-read as UTF-16, then escape? Or something to
    # that effect. But there's actually no need to reverse engineer at all:

    ## Just do a binary `s/eval/puts/`!

    diff --git a//usr/share/rbenv/versions/2.1.2-github/lib/ruby/vendor_ruby/2.1.0/x86_64-linux/ b//usr/share/rbenv/versions/2.1.2-github/lib/ruby/vendor_ruby/2.1.0/x86_64-linux/
    index 6b22d81babada50cacf34a5e47baad900dd94b85..328cd4e18c144b6d1d7637d67f5dc330a7a50547 100755
    GIT binary patch
    delta 17

    echo "$ruby_concealer_patch" | git apply

    echo '2.1.2-github' > /usr/share/rbenv/version; eval "$(rbenv init -)"

      f=$(cat); cd $(dirname $f)
      r=$(ruby $(basename $f) | head -n -2) && echo "$r" > $f

    # There's some weirdness with a couple (pre|post)-receive-hooks, which seem
    # to like it a little better if one `cd`s to the directory first. 
    # They still squawk a bit but seem to decrypt fine.

    echo "One moment..." >&2 # While we grep through a bunch of other files...
    for concealed in $(grep -rl __ruby_concealer__ /data 2>/dev/null); do
      echo Revealing $concealed ... >&2; echo $concealed | ruby_revealer

    # Put the module back how we found it.
    echo "$ruby_concealer_patch" | git apply -R

4. Uh, profit? (`sudo dd if=/xvda`, `sudo tar cvz /data`...)

Vulnerability Impact
Quite impactful?
A few things that occur to me (in order of least to greatest consequence, IMO):

  - "Piracy". Somewhat irrelevant; the value of the product is mostly in support.
  - Further vulnerabilities, exploited via weak points found in code.
      - On the upside, code quality would probably improve rapidly, no? :wink:
  - **IP theft and [industrial espionage][3]**. 

Vulnerability Urgency
I wouldn't say I'd wake someone up for it. But I think it could keep someone up at night.

I have some other ideas as well, but perhaps you could start by [requiring registration to access the AMIs][4] and authentication to [download `.ova`s][1].


Leave a Reply

Your email address will not be published. Required fields are marked *