2

After an incident, I have a question which answer's I cannot find. I cannot provide the real headers as they come from a client.

Let’s consider a company which uses an Office365 tenant as mail server. Its domain is example.com, and mail addresses are name@example.com. Employees thus all have a name@example.com account.

The company has published the default Office365 SPF: v=spf1 include:spf.protection.outlook.com -all

The company does not have either a DKIM published nor a DMARC policy.

Would it be possible to connect with a random Outlook account (attacker@outlook.com) to smtp-mail.outlook.com or Outlook.office365.com with protocol SMTP, and then craft an email using name@example.com?

The SPF would pass as the mail is sent from the right servers. The question is more about Microsoft performing access control on emails sent through their SMTP servers.

This question would probably exist for other companies managing mails for you that also host public-accessible emails.

schroeder
  • 123,438
  • 55
  • 284
  • 319
Ixiliae
  • 21
  • 2
  • Closely related, to the point of possibly being a duplicate: https://security.stackexchange.com/questions/185898/can-spf-be-bypassed-by-using-a-shared-email-server/185902#185902 – IMSoP Jun 13 '19 at 15:28
  • Indeed, the question is similar, except the other one was not focused on O365 – Ixiliae Jun 14 '19 at 07:34
  • Right, but if you rephrased the question as "Does Microsoft properly implement access control when you pay them for cloud services?" it would probably be closed as off-topic, because a) only Microsoft could answer; and b) any answer other than "yes" would be a huge scandal. – IMSoP Jun 14 '19 at 09:08

3 Answers3

1

Would it be possible to connect with a random Outlook account (attacker@outlook.com) to smtp-mail.outlook.com or Outlook.office365.com with protocol SMTP, and then craft an email using name@example.com?

Generally not. By default, all SMTP connections to O365 must be authenticated first.

In the case of a domain having a non-authenticated SMTP connector set up, it would typically be restricted to accept mail from specific IP addresses only, i.e. ones that you trust to send email for your domain.

Third party email providers may handle authentication differently, and may in fact be susceptible to this type of spoofing.

MarianD
  • 244
  • 1
  • 2
  • 7
Jens Ehrich
  • 223
  • 3
  • 8
0

SPF works well, but it has significant limitations. For multi-tenant email servers, if you specify their servers as an authorised sender, then anyone using that sender would also be authorised, unless the email service does internal checks to make sure that an email cannot be sent from its service to a domain it hosts. But that kind of checking is simply a business logic check to protect its customers and is up to each email hosting service.

For Office 365, specifically, they set up DKIM for the initial domain, which solves the problem you describe, at least on one level. If they sign emails with their own central signing process (indications are that they do), then even DKIM will not help because the spoofed header will be valid.

schroeder
  • 123,438
  • 55
  • 284
  • 319
  • Thanks a lot. My question was indeed mostly about the internal checks that Microsoft may have set up. As for the DKIM, it by default setup for Office365, without the company publishing its DKIM record ? How would that work if the check is made on the TXT dns records of the company's domain ? I understand that would workd for company.onmicrosoft.com domains, but not for company.com – Ixiliae Jun 11 '19 at 10:12
  • O365 might have published it for you. You can try a DKIM checker and look up your domain. What any one hosting company does internally is entirely up to them. and for O365, the options change based on the level of protection you buy. If you are specifically concerned about O365 and want details, you will need to contact their support. – schroeder Jun 11 '19 at 10:30
  • I contacted their support and even some internal contact at Microsoft, which were of absolutely no help on the matter - their answers were completely out of the context. My goal was to determine if someone with only an SPF published was at a "higher risk" of being spoofed than someone without SPF in the case of tenants like O365 – Ixiliae Jun 11 '19 at 11:48
  • There is no higher risk of being spoofed with SPF. It just offers no protection in this case. – schroeder Jun 11 '19 at 11:51
  • What I mean by higher risk would be that reading the header and not knowing a lot about e-mail protection, it would be possible to have an SPF=pass and thus assume the email was sent from the legitimate server. Thank you for your help ! – Ixiliae Jun 11 '19 at 13:49
  • 1
    That's not a higher risk of spoofing, that's a higher risk of not understanding the limitations of this one control. – schroeder Jun 11 '19 at 14:42
  • It is indeed what I meant through this. It is just something that could induce human error. Thank you. – Ixiliae Jun 12 '19 at 13:38
  • Alas, even in something as broadly applied as SPF, there is no silver bullet. – schroeder Jun 12 '19 at 13:40
  • DKIM doesn't help any more than SPF here: as soon as you send the unsigned message to an SMTP server, it's up to that SMTP server to decide whether to sign it or not. Either it checks your authorisation, and would reject the message completely, or it doesn't check (or can be tricked) and will sign the message before sending it on. – IMSoP Jun 12 '19 at 15:41
0

When you include any mail server in your SPF record, what you are specifying is that you trust that server to only send mail with your permission.

Consider the case where you run an SMTP server for a single domain, example.com, and you give out logins to that server to various users. You take on a student placement, and give them an address student@example.com. They discover that you have messed up the server's security, and they can write mail from ceo@example.com without it being rejected or rewritten. SPF cannot detect this abuse, because it only ties the domain to the server, and has no knowledge of users.

If you delegate SMTP services to a server that runs multiple domains, the situation is effectively the same: it is up to that server to determine which user is authorised to send from which domain (and which address on that domain). If Microsoft failed to do this with Office365, it would be considered a major security breach, but SPF would not detect it.

Note that the same applies to DKIM: the signature is generally added on a shared server, after the mail has been submitted by a client (Outlook, Thunderbird, etc) so you are trusting that server to only sign legitimate messages.

The only way you can remove this layer of trust is to sign or encrypt the message in the mail client, before sending it to any SMTP server (e.g. using GPG or S/MIME). However, support for this is far from universal, and you need a way to inform people that they should check messages against a particular public key, so it's not particularly useful for every-day spam prevention.

IMSoP
  • 3,780
  • 1
  • 15
  • 19
  • This is exactly what I was trying to assess here : if Microsoft was actually performing those checks. The problem being that I have not been able to reach to anyone that has a definite answer, and that I do not have in my possession a test tenant allowing me to try that out. Thank you for your answer. – Ixiliae Jun 13 '19 at 08:12
  • I think you're unlikely to get a satisfactory answer, because you're basically asking them if they're doing their job, like asking McDonald's if their burgers are safe to eat. This isn't really about SPF, it's just basic account security: if you log in with a particular username, you should only be able to do things as that user. If you don't trust Microsoft to perform basic security, use a service you do trust. – IMSoP Jun 13 '19 at 08:42
  • I do think they perform this access control - I would just need an official response for clients I have been working with. – Ixiliae Jun 13 '19 at 11:23