I was working with one of my clients the other day when the head of Information Security came into the room along with the IT Director. You could tell by the clap of thunder that accompanied them that this wasn’t going to be good. It turns out that some nasty little bugger out on the Internet had discovered that he or she could send emails in to users in this company and spoof the sender address as another user within the company. The evil attacker decided to exploit this by sending PDF attachments containing malware, and making the emails look like they were from the head of the company, telling users to open the PDF to view important information regarding their benefits plan.
End users looking at the email couldn’t tell it wasn’t from the big boss, and information regarding benefits is enough to pique anyone’s interest, so of course dozens of users opened the PDF-many had not yet patched their Adobe software and as a result were exploited.
This became an “all hands on deck” issue that had to be resolved immediately. Our assignment was to drop everything else, figure out how spoofed emails were getting in, and stop them.
We all know how to execute SMTP commands in a TELNET session to specify a sender address. Most of us have probably automated that process at some time using BLAT or some other software package. Most of us probably configure our email gateway not to accept email from the outside world purporting to be from the inside. This client didn’t.
It was easy enough to find, and to fix, and we did so quickly and reported the door firmly locked. It was for another group to clean the infected machines, so we thought our role in this was done, but then the help desk tickets started flowing in that project management notifications were not getting in.
It seems this client uses a cloud based PMO app that sends notifications to users using an internal address as the source. Yes, it was spoofing internal addresses. As soon as we blocked the attack vector of the malicious user, we broke the functionality of the external app.
The point of this post is not to describe what we did to address this new issue. It’s to talk about what the root cause of this issue was. No, it’s not that we “broke” an app responding to a security issue. It’s that an app was taking advantage of a poor security configuration and doing something it never should have done.
As more and more applications and services move to the cloud, you will likely encounter more applications that exist outside of your network, but that will want to send email in to your internal users, and make it look like the email is internal. You want to make sure that when it comes to email, only one or the other of these two situations exists.
1) The app sends email using an authenticated connection, or
2) Your system accepts the email using a dedicated connector set up so only the app can use it.
Under no circumstances should you ever allow anonymous systems to connect to your MTA and send email using a source address that is internal to your company. Spoofing the sender address may make your users feel better about the app, but that doesn’t mean you should drop your guard and run an insecure system. Requiring authentication from the app sending the email, or if it cannot support that, using a dedicated connector that will only accept email from the provider’s network ranges, will enable this masquerade for the specific app to fool your users, but won’t let the bad guys have free reign on your email system.
When it comes to spoofing, just say NO!