The git-shell is a restricted shell maintained by the git developers and is meant to be used as the upstream peer in a git remote session over a ssh tunnel. The basic idea behind this shell is to restrict the allowed commands in a ssh session to the ones required by git which are as follows:
git-receive-pack
Receives repository updates from the client.
git-upload-pack
Pushes repository updates to the client.
git-upload-archive
Pushes a repository archive to the client.
Besides those built-in commands, an administrator can also provide it’s own commands via shell scripts or other executable files. As those are typically completely custom, this post will concentrate on the built-in ones.
Note: This has nothing to do with the also recently fixed vulnerabilities in gitlab [1] [2].
One interesting observation we make when testing complex environments is that at the bottom of huge technology stacks, there is usually a handful of shell scripts doing interesting stuff. More often than not these helper scripts are started as part of cron jobs running as root and perform basic administrative tasks like compressing and copying log files or deleting leftover files in temporary directories. Of course, these high privileges make them an interesting target for privilege escalation attacks and one class of vulnerability we reliably encounter in shell scripts is unsafe handling of globbing or filename expansions. Continue reading “Revisiting an Old Friend: Shell Globbing”
During one of our pentests in some corporate environment we were to analyze an application-server called Liferay. Liferay comes with a lot of functionalities, runs on top of Apache Tomcat and includes a nice API that makes it very easy to add components or further functionality that are not part of the core. These (potentially selfmade) “addons” are called “portlets” and they can be inserted in any place in the frontend.
We quickly found an active default-account (test@liferay.com : test) which immediately led to the question: how to get access on the system-layer through the account on the application. Because we were not aware of any portlet which provided the desired functionality, we decided to write it on our own and created a straight-forward portlet for system level command execution.
As mentioned above, Liferay offers an API for adding portlets to the core. This can be done by creating a standard war-file which contains java-classes, including the desired functionality and some – in this case – Liferay-specific xml-based configuration files. War files are often used to expand the functionality of java-servers (e.g. Tomcat can also be extended via war-files) – it just needs to contain the application-specific xml-files.
Our java-class includes a html-form consisting of an input-field and a button, which sends commands (via GET) to the server. On the server the input gets executed in a shell – a new java HTTP-Shell is born. After some adjustments regarding to the operating system and the java compiler (1) we had a GET-Parameter-based HTTP-Shell.
The following steps are necessary to deploy the shell portlet:
3.) Execute create.bat / create.sh [Note: javac and jar must be installed in the PATH.]
4.) Have fun with the ShellPortlet.war
How to deploy the war-file?
1.) Login to your Liferay-System with a privileged user-account and open http://yourdomain.com/group/control_panel/manage
2.) You should find a category called “Server” on the left side in the navigation. Click “Install Plugin” and on the next site click “Install more plugins” followed by “Fileupload”
3.) Upload the war-file and use “tail -f $CATALINA_HOME/logs/catalina.out” or (on Windows) the Tomcat-console to observe the logs for any error/exception. When everything worked you’ll find an entry like “1 Portlet for ShellPortlet is available for use”
4.) Now go back to your mainpage via the link in the upper area “Back to Liferay”. Then click “Add” -> “More” and you will see all categories in which the portlets are sorted.
5.) If everything went right you will find a category named “Ownage” in this list. Click on it and drag&drop the shellportlet anywhere on your website.
6.) Have fun playing! 🙂
This shows – once again – that it’s not that hard to gain system-access over a (web-) application. Everyone who uses web-applications should secure the higher-privileged accounts by strong passwords or better deactivate them in case they are not needed. It also shows that – once again – comprehensive and reasonable hardening would have prevented the compromise of yet another system.
(1): The java-class must be compiled by the same compiler-version which the tomcat-server is using. (E.g.: If the tomcat uses jre1.6, the java-class in the war-file must be compiled by a javac which is out of the jdk1.6)
