Using Google's SMTP servers, I can send an email from any Gmail (or @google.com) account to any other Gmail email address. The process is simple... and is shown in the images below (addresses masked to slow the kiddies).
This is NOT a vulnerability in Google's infrastructure... it's merely how SMTP was DESIGNED to work. This same procedure works on other SMTP servers as well. Many of the old protocols (like SMTP) that we continue to use everyday are inherently insecure. My favorites are DNS, SMTP, and ARP. Many of the exploits based on these protocols aren't really even exploits... they are simply an abuse of functionality intentionally built into the protocol!
How could we let things get so bad? Why should I be ALLOWED to send an email on your behalf, sending colorful messages to other Gmail users? Honestly.... I don't know... what I do know... is instead of fixing the underlying protocol (which is painful, costly, and resource intensive) we've "bolted on" temporary fixes like spam filters to help us "fix" the issues with the underlying protocol. After a while... we get used to having these "bolt on" and the temporary fixes become permanent fixes and the underlying protocol remains vulnerable to simple attacks like this one.
I know what you're saying.... "SMTP was created in the wild wild west... times have changed... that will NEVER happen again!" The sad thing is... we're starting to see the same things happening to HTTP. Just as SMTP Admins have turned to Spam filters and other appliances to make up for the shortcomings of SMTP, we are now seeing that many are turning to Application Firewalls to make up for the shortcomings of HTTP and poor coding practices. There are some that claim that application firewalls are a great "temporary fix", and they probably they are! Just as Spam filters were a temporary fix for SMTP abuses!
heh, well the simplest things work the best.
ReplyDeleteBilly,
ReplyDeleteFunny you posted this. I was just goofing around with this very thing and was actually kind of amazed this approach still worked. I'm kinda shocked that there is not more abuse using this vector. I'll be using it in future social engineering efforts during pen tests!
later
Great point on the web app firewalls... we've gone through them like a chainsaw through a stick of butter so far. Even as a temporary fix most of them are currently snake oil.
ReplyDeleteI truly feel bad that our industry does that so much... someday people will realize there is no magic pill.
Well, it seems that Google already disabled the relaying "feature".
ReplyDeleteActually... the SMTP server I used in the example still works....
ReplyDeleteI've tried smtp.google.com. Relaying disabled:
ReplyDeletehttp://shrani.si/f/2T/o2/RggjRFa/smtp.png
I guess we always need to keep in mind how protocols work and the "features" they have. Nice find.
ReplyDelete@ /nul - I'm not going to give you the address of the SMTP server I used... but smtp.google.com is NOT it.....
ReplyDeleteBilly, I'm *not* begging for the SMTP address at all. It's just that I thought Google already disabled relaying (since it got public) and then just to make clear not all Google SMTP servers are affected. On a side note: it's always nice to watch "old school" stuff rising again :)
ReplyDeleteSome Google system with MTA is configured to believe form source address. In fact, they don't care if the sender address comes from the sender domain. This is not a relaying. This situation is acceptable by new RFCs about SMTP. SMTP protocol MUST be "reviewed" but that is another problem.
ReplyDelete@ /trash
ReplyDeleteI couldn't agree with you more! This isn't relay or a vulnerability with Googles SMTP servers, it's simply the way SMTP was DESIGNED to work. The whole point of the post was to talk about how SMTP and other protocols are inherently insecure by design...
BK
It's funny... we've gotten so into spam filters and layer 7 firewalls and blah blah, blah blah, blah blah that we've forgotten some of these crazy week protocols.
ReplyDeleteEXPN, VRFY, and RCPT TO (as well as the other commands) are classic examples of "questionable" features that exist within the Simple Mail Transfer Protocol. I agree that it's insecure by design, but it is one of those cases where it's both a feature and a bug. 99% of the servers I've tested for relays have them disabled anyway.
ReplyDeletewow.. and that's how i got that funky mail from @google.com about my banking was insecure and i had to click a realy strange link and stuff.
ReplyDeleteno, i didn't bother clicking the link.
realy good articel and you did make a lot of good points :)