Billy (BK) Rios » The Old Dog and his Old Tricks (Part I)

Tuesday, September 18th, 2007

The Old Dog and his Old Tricks (Part I)

Lets say I found a CSRF that allows me to hijack your Gmail account to send an email from you to another Gmail user… would you consider it a risk? Well, the good news is I don’t have a CSRF to send out email from your Gmail account, but the bad news is I don’t need CSRF (or any other exploit) to send an email from your Gmail account.

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!

Posted by xssniper | Filed in Security

http://www.gnucitizen.org pdp

heh, well the simplest things work the best.
http://www.cudge.org/ lordm

Billy,

Funny 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
http://xs-sniper.com Nathan McFeters

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.

I truly feel bad that our industry does that so much… someday people will realize there is no magic pill.
/nul

Well, it seems that Google already disabled the relaying “feature”.
xssniper

Actually… the SMTP server I used in the example still works….
/nul

I’ve tried smtp.google.com. Relaying disabled:

http://shrani.si/f/2T/o2/RggjRFa/smtp.png
rcarter

I guess we always need to keep in mind how protocols work and the “features” they have. Nice find.
xssniper

@ /nul – I’m not going to give you the address of the SMTP server I used… but smtp.google.com is NOT it…..
/nul

Billy, 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
/trash

Some 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.
xssniper

@ /trash

I 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
http://xs-sniper.com Nathan McFeters

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.
http://www.awesomeandrew.net/ Awesome AnDrEw

EXPN, 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.
sjovan

wow.. 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.

no, i didn’t bother clicking the link.

realy good articel and you did make a lot of good points