In his latest post, Brian Krebs reports on the exploit-of-the-week that's not really an exploit, depending on how you look at it. This time around, the bad guys are targeting users of a popular ticketing system to bounce their bad stuff into inboxes.
What's the Game?
It works like this:
Bad guy knows that company X uses ticketing system Z.
Bad guy sends a forged email to the Z ticketing system.
The Z ticketing system responds to the email, sending the reply back to the forged address.
The Z ticketing system is populating the response's subject line based on what was initially submitted by the bad guy.
Thus the bad guy is able to specify some specific text to put in front of the potential victim.
And the ticket reply email, the only thing the potential victim receives, is full authenticated and branded as company X.
Net result? Bad guy causes potential victims to receive a phishy or scammy email from company X.
How to Fix It
The fix? Brian says that this could all be avoided if "[ticketing system Z] customers validated support request email addresses prior to sending responses."
But what does "validated" mean in that context? Let me fill in the blanks as best I can, or really, just share with you what I would do to fix this, if it were up to me.
Don't blindly accept support requests from unverified users; require a login or that somebody be recognized as a customer first. I grant that this could be a problem for support queues intended to receive contact from non-customers, like abuse and compliance. But maybe don't send an auto-reply, if the submitter wasn't logged in or recognized, at least.
Don't include submitter-supplied information in the auto-response. If bad guys can't bounce custom content and/or links to unsuspecting third parties, this path is much less interesting to them.
Validate inbound email addresses before trusting that the attempt to open a ticket was legitimate. These inbound emails to the ticketing system are clearly forged. They're likely failing DMARC checks. DMARC could have very much helped here.
If Yahoo can check for, and reject forged email messages that fail authentication checks, why can't the ticketing system? It gets complicated.
Ticketing System Workflows Are Complex
I really want ticketing systems to reject stuff like this at the edge. But, I also understand why ticketing systems might not be able to easily enforce DMARC checks on inbound mail. Having dealt with a number of these types of systems myself, I know that sometimes people forward inbound email addresses to them. It is often part of the workflow.
Example: I tell the world that support@wombatmail.com is the support contact address. But that's a Google Workspace mailbox on my corporate mail domain. To get that inbound mail into the ticketing system, I am likely auto-forwarding anything received on to support-ticket@wombatmail.zticketingsystem.com.
That forwarding step breaks SPF and could even break DKIM, depending on what the forwarding system changes. DMARC could fail as a result, and I could end up dropping a legitimate email, and end up with an unhappy customer, one who hoped for a speedy support response, but never got one.
That makes things complex, but not insurmountable. Test it, fix it, offer options, and send clarifying rejections that link to more information.
Don't Forget Reputation
There's another reason to prevent this kind of thing from happening en masse: If the ticketing system's properly configured to authenticate its own outbound emails, there are likely two DKIM signatures: One for the ticketing system's domain, and one for the client's domain. Both of these email domains are going to end up taking a reputation hit, if this continues to happen at significant volumes. People will report it as spam at higher-than-average levels, because, well, that's what it is.
Meaning that all of this could lead to legitimate ticket responses going to the spam folder, because of what the bad guys did.
Krebs Is The Man
By the way, if you don't follow Brian Krebs and his "Krebs on Security" blog, you're missing out. It is well written and very insightful. I consider it essential reading because he doesn't just recycle and link to news (like I'm guilty of here); he engages in original investigative reporting with an intense focus on cybercrime, spammers, data breaches and so many other online threats.
In his latest post, Brian Krebs reports on the exploit-of-the-week that's not really an exploit, depending on how you look at it. This time around, the bad guys are targeting users of a popular ticketing system to bounce their bad stuff into inboxes.
What's the Game?
It works like this:- Bad guy knows that company X uses ticketing system Z.
- Bad guy sends a forged email to the Z ticketing system.
- The Z ticketing system responds to the email, sending the reply back to the forged address.
- The Z ticketing system is populating the response's subject line based on what was initially submitted by the bad guy.
- Thus the bad guy is able to specify some specific text to put in front of the potential victim.
- And the ticket reply email, the only thing the potential victim receives, is full authenticated and branded as company X.
Net result? Bad guy causes potential victims to receive a phishy or scammy email from company X.How to Fix It
The fix? Brian says that this could all be avoided if "[ticketing system Z] customers validated support request email addresses prior to sending responses."But what does "validated" mean in that context? Let me fill in the blanks as best I can, or really, just share with you what I would do to fix this, if it were up to me.
- Don't blindly accept support requests from unverified users; require a login or that somebody be recognized as a customer first. I grant that this could be a problem for support queues intended to receive contact from non-customers, like abuse and compliance. But maybe don't send an auto-reply, if the submitter wasn't logged in or recognized, at least.
- Don't include submitter-supplied information in the auto-response. If bad guys can't bounce custom content and/or links to unsuspecting third parties, this path is much less interesting to them.
- Validate inbound email addresses before trusting that the attempt to open a ticket was legitimate. These inbound emails to the ticketing system are clearly forged. They're likely failing DMARC checks. DMARC could have very much helped here.
If Yahoo can check for, and reject forged email messages that fail authentication checks, why can't the ticketing system? It gets complicated.Ticketing System Workflows Are Complex
I really want ticketing systems to reject stuff like this at the edge. But, I also understand why ticketing systems might not be able to easily enforce DMARC checks on inbound mail. Having dealt with a number of these types of systems myself, I know that sometimes people forward inbound email addresses to them. It is often part of the workflow.That makes things complex, but not insurmountable. Test it, fix it, offer options, and send clarifying rejections that link to more information.
Don't Forget Reputation
There's another reason to prevent this kind of thing from happening en masse: If the ticketing system's properly configured to authenticate its own outbound emails, there are likely two DKIM signatures: One for the ticketing system's domain, and one for the client's domain. Both of these email domains are going to end up taking a reputation hit, if this continues to happen at significant volumes. People will report it as spam at higher-than-average levels, because, well, that's what it is.Meaning that all of this could lead to legitimate ticket responses going to the spam folder, because of what the bad guys did.
Krebs Is The Man
Comments
Post a Comment
Comments policy: Al is always right. Kidding, mostly. Be polite, please and thank you.