Back to main menu

IT & Engineering

A word of caution for Laravel developers

Recently we've become aware of a trend where customers are inadvertently exposing sensitive information along with their Mailgun credentials to the public. This particular issue arises with websites using the popular PHP framework, Laravel. Read more...

PUBLISHED ON

PUBLISHED ON

"Is my application secure?" is one of the top questions developers ask themselves nowadays. And yet, security breaches and compromised accounts are becoming far too common, and compliance and security teams are constantly racking their brains to identify vulnerabilities and how to prevent them.

At Mailgun, we've recently noticed an increase in the number of customer accounts with unauthorized use on them. This isn’t anything new, but the current increase did give us pause, so we decided to investigate. Our investigation found the usual culprits like the accidental exposure of credentials on Github and credential stuffing attacks, but what we hadn’t seen before was something that affected our customers using Laravel.

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.

debug

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.

debug2

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.

debug3

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!

Related readings

Mailgun and Heartbleed

This was reported on April 10, 2014...

Read More

The golden age of scammers: AI-powered phishing

Long live the prince of Nigeria, he had a good run. Gone is the age where scammers wield the same mediocre power as a snake oil salesman, reliant on their own persuasion and...

Read More

What are SYN flood attacks and how can you defend against them?

“We’re under attack!” It’s a line that could very well be taken directly from Star Wars or The Matrix, but it’s also a cyber security reality. These attacks are not only sneaky but can be...

Read More

Popular posts

Email inbox.

Email

5 min

Build Laravel 11 email authentication with Mailgun and Digital Ocean

Read More

Mailgun statistics.

Product

4 min

Sending email using the Mailgun PHP API

Read More

Statistics on deliverability.

Deliverability

5 min

Here’s everything you need to know about DNS blocklists

Read More

See what you can accomplish with the world's best email delivery platform. It's easy to get started.Let's get sending
CTA icon