MS Spear Phishing Attack simulator can potentially expose your users' passwords

Quite some time since my last post, but I had some pretty nice case recently, and because MS support seems not really interested to make deeper investigation by themselves, I wanted to put this piece of information somewhere, so others can also be aware about the potential security flaw in the tool called "Spear Phishing (Credentials Harvest) Account Breach" in the Attack simulator set of tools. You can find these tools on the Office 365 Security & Compliance portal in Threat management section.

First of all, what this tool is and what it does? In a very short, this tool allows you to send a specially crafted message to your users , which contains links to a quasi-malicious page disguising the genuine Office 365 login page. Why "quasi-"? Because in fact these pages are on the MS controlled domains, however not really used for real MS services. Example links from the tool: http://portal.docdelivaryapp.com, http://portal.hardwarecheck.net or http://portal.docstoreinternal.net.

Insecure autoconfiguration lookups in Thunderbird

Recently I've tried an autoconfiguration feature in Thunderbird. When I was trying to figure out how it works and at what sequence it lookups for the configuration, I noticed that I didn't have SSL configured on my test web server, but Thunderbird received the configuration anyways.

Of course, I have some concerns with not using SSL by Thunderbird when it looks for the configuration. Here I have found a final (?) conclusion about using SSL:

DNS MX: Mail delivery between domains happens via DNS MX lookups,
 which are insecure. In other words, an attacker can already
 re-route and intercept new mails. The risk of interception during
 account setup is not larger than that. More importantly:
Guessed configs: An attacker can easily *prevent* connections,
 making the ispdb lookup (via https), isp fetch (via https) and
 heuristics for IMAP SSL servers and IMAP servers with secure auth mechs
 all fail, making us fall back to plaintext auth, and that's it, game over.
 Therefore, lookups via http don't add risk.

But I cannot agree with that, because intercepting emails is not the only target for the possible attack.

I've made an experiment, and create a network with a specially prepared DNS server, which redirects autoconfig.gmail.com and gmail,com to a local http server, with an autoconfig file that provides addresses to the wrong imap and smtp servers. Thus, when client tries to configure an account and just clicks "Continue" and "Done" without looking at the IMAP server address, an attacker can intercept his password if provide him with the server address for which he has an SSL certificate.

Good news: it's not so easy to use some pretty-looking addresses like the one on the screenshot. Because you need to have a trusted SSL certificate for this name. And if not use SSL in provided IMAP/SMTP configuration, Thunderbird will warn you with a big red window.

However, the attacker can use any server name if he has any stolen server certificate, and user can just don't pay appropriate attention to the values in the configuration.

Attack vector: force user to reconfigure their mail client with fake mail servers.

• Prepare a router with a transparent proxy and/or a specially configured DNS service.
• Router shall block all encrypted outgoing IMAP and SMTP connections.
• Router will redirect all autoconfig.[domainname] and [domainname]/autocinfig... to a web server with a prepared fake configuration. (It can be a script that will response with the configuration for any domain requested)
• Prepare a server with imap and smtp services with a stolen SSL certificate. DNS service will direct all requests to this server.
• Put this setup with an open WiFi to any crowded place (hotels, hospitals, bus/train stations, etc.).
• ... PROFIT

Of course, the configuration above is very simplified. Final configuration can be more intelligent and should allow user to browse Internet and use other services normally, so user will be sure that the only problem is a mail client.

Some users tend to re-configure from scratch their applications if something won't work. Of course, make this setup for collecting the Thunderbird users password only is not effective, but this could be a part of an attacker tools-set aimed to collects the data on public networks.

Complicated passwords - it's easy!

I've decided to write about the passwords in a first post, because it's something I think about almost every day. Maybe, because people around me just thinks that hard passwords are hard to remember, so a "small" chance to have their passwords stolen don't worse the real danger to forget it. I'm facing the weak passwords issues pretty often, and every time I say a magic phrase: "mnemonic formulas". "What is it?" asks users. "It's something that will help you to have the complicated unique passwords for every site you're visiting". I will not come up with my own definitions and descriptions and just put some quotations below.

So, the first result of the google search for "password mnemonic formulas" gave me this document with a simple definition:

A Mnemonic Password Formula, or MPF, is a memory technique utilizing a predefined, memorized formula to construct a password on the fly from various context information that the user has available.

Actually, information in the document is enough to understand how it works, I just to put here a quote with a simple formula example:

A Simple MPF
The following simple formula should be sufficient to demonstrate the MPF concept.
Given the authenticating user and the corresponding authenticating system, a formula like that shown in the following example could be constructed. This example formula contains two elements: the user and the target system identified either by hostname or the most significant octet of the IP address.

< user >! < hostname|lastoctet >

The above MPF would yield such passwords as:
• ”druid!neo” for user druid at system neo.jpl.nasa.gov
• ”intropy!intropy” for user intropy at system intropy.net
• ”thegnome!nmrc” for user thegnome at system nmrc.org
• ”druid!33” for user druid at system 10.0.0.33
This simple MPF schema creates fairly long, easy to remember, passwords that contain a special character. However, it does not yield very complex passwords. A diligent attacker may include the target user and hostname as some of the first combinations of dictionary words used in a brute force attack against the password.
Due to the fact that only the hostname or last octet of the IP address is used as a component of the schema, passwords may not be unique per system. If the same user has an account on two different web servers, both with hostname ”www”, or two different servers with the same last address octet value within two different sub-nets, the resultant passwords will be identical. Finally, the passwords yielded are variable in length and may not comply with a given systems password lengthpolicies.

 Generally - that's it. Stay secured!