[BlueOnyx:24101] Re: Outlook for Android failure

[Michael Stauber]

Hi Chris,

> In the process, we discovered that the actual authentication isn't
> taking place between the device running Outlook and the BlueOnyx
> server.   The login is coming from an IP address assigned to
> Microsoft.   Observe the following from the logfile:
> 
> Jul 14 15:38:31 web dovecot: imap-login: Disconnected (no auth attempts
> in 0 secs): user=<>, rip=52.125.128.99, lip=208.77.216.244,
> session=<bHhVymyqVIU0fYBj>
> Jul 14 15:38:31 web dovecot: imap-login: Disconnected (no auth attempts
> in 0 secs): user=<>, rip=52.125.128.99, lip=208.77.216.244,
> session=<QWRWymyqWIU0fYBj>
> Jul 14 15:38:31 web dovecot: imap-login: Login: user=<usernamehere>,
> method=LOGIN, rip=52.125.128.99, lip=208.77.216.244, mpid=19719, TLS,
> session=<iSleymyqWoU0fYBj>
> Jul 14 15:38:32 web dovecot: imap(usernamehere): Logged out in=11 out=436
> Jul 14 15:38:32 web sendmail[19816]: 06EKcWdS019816: [52.125.128.99] did
> not issue MAIL/EXPN/VRFY/ETRN during connection to MSA
> Jul 14 15:38:32 web sendmail[19819]: STARTTLS=server,
> relay=[52.125.128.99], version=TLSv1/SSLv3, verify=NO,
> cipher=ECDHE-RSA-AES256-GCM-SHA384, bits=256/256
> Jul 14 15:38:32 web sendmail[19819]: AUTH=server, relay=[52.125.128.99],
> authid=usernamehere, mech=LOGIN, bits=0
> Jul 14 15:38:32 web sendmail[19819]: 06EKcWmJ019819: [52.125.128.99] did
> not issue MAIL/EXPN/VRFY/ETRN during connection to MSA

Looking at the above I see a couple of unnecessary steps. Let's ignore
the dovecot connections for now. I'm meaning this one:

> [<IP>] did not issue MAIL/EXPN/VRFY/ETRN during connection to MSA

If you have fail2ban running with SMTP-checks set to "extra", then after
five of these (assuming default config) the IP will get the ban-hammer.

If someone tries that against one of my servers, the ban-hammer includes
doing a WHOIS lookup to then block the whole IP address range of the
originating ASN.

This is a common spammer practice: They use the VRFY command against the
MTA to check if an email address exists. This is (if VFRY is enabled) a
very fast check and you can poll a whole dictionary of usernames to see
if the MTA would accept them. A LEGITIMATE service is pretty ill advised
to use it. And I mean why the heck should they do it? If the AUTH fails,
then the account information is wrong. There is no need to run a VRFY
first and THEN do an AUTH.

If you have fail2ban, check /etc/fail2ban/filter.d/sendmail-reject.conf
and check this section:

# Parameter "mode": normal (default), extra or aggressive
# Usage example (for jail.local):
#   [sendmail-reject]
#   filter = sendmail-reject[mode=extra]
#
mode = extra

If it says "mode = extra", then the line "did not issue
MAIL/EXPN/VRFY/ETRN" is monitored and repeatedly triggering it will
result in a ban of the originating IP.

> AUTH=server, relay=[<IP>], authid=usernamehere, mech=LOGIN, bits=0

THAT is the normal login. That should work, but /var/log/messages will
tell you if it failed.

Now back to the  Dovecot connections:

>  dovecot: imap-login: Disconnected (no auth attempts in 0 secs)

They're doing the same there as well. They're probing and fingering the
connection before they actually try a login. This is a totally
unnecessary extra step, as they could directly try an AUTH against IMAP.

And they're even doing it twice: Two unnecessary AUTH against Dovecot,
two unnecessary VRFY against the MTA. With a stock fail2ban they have
five tries free in 600 seconds and they already used up four of these in
the first attempt. The next one drops the hammer.

> #2:  Do I just need to find myself a nice tinfoil hat or does this
> bother anyone else?   Microsoft / Outlook is essentially inserting
> themselves as a "man in the middle" and any encryption of the traffic
> that the user would assume exists between the server and the device is
> actually getting bypassed.   Which means that you're giving Microsoft /
> Outlook unfettered access to any of the messages stored on the server or
> that you send from your device.

I also think that this is pretty abhorrent and intrusive. It's like
giving MickeyMouse-Software the keys to your kingdom. Not only do they
then know the login credentials to your email account(s), but also see
your emails before you do. And there is NO way of knowing what they'll
do with that information, how long and where it is stored and who else
will have it. And it won't just be for "targeted advertising" and
"enhancing your user experience". If I were using this as a business
client, then I'd qualify that as industrial espionage.

How much I trust Microsoft? Let me open the soap box for a second: In
February I bought an Office 365 subscription for the family as both
daughter and wife needed an up to date Office/Excel/Powerpoint. The
product is actually named "Microsoft 365 Family" now. The email address
I used for the purchase is an email alias that I used for NOTHING else.
Aliases make it easy to assign each vendor his own so that it's easy to
spot credential leakage. They way the Microsoft store works I had to pay
the sum in Colombian Pesos based on my purchase address. Otherwise it
could have been in USD or EUR based on where and how I usually do my
online-shopping.

The kicker? A couple of weeks later I got a very obvious SPAM to *that*
exact email address, mentioning a billing problem for the ongoing
subscription. The email mentioned the exact purchase date, the exact
product type "Microsoft 365 Family" and the sum in Colombian Pesos (not
EUR or USD) and asked me to login to a fake lookalike site to sort out
the billing. That site was hosted on a Romanian IP and the email itself
originated from a mailserver in Ukraine. The obvious question being:
Which revolving door at Microsoft did they carry *that* bundle of
information out of?

But back to topic: Given Microsofts industry position, security track
record and geo-political leaning I think it's a terrible idea to let
them handle your emails *this* way. European clients also have the issue
that this - most likely - isn't GDPR/DSGVO-conforming either.

-- 
With best regards

Michael Stauber