Introduction

In addition to hosting millions of lines of code, Github contains a ton of secrets hidden in the depths of various repositories. These secrets are the product of developers unknowingly pushing their credentials, server secrets, passwords, etc. to the repository in addition to their code.

These secrets can be found with special Github search queries also called Github Dorks. A good collection of Github dorks is available here: https://github.com/techgaun/github-dorks

Let’s go through a couple examples of these to find secrets.

Dork 1 – filename:sftp-config.json

The file sftp-config.json is created by sublime text editor. Many developers prefer sublime text for remote development. For this purpose, sftp package in sublime comes handy. Sftp can be used with both password and/or key based authentication.

Once you setup the SFTP in sublime, sftp-config.json file is created as following:

This file contains sensitive information such as username, password, and IP address to connect.

So, if we search in github for sftp-config.json, we get several results, one of which is a web-programming project that contains credentials in plain text.

Dork 2 – filename:config.php dbpasswd

It is very common for php applications to hardcode database credentials. Usually the config.php file is used to provide configuration details for a php application which will be used to establish a database connection. So when we use this github dork, we get many results with php projects containing hardcoded credentials.

One example is valueclickbrands project.

Attackers can take advantage of this information disclosure bug to hijack the database completely and deal more damage.

Key Takeaway

Before making any project public, make sure the Github repository as well as previous commit branches does not contain hardcoded credentials and config files.

#github #dorks

For whipping up a quick web app or even creating a production level web API, Flask is arguably one of the top web frameworks according to Python developer survey 2022. Developers love it because it’s lightweight, easy to use, and does not require particular tools or libraries.

One of the many cool Flask features is the interactive debug console in the browser. The interactive debug console can be very useful to quickly test what part of your code is causing issues. But in many cases, developers explicitly enable the debug console and disable the pin protection on those debug consoles.

Thus, one of the consequences is remote command execution on these applications.

For this demonstration, we will be examining two projects that disable the pin protection: (1) Umber, a course management web application and (2) Shrunk, a URL shortener for Rutgers University.

Exploiting Umber

If we look under the environment file of the application, we can see that the application explicitly declares “export WERKZEUG_DEBUG_PIN=off”.

This command disables the pin protection on the debug console

Figure 1: Disabling the pin protection on the debug console

So, when we start the server, the debugger gets activated too.

Figure 2: Debugger is activated with PIN disabled

Now we can access the console web page at http://127.0.0.1:5000/console and execute our code.

Figure 3: Executing code remotely in Umber

Exploiting Shrunk

Another project that explicitly disables the pin protection is Shrunk, an internal project developed at Rutgers University to shorten the URL.

The shrunk server is started with a shell script called start.sh

The shell script explicitly disables the pin and runs the application in the debug mode.

Figure 4: Activating debugger mode disables the pin

So, same as the first example, when we start the server, we get the prompt that the Debugger is active and the Debugger PIN is disabled. These warnings are usually disabled and if deployed in production directly, then it can compromise the application.

Figure 5: Warning that the Debugger PIN is disabled

Figure 6: Executing code remotely in Shrunk

Key Takeaways

• Always check if your application has debugger enabled before deployment.
• Limit the console access to only specific internal IP ranges.
• Make sure that if you need the debugger active, it also has debugger pin enabled.

#NCSAM #exploit #research #vicarius_blog