A word of caution for Laravel developers

What’s going on with Laravel?

Laravel is a very popular PHP framework used by developers around the world. Laravel includes a debug mode that helps those developers find problems and identify errors in their code while developing a web application.

That, by itself, isn’t a problem because this is usually something only used during development. The problem arises when the web application goes live and debug mode is not turned off. When this happens, sensitive information like passwords, keys, and database information can be exposed when an exception occurs, like the screenshot below shows.

To be clear, this is not a bug or vulnerability with Laravel. This is simply a step that can be overlooked by the developers when taking a site live. It’s also not a new problem - we’ve found many discussions around this topic on forums and threads online. But it does seem that bad actors have caught wind of this and are now actively searching for these exposures.

While looking into the above issue, we also noticed something else happening with a smaller subset of Laravel applications. On a few occasions, the developer misplaced files in a way that allowed the entire Laravel application to be served out of the web directory, instead of just the "public" directory. When this happens, the .env file containing all of the same sensitive information is exposed, as shown in the previous screenshot. If this is done, you can simply use your web browser and visit the file directly, if you know the path. Check out the screenshot below to see how this looks.

Why does this matter for Mailgun?

Well, if this sensitive information is available and gets in the hands of the wrong person (i.e. spammers), then you can bet your bottom dollar that there will be unwanted messages soon flowing through the compromised mail server. But how do the spammers find this information?

Unfortunately, it’s kind of easy. If debug mode isn’t turned off when an application is in production mode, an attacker can trigger an exception by using a specially crafted payload in an HTTP request. Once that happens, they’re greeted with the debug page, and the sensitive information is then scraped and either used or sold. Granted, they don’t know all of the websites that are vulnerable to this attack, but that doesn’t stop them.

Hackers are relentless. They’ll iterate over lists of IPs, domains, and paths until they get lucky and find a website that either had the debug mode still enabled, or left the .env file in the open. To make matters worse, bad actors have simplified this process making it easier than ever to find these vulnerabilities with tools like the one shown below.

How can you stay protected?

First and foremost, turn debug mode off when you’re taking your site live. Debugging issues with code is extremely important and helpful for developers, but it is not intended to be used in a production environment.

Secondly, be careful when you’re moving files around. Never, ever put your .env file in the web directory. It may seem obvious to most, but the fact is, there are loads of examples showing that this sort of thing is happening far too frequently.

Why are we telling you this?

We want a healthy email ecosystem. We hate spam (really hate it) and we’ll do anything in our power to help the email community to fight it.

Not only that, but this is a bigger problem than just the malicious use of mail servers. The sensitive information being exposed in these attacks can be used by hackers to steal data or develop further attacks on systems. The last thing anyone wants to read about is another data breach.

 Good luck and stay safe!