EXE Hijacking in Git Bash for Windows
TLDR; Git Bash for Windows 1.x will execute any file named “git.exe” in the current directory when accessing the Windows context menu
I was researching some old DLL hijacking vectors recently. Specifically, I was looking at the Metasploit module exploit/windows/browser/webdav_dll_hijacker. I wanted to see if this old 2010 exploit would work with Windows 8 (it doesn’t). This exploit sets up a Windows share and shows you the files requested by the victim. The idea is if the victim machine requests a DLL, then it will serve a DLL with a reverse-shell embedded.
While testing I noticed a request for “git.exe”. This is unusual, because I was on a Windows share created by the exploit. Why would my machine be searching there for “git.exe”?
I realized, it is likely because right-clicked a file in the folder and I have Git-Bash installed on my Windows machine. This got me thinking,
“What would my machine have done if it had found an arbitrary file named ‘git.exe’ in that folder?”
Exploitation is simple. Take an arbitrary EXE file and place in an arbitrary folder. Rename the EXE to “git.exe”. Now, right clicking any file in the folder and running Git-Bash from the context menu executes that file. Here is an example video using calc.exe as a payload:
This was tested with a 1.x version of Git-Bash for Windows.
Impact for this is about as severe as a DLL Hijacking exploit. In this case, an EXE is hijacking normal application operation instead of a DLL but the concept is the same. This exploit may give attackers opportunities for persistence or privilege escalation. Since it is Git-specific, I can imagine ways attackers could sneak a malicious “git.exe” file into repositories in the hopes of being executed on the machines of developers.
The latest version (2.x) is not affected. Anyone using a vulnerable version of Git-Bash for Windows (1.x) should uninstall the old version and upgrade immediately. Git-Bash for windows 1.x is no longer supported and should not be used.
This vulnerability was disclosed and assigned CVE # 2016-9274.