This post covers a weird and simple vulnerability that I found in Microsoft Office 365 service. To be honest, I can't say I fully understand the logic behind of this vulnerability. Anyway, it's fixed now.

In september, I was testing spam filters of various e-mail services such as Gmail, Outlook 365 and Yandex. I used my university e-mail address which uses Office 365 Web Service and personal e-mail addresses from Gmail and Yandex. I installed sees tool on an Amazon server to send phishing e-mails. The test wasn't so successful. A sample setting for targeting my Yandex e-mail:

It landed on spam folder. Tried with Gmail and Outlook 365, still no luck. Maybe this tool was not so efficient maybe I was doing a mistake, I wasn't sure.

Suddenly, a weird thing happened. I saw an e-mail on my Yandex inbox which has "Verify Test 2" on it's subject field and has a green valid sign.

At first few seconds, I was thinking that I accidently sent another test e-mail to my Yandex e-mail and it worked. But then I realized I was using "Verify Test 1" subject for Yandex, and "Verify Test 2" for Outlook. There should be something else.

After few minutes of inspection, I remembered that I set up an e-mail forwarding rule for my Outlook 365 e-mail to Yandex. So, Outlook forwarded this e-mail to Yandex. But why that valid sign appeared now?

I checked it in Yandex's website it says: (By the way this feature is not supported anymore.)

"With a DKIM signature, the email recipient can verify that the message really came from the supposed sender."

It was a simple DKIM(DomainKeys Identified Mail) validator. So basically if an e-mail signed by a valid certificate regarding to the domain name of the sender, we see that cool icon. So, sender domain is microsoft.com, it should have been signed by Microsoft's certificate??

In order to understand whats going on, I checked the headers of these spam and valid e-mails. The header below is belongs to the e-mail which is marked as spam by Yandex:

Received: from mxfront15h.mail.yandex.net ([127.0.0.1])
	by mxfront15h.mail.yandex.net with LMTP id HG70cJmK
	for <[email protected]>; Sat, 3 Sep 2016 22:02:37 +0300
Received: from ec2-52-51-33-8.eu-west-1.compute.amazonaws.com (ec2-52-51-33-8.eu-west-1.compute.amazonaws.com [52.51.33.8])
	by mxfront15h.mail.yandex.net (nwsmtp/Yandex) with ESMTP id K8106KgL1a-2aGmWbm2;
	Sat, 03 Sep 2016 22:02:36 +0300
Return-Path: [email protected]
X-Yandex-Front: mxfront15h.mail.yandex.net
X-Yandex-TimeMark: 1472929356
Authentication-Results: mxfront15h.mail.yandex.net; spf=fail (mxfront15h.mail.yandex.net: domain of example.com does not designate 52.51.33.8 as permitted sender) [email protected]
X-Yandex-Spam: 1
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by ip-10-0-0-12.eu-west-1.compute.internal (Postfix) with ESMTP id 2749C42DA5
	for <[email protected]>; Sat,  3 Sep 2016 19:02:36 +0000 (UTC)
Content-Type: multipart/alternative;
    boundary="127.0.0.1.0.4022.1472929356.122.1"
From: Johannes Brahms <[email protected]>
Subject: Verify Test 1
MIME-Version: 1.0
To: [email protected] 

It's received by Amazon server, there is no valid signature, no surprise it was landed on spam folder. Let's check the header of valid e-mail:

 Received: from mxfront9h.mail.yandex.net ([127.0.0.1])
	by mxfront9h.mail.yandex.net with LMTP id anm2f8eB
	for <[email protected]>; Sat, 3 Sep 2016 22:05:49 +0300
Received: from mail-he1eur01lp0215.outbound.protection.outlook.com (mail-he1eur01lp0215.outbound.protection.outlook.com [213.199.154.215])
	by mxfront9h.mail.yandex.net (nwsmtp/Yandex) with ESMTPS id **REMOVED**;
	Sat, 03 Sep 2016 22:05:48 +0300
	(using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits))
	(Client certificate not present)
Return-Path: [email protected]
X-Yandex-Front: mxfront9h.mail.yandex.net
X-Yandex-TimeMark: 1472929548
Authentication-Results: mxfront9h.mail.yandex.net; dkim=pass header.i=@bilgiedu.onmicrosoft.com
X-Yandex-Spam: 1
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=bilgiedu.onmicrosoft.com; s=selector1-bilgiedu-net;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version;
 bh=**REMOVED**
 b=**REMOVED**
Resent-From: <[email protected]>
Received: from HE1PR0401CA0023.eurprd04.prod.outlook.com (10.166.116.161) by
 AM5PR0401MB2563.eurprd04.prod.outlook.com (10.169.245.14) with Microsoft SMTP
 Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id
 15.1.609.3; Sat, 3 Sep 2016 19:05:44 +0000
Received: from AM5EUR02FT060.eop-EUR02.prod.protection.outlook.com
 (2a01:111:f400:7e1e::203) by HE1PR0401CA0023.outlook.office365.com
 (2a01:111:e400:c512::33) with Microsoft SMTP Server (version=TLS1_0,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.609.3 via Frontend
 Transport; Sat, 3 Sep 2016 19:05:44 +0000
Received-SPF: Fail (protection.outlook.com: domain of example.com does not
 designate 52.51.33.8 as permitted sender) receiver=protection.outlook.com;
 client-ip=52.51.33.8; helo=ip-10-0-0-12.eu-west-1.compute.internal;
Received: from ip-10-0-0-12.eu-west-1.compute.internal (52.51.33.8) by
 AM5EUR02FT060.mail.protection.outlook.com (10.152.9.179) with Microsoft SMTP
 Server id 15.1.587.6 via Frontend Transport; Sat, 3 Sep 2016 19:05:43 +0000
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by ip-10-0-0-12.eu-west-1.compute.internal (Postfix) with ESMTP id E7BF642DA5
	for <[email protected]>; Sat,  3 Sep 2016 19:05:42 +0000 (UTC)
Content-Type: multipart/alternative;
	boundary="127.0.0.1.0.4033.1472929542.917.1"
From: Johannes Brahms <[email protected]>
Subject: Verify Test 2
MIME-Version: 1.0
To: <[email protected]>

To be honest, I didn't fully understand whats going on since I'm no expert on e-mail authentication topic. E-mail received by outlook.com domain and has a DKIM signature info in it. Let's check that (I removed bh and b fields):

 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=bilgiedu.onmicrosoft.com; s=selector1-bilgiedu-net;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version;
 bh=**REMOVED**
 b=**REMOVED**

a= the signing algorithm

c= the canonicalization algorithm

d= signing domain

h=the list of signed header fields

bh= body hash

b= digital signature of the contents

So my e-mail address is [email protected] but the signing domain is bilgiedu.onmicrosoft.com. I'm not sure if it's like that on all Outlook 365 clients, probably it is.

But in the e-mail, sender is [email protected]. This part was a confusion for me. Is onmicrosoft.com's signature is same with microsoft.com? If so that's an issue on Microsoft's side. Or, it's not like that and Yandex has an issue on identifying valid DKIM signatures. Or, I totally don't know shit about this DKIM stuff.

Update (20 November 2016): Reddit user ptmb wrote a good explanation about whats going on:

"To further develop on /u/indrora 's explanation of DKIM, the problem here, and why it was related to DKIM, was that when Outlook was redirecting the messages it was signing them with it's own DKIM key instead of keeping whatever signature was originally in the email (or lack of it).
That means that instead of having an email with a proof of identity from the original sender, you received an email with a proof of identity from the "redirector".
And because Outlook was blindly signing these messages it was redirecting, if the message had a fake from field saying [email protected], then after Outlook blindly redirected it, it'd have a genuine DKIM signature from microsoft by coincidence, even though the original email wasn't from Microsoft at all."

I decided to do some additional tests. I changed my forwarding address to my Gmail address and sent another spam e-mail with microsoft.com domain to my Outlook address. It landed on spam folder in Outlook and inbox in Gmail.

I changed forwarding address to Yandex again. This time I changed the spam e-mail's domain with an other domain name than microsoft.com. It landed on spam box in both Outlook and Yandex. Also there was no "green valid sign" on it (obviously)

Even if I didn't fully understand whats going on, I could send valid e-mails from microsoft.com to anyone.

Anyway, I decided to notify both Yandex and Microsoft. I said to Yandex you may have a problem with that "green valid sign", it may cause a security illusion for users. Also I sent a vulnerability report to Microsoft.

I couldn't hear back from Yandex but later on Microsoft security team said they reproduced the vulnerability. After some time, vulnerability is fixed. The weird thing is, Yandex disabled that "green sign" feature after some time (I don't know exact date). I'm not sure if it's related with this anomaly. Anyway, you can find remediation timeline below.

Timeline:

-September 3, 2016: Issue reported to Microsoft

-September 3, 2016: Microsoft forwarded the report to analysts

-September 29, 2016: Microsoft said they reproduced the issue

-October 27, 2016: Microsoft said the vulnerability is fixed

-November 2016: Microsoft gives credit to me: https://technet.microsoft.com/en-us/security/cc308575