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

ghe.md

Affected Target

Per github/github/README.md:

This is GitHub.com 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,
  • these links are only found after one registers at enterprise.github.com, 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. 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 admin@ec2-blah-blah.blah.compute.amazonaws.com ...

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 ruby_concealer.so`:
   #
   ## > 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/`!
   
   ruby_concealer_patch='
   diff --git a//usr/share/rbenv/versions/2.1.2-github/lib/ruby/vendor_ruby/2.1.0/x86_64-linux/ruby_concealer.so b//usr/share/rbenv/versions/2.1.2-github/lib/ruby/vendor_ruby/2.1.0/x86_64-linux/ruby_concealer.so
   index 6b22d81babada50cacf34a5e47baad900dd94b85..328cd4e18c144b6d1d7637d67f5dc330a7a50547 100755
   GIT binary patch
   delta 17
   YcmX?Qead=601rz+X-V<s5S}tY06_f)fdBvi
   
   delta 17
   YcmX?Qead=601r!QSz^xS5S}tY06+5vT>t<8
   '
   
   echo "$ruby_concealer_patch" | git apply
   
   echo '2.1.2-github' > /usr/share/rbenv/version; eval "$(rbenv init -)"
   
   ruby_revealer(){
     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
   done
   
   # 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? 😉
• IP theft and industrial espionage.

Vulnerability Urgency

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

Mitigation

I have some other ideas as well, but perhaps you could start by requiring registration to access the AMIs and authentication to download .ovas.