Hacking Flask Applications

Executing arbitrary commands using the Werkzeug Debugger

Vickie Li
The Startup
4 min readFeb 18, 2020

--

One of the very first web applications I made was developed using Flask. It was the best choice since it has a lot of documentation online for a beginner like me, and has tons of extensions to support the implementation of additional features.

I wasn’t aware, however, of the security risks that come with using Flask. Today, let’s discuss one of them, a vulnerability found in Flask applications that can lead to Remote Code Execution (RCE).

What is Flask?

Flask is a micro web framework written in Python. It has become one of the most popular Python web application frameworks.

Flask began as a wrapper around Jinja and Werkzeug. The vulnerability that we are going to discuss today is caused by Werkzeug. Jinja is a template engine for Python that has it’s own severe security issues, but that’s a topic or another day!

What is Werkzeug?

Werkzeug German noun: "tool". 
Etymology: werk ("work"), zeug ("stuff")

Werkzeug is a comprehensive WSGI web application library.

WSGI means “Web Server Gateway Interface”. It is a specification that describes how a web server communicates with web applications, and how web applications can be chained together to process one request.

Werkzeug began as a simple collection of various utilities for WSGI applications and has become one of the most advanced WSGI utility libraries.

In particular, Werkzeug includes an interactive debugger that allows inspecting stack traces and source code in the browser.

The Werkzeug Debugger

Werkzeug provides an interactive debugger renders tracebacks and allows for the execution of Python code on the local machine.

You can find the official documentation for the debugger here:

Once the debugger is enabled and an error happens during a request, you will see a detailed traceback instead of a generic “internal server error”.

The traceback page looks like this. (The example is taken from the Werkzeug Documentation at https://werkzeug.palletsprojects.com/en/1.0.x/debug/.)

Notice that there is an interactive Python console at the bottom of the traceback page. Inside the console, you can execute any kind of Python code on the local machine. This feature allows developers to quickly test assumptions and check what went wrong during the request.

Werkzeug Remote Code Execution Vulnerability

Upon entering the debugger documentation page you will see this warning:

The issue here is not the Werkzeug debugger itself, but an incorrect way of configuring a Werkzeug application: making the debugger available on a production machine.

A publicly exposed debugger will subject the machine to remote code execution. Once attackers can execute arbitrary Python code on the server, she can directly leak all the sensitive data stored on the server.

How To Exploit The Vulnerability

So how do you find out if an application is vulnerable to this issue? And once the vulnerability is confirmed, how do you exploit it?

The best way to discover this vulnerability is by doing thorough recon. Using Shodan or by carefully examining the server’s response headers, you can find out whether the application uses Werkzeug or not.

If the application uses Werkzeug, the next step is to induce an internal server error in the application. The debugger gets triggered when there is an internal server error. Sometimes, you can also access the debugger console by navigating to the path “/console”, if it is set as a general-purpose path for the debugger.

Starting with Werkzeug 0.11 the debug console is protected by a PIN by default. If an incorrect PIN is entered too many times the server needs to be restarted. However, it is possible that the PIN has been disabled in the application.

Once you’ve exposed the debugger console, standard RCE escalation techniques apply.

Thanks for reading. And remember: trying this on systems where you don’t have permission to test is illegal. If you’ve found a vulnerability, please disclose it responsibly to the vendor. Help make our Internet a safer place.

Is there anything I missed? Please send me a note on Twitter: https://twitter.com/vickieli7.

--

--

Vickie Li
The Startup

Professional investigator of nerdy stuff. Hacks and secures. Creates god awful infographics. https://twitter.com/vickieli7