A step-by-step walk-through of an Invalid Endpoint

I’ve been meaning to write about this for a while. It all started back in Mar 2019 when a new, Private, Vulnerability Disclosure Program was launched on HackerOne. Later, I was invited on July 2nd, 2019 to be a part of the on-going program.

With the limited scope, I did a simple Google Image search using one of their sub-domains.

Found this interesting sub-domain (apisandbox.example.com), a simple status page showing a message as ‘ok’ when visited. Did a manual search about the technology stack on which they are depending on and using.

Django Framework, they’re using so, I went ahead and did a simple directory search using dirsearch with a curated custom wordlist. Exactly after 17 minutes, that process flags a HTTP 200 OK success status response for this directory NpcTrackFrame_UpdateTarget.php.

Got a Page not found (404) error when visited https://apisandbox.example.com/NpcTrackFrame_UpdateTarget.php.

As they’re using Django and not having a custom 404.html template in place, for this specific missing request_path, Django loads the default “Not Found” message fromdjango.views.defaults.page_not_found()tree. But along with the “Not Found” message, that request also reveals all the URLConf data.

All the paths within URLConf

What’s URLConf? It is a URL configuration for Django which contains all the paths of the project.

But even though that loads the default “Not Found” message the URLConf was being disclosed because the developers initially had forgotten to properly set DEBUG mode to False. And as the request_path was not found that results in an exception when DEBUG mode isTrue in the settings module, Django displayed all the paths within the URLConf.

Error example

In this case, exampleapi.urls the URL * declaration for the Django project; containing all the paths in the project. Going through all the paths, I stumbled upon ^dataportal/views/?$

And when visited https://apisandbox.example.com/dataportal/views, the system discloses the credentials of their Amazon S3 Bucket, Jira account, FTP account, and also the credentials of their Admin account.

Key Takeaways:

There are always going to be sections of your debug output that are inappropriate for public consumption. File paths, configuration options and the like all give attackers extra information about your server.

• It is also important to remember that when you’re not using the DEBUG mode you need to turn it off.
• Always do have a 404.html file in the templates folder under the root directory.
• Even, when DEBUG is False, you also need to properly set and take care of the ALLOWED_HOSTS setting.

Thanks for Reading!

Mohammed Israil 🇮🇳