Since this example of exploiting a Flask/Werkzeug application with Debugging enabled is from an active Hack The Box machine I won’t mention the name here so as not to spoil it, but all of the principles outlined are the same when attempting to reverse engineer the console PIN.
When testing a Flask app, there are a few key things to check for. First, look for SSTI (server-side template injection) since Flask uses the Jinja2 templating engine. Second, check if the secret key used to sign session cookies is visible anywhere in the source code. Finally, check whether debugging has been enabled in Werkzeug when the application was started. If debugging is enabled, attempt to crack the PIN to access the debugging console and execute code, which is what I will cover here.
Werkzeug is a set of Python libraries that allows a Flask application to communicate with a web server such as Apache,Nginx or Gunicorn using WSGI (web server gateway interface). In addition to being a middleware between the application and a proper server, Werkzeug itself can act as a bare bones web server for testing purposes. This is not to be used in Production environments and you’ll get a message **WARNING: This is a development server. Do not use it in a production deployment. Use a production WSGI server instead.** telling you so when you enable this feature after starting your Flask app in the terminal.