Free Privileged Account Discovery Tool: Identify & secure credentials to stop lateral movement. Download Free

BeyondTrust
  • Products
    Privileged Password Management
    Discover, manage, audit, and monitor privileged accounts
    Password Safe DevOps Secrets Safe
    Endpoint Privilege Management
    Manage privileges on Windows, Mac, Linux, and Unix endpoints
    Windows and Mac Unix and Linux Active Directory Bridge
    Secure Remote Access
    Centrally manage and secure remote access for service desks and vendors
    Remote Support Privileged Remote Access
    BeyondInsight Analytics
    See All Solutions
  • Resources

    Universal Privilege Management

    Our innovative Universal Privilege Management approach secures every user, asset, and session across your entire enterprise.

    Watch Video

    Learn

    Case Studies
    Competitor Comparisons
    Datasheets
    Glossary
    Product Demos
    Whitepapers

    Attend

    Events
    Go Beyond
    Training
    Webinars

    Support

    Changelog
    Professional Services
    Technical Documentation
  • Blog
  • Partners
  • Contact
  • Support
  • Services
  • Training
  • Events
  • Company

Git’s Case-Insensitive Discrepancies: Exploiting GitHub For Windows And Microsoft Visual Studio (still affected)

December 23, 2014

  • Blog
  • Archive
A vulnerability within Git has been recently announced concerning the case-insensitive nature of the Windows file system. This vulnerability is unique in that fact that an attacker does have the ability to execute arbitrary code, however conventional exploitation methods, such as memory corruption, is not required. This article explores two ways to execute arbitrary, attacker controlled code on a remote system. First, we take a look at GitHub For Windows and how hook scripts can be executed. Then, we dive into Visual Studio 2013, which as of this writing is still unpatched. GitHub For Windows Vulnerability According to the GitHub advisory, an attacker “can craft a malicious Git tree that will cause Git to overwrite its own .git/config file when cloning or checking out a repository, leading to arbitrary command execution in the client machine.” So how does an attacker go from simply overwriting a directory to executing arbitrary code…remotely? A typical .git directory contains a very interesting sub-directory named hooks: github1 This hooks sub-directory stores scripts which are automatically executed whenever a particular git command is issued. For example, the file named pre-commit will execute prior to issuing a git commit command. What’s even more interesting is that these scripts can be written in any scriptable language, such as perl which is bundled with GitHub For Window’s console application. This allows for extremely complex and dangerous payloads to be executed. Note: for an entire listing of which hook scripts are available, the githooks man page provides detailed information. Taking a look at the patch diff: github2-1github2-2 We see that the return values for a couple new functions are assigned to the has_dotgit variable. Digging into the is_ntfs_dotgit() function, we see that a case comparison is done against the .git and git~1 strings. github3 So it appears that there are two attack vectors that can be taken in order to exploit this vulnerability. One, taking advantage of the case insensitive nature of the windows and MAC OS X operating systems, and two, taking advantage of Window’s 8.3 file naming convention. Before exploiting this vulnerability, it’s important to note that a client and server each have their own .git directory. So when the client victim clones the malicious repository, their .git directory is overwritten with the malicious .git directory structure, containing the attack payload. In this example, the malicious attack server will be hosted on a case-sensitive operating system – Kali Linux. Because of this case-sensitive nature, we are able to create two separate directories, .git and .Git: github4 And hidden within the .Git/hooks directory, lies the malicious perl script (which, in this case, launches Windows calculator): github5 Next, the changes are committed and the server daemon is launched: github6 The victim, running a vulnerable version of GitHub For Windows, then clones the repo: github7 And commits any changes they’ve made, executing the malicious payload: github8 Microsoft Visual Studio 2013 Vulnerability – A Slightly Different Approach While the official GitHub clients have been patched to resolve the issue, other implementations of git over Windows (or Mac) may still be affected - one such implementation is Microsoft Visual Studio 2013. Visual Studio 2013 suffers from essentially the same case-insensitive vulnerability, however, one caveat is that client side hooks are disabled. As such, this will not allow us to execute scripts in the same manner. However, as with most other things, when there is a will there is a way - and it this case, there is definitely a way. Another very interesting file within the .git directory is the config file. This file specifies different options for various git functionality. For instance, we can specify which diff tool Visual Studio will use to display any file differences between the local and remote repository: github9 In this config file, we are defining the diff tool to be “sometool” and specifying the path to the tool’s location on the local (victim) file system. An attacker can leverage the case-insensitive vulnerability by placing a malicious executable inside the .Git directory which will be ran whenever a diff is performed within Visual Studio 2013, which we’ll now show in greater detail. First we upload a malicious executable to the .Git directory: github10 Then we modify the config file to point to this location on disk: github11 Note: here we can provide a relative file path. In this case, .git is implicitly specified. And finally, these changes are committed and the malicious daemon is hosted. On the client side of things, we fire up Visual Studio 2013 and clone the malicious repo: github12 We then modify a file and do a comparison: github13 Which finally executes our payload within the .git directory: github14 In conclusion, it is important not to limit our outlook based on an advisory. It was stated that “…libgit2 (and Visual Studio which uses it) have been updated at the same time.” Yet, this is not the case. We can see that when developers introduce vulnerable code into their own software, multiple applications can be affected while flying under the radar. Although this vulnerability does require an attacker-controlled repository, limiting the chance of exploitation, we still hope to see this vulnerability within Visual Studio fixed in the near future.

Scott Lang

Sr. Director, Product Marketing at BeyondTrust

Scott Lang has nearly 20 years of experience in technology product marketing, currently guiding the product marketing strategy for BeyondTrust’s privileged account management solutions and vulnerability management solutions. Prior to joining BeyondTrust, Scott was director of security solution marketing at Dell, formerly Quest Software, where he was responsible for global security campaigns, product marketing for identity and access management and Windows server management.

Stay Up To Date

Get the latest news, ideas, and tactics from BeyondTrust. You may unsubscribe at any time.

I agree to receive product related communications from BeyondTrust as detailed in the Privacy Policy, and I may manage my preferences or withdraw my consent at any time.

You May Also Be Interested In:

Webcasts | February 09, 2021

Customer Webinar: Remote Support 21.1 Released!

Webcasts | February 24, 2021

Your PAM 2021 Blueprint: Securing Privileged Accounts for On-Premises and Cloud Assets

Whitepapers

Evolving Privileged Identity Management (PIM) In The 'Next Normal'

BeyondTrust Logo
  • Facebook
  • Twitter
  • LinkedIn

Keep up with BeyondTrust

I agree to receive product related communications from BeyondTrust as detailed in the Privacy Policy, and I may manage my preferences or withdraw my consent at any time.

Customer Support
Contact Sales

Products

  • Endpoint Privilege Management
  • Password Management
  • Privileged Remote Access
  • DevOps Secrets Safe
  • Remote Support

Resources

  • Blog
  • Case Studies
  • Competitor Comparisons
  • Datasheets
  • Glossary
  • Videos
  • Webcasts
  • Whitepapers

About

  • Company
  • Careers
  • Contact
  • Events
  • Leadership Team
  • Partner Program
  • Press

Languages

  • English
  • German
  • French
  • Spanish
  • Korean
  • Portuguese
  • Japanese
  • Privacy
  • Security
  • Manage Cookies
  • WEEE Compliance

Copyright © 1999 — 2020 BeyondTrust Corporation. All rights reserved. Other trademarks identified on this page are owned by their respective owners. BeyondTrust Corporation is not a chartered bank or trust company, or depository institution. It is not authorized to accept deposits or trust accounts and is not licensed or regulated by any state or federal banking authority.