Jump to content


 


Register a free account to unlock additional features at BleepingComputer.com
Welcome to BleepingComputer, a free community where people like yourself come together to discuss and learn how to use their computers. Using the site is easy and fun. As a guest, you can browse and view the various discussions in the forums, but can not create a new topic or reply to an existing one unless you are logged in. Other benefits of registering an account are subscribing to topics and forums, creating a blog, and having no ads shown anywhere on the site.


Click here to Register a free account now! or read our Welcome Guide to learn how to use this site.

Photo

Lack of Anti-Spoofing for Companies.


  • Please log in to reply
1 reply to this topic

#1 chris155au

chris155au

  • Members
  • 1 posts
  • OFFLINE
  •  
  • Local time:11:52 PM

Posted 12 January 2017 - 12:30 AM

I'd never really given it much thought. All I knew is that in under a minute, I could get into an email client and make a new email account with the Header Sender Address, "x@microsoft.com" and the Sender ID, "Microsoft Security." But the more I think about it, the more outrageous it seems that this is possible. One solution would be to simply introduce a standard in email clients where the users username domain has to also be the Header Sender Address domain; and I cannot believe that isn't the case currently. However, today I came across SPF, Sender Policy Framework, in particular 'OpenSPF' designed to detect someone spoofing.

 

If this technology exists, then why don't Microsoft and banks use it?


Edited by chris155au, 12 January 2017 - 12:31 AM.


BC AdBot (Login to Remove)

 


#2 Kagern

Kagern

  • Members
  • 1 posts
  • OFFLINE
  •  
  • Local time:10:52 PM

Posted 16 January 2017 - 01:03 PM

While there is nothing that prevents you from just calling yourself bill.gates@microsoft.com and sending messages, there are systems in place meant to prevent that messages sent in this way from getting anywhere.  SPF tells servers where messages for a given domain should be coming from, DKIM establishes cryptographic proof that a message came from a valid source, and DMARC sits on top of DKIM and SPF to establish a policy which tells clients what should be done with messages failing validation using these.  Adoption of new standards doesn't always happen quickly (DMARC is about 4 years old now), and it will take time for these to become widely deployed.

 

I've used DMARC quite successfully in organizations that were subject to highly targeted spoofing and phishing attacks (to the point of creating messages that contained fake exchanges between corporate officers).






0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users