Illustration from Microsoft (edited by us)
note: maybe readers will found many grammar mistakes in this article. However, we wish we could deliver the main point of this article.
Doing groove in mobile is almost an inevitable thing for most of users in the world especially in professional fields. Sending an email, creating a document, accessing a contact information, even communicating either with audio and audiovisual are common things we always encounter along with the growth of mobile technology development and also the availability of Internet package.
Microsoft as a one of familiar large companies also sees the opportunity so they increasingly innovating to develop their technology to answer the users’ needs. The reality of this own can be seen from the email, Skype, online-based office application services, games, search engine, even other integrated services at Outlook.com.
Based on the statistic titled “Microsoft by the Numbers” which can be accessed from Microsofts’ official site, noted that the users of outlook.com service have reached more than four hundred active users until now.
Figure 1: Outlook.com by Numbers – Picture from Microsoft
Seeing the massive numbers of users and the enormity of the service usage, Microsoft has attempted to do various precautions to avoid the account theft, such as creating a sensitivity searching program, embedding a CAPTCHA on outlook.com service even temporarily blocking the access – Smart Account Lockout (“New best practices + #AzureAD and MSA can help”) when there are too many errors with the password entered on a valid account.
Figure 2: Smart Password Lockout – Microsoft Service Account – Temporary Blocked
Figure 3: Smart Password Lockout – Microsoft Service Account – CAPTCHA
In this topic, we will discuss the issue which can “authorize” the Attacker to bypass the protection with brute force attack in Microsoft’s outlook.com. By using the issue, then the Attacker will be able to continue to “search” the valid password of a registered account without worrying to “deal with” CAPTCHA feature or access blocking.
2.1. Definition of Brute Force Attack
We are pretty convinced that the readers have known for sure the definition of Brute Force Attack. But to complete this modest article, we also try to explain in simple terms about the definition.
Based on the Wikipedia summaries, Brute Force Attack is a trial activity which attacks the possibilities of passwords which may be used by the users. The purpose is no other of taking over the user’s account illegally. In the process, the Attacker should have a lexicon first that “allegedly” contains the passwords that may be used by the users. If the password used by the user is not “registered” in related lexicon, the Attacker will fail to take over the account referred to the attack. Briefly, the harder the password used by the user, the more difficult it is for the Attacker to take over the account.
In reality, the attack also can be addressed to the possibility of the username. When the username is unknown or difficult to guess, the more difficult it is for the Attacker to take over the account in this way.
2.2. Definition of CAPTCHA
CAPTCHA stands for “Completely Automated Public Turing Test to tell Computers and Humans Apart”. Simply, this feature is frequently used to distinguish the activity conducted between computer and human. (Of course the reader remembers about the Turing’s test with similar purpose. The only difference is, this test is conducted by a computer so that always known as Reverse Turing Test).
In the application, the feature needs one simple step conducted by the user, such as typing some letters shown in the picture or choosing the picture appropriate with instructions
2.3. CAPTCHA and Temporary Blocked at Outlook.com
As long as we have learned and know (at least until the article is made – May 28th, 2016), Microsoft has anticipated the Brute Force Attack from the Attacker by activating the CAPTCHA feature on certain circumstances as well as temporary blockage for an account. The exact thing we know is after ten invalid attempts, one of the features will be activated.
2.4. Web Browser VS Built-in Mail Application Access
As we know, to login into the Outlook service the user should access the outlook.com page through the web browser which will be redirected to https://login.live.com/ first. The problem is, this one particular thing does not apply when the user attempt to log in through the built-in mail application on iDevices (iPhone, iPod, and iPad).
In web browser, the user’s email address and password will be sent to https://login.live.com/ppsecure/post.srf?bk=<some_random_value>&uaid=<another_random_value?>&pid=0 with POST method containing some parameters such as:
Figure 4: Login into MSA via https://login.live.com/
However, in built-in mail application for iDevices, the email address and password will be sent in base64 form to https://m.hotmail.com/Microsoft-Server-ActiveSync. The value of this base64 is sent to the parameter Authorization as shown below:
Figure 5: Login via Built-in Mail Application via iDevices
Please note that the plaintext value of base64 consists of email_address:User’s_Password. So, if the victim’s email is firstname.lastname@example.org and the pass used is xyz, then the plaintext value is email@example.com:xyz.
Moreover, after the user logged in, Microsoft will actively check the conformity between an email address and password used by the user by re-doing the synchronization with their server. In this matter, Microsoft will send back the data to https://blu407-m.hotmail.com/Microsoft-Server-ActiveSync?User=<email_address>&DeviceID=<User’s_Device_ID>&DeviceType=<User’s_Device_Type>&Cmd=Ping accompanied by the base64 value explained earlier. For example:
Figure 6: Full Request from Microsoft to Server
As we can see, the following are a few summaries regarding the figure 2:
2.4.1. POST Method is sent to https://blu407-m.hotmail.com/. It should be noted that “blu407” can be replaced by blu408, snt405, or bay404;
Figure 7: Random Location of the URL
2.4.2. User as a parameter for the user’s email address;
2.4.3. DeviceID as an identity marker from iDevice used by the user;
2.4.4. Authorization as determinant parameter for model data items containing email address and pass of the user;
2.4.5. Basic in this term acts as a parameter which determines that the data submission such as email and a password is converted to base64 form.
There is also some additional information from the points:
- Cookies is not a big deal in terms of session for an Attacker so they still can use the active cookies to access other user email. In other words, cookies generated from the login process through the built-in mail application is not identical against an email and also the password used at certain times;
- When the data of “Authorization Basic” containing the true value, the server will give a response as “Account has been migrated”. Otherwise, if the value is false, the server will give the response as “Authorization header has syntax error”;
Figure 8: Valid Response – Account has been Migrated
Figure 9: Invalid Response – Authorization Header has Syntax Error
- And as an important note, we have not tried this one in built-in mail application on Android Based Devices so we don’t know regarding the methods applied in login activity.
2.5. While Synchronization Feature Betray the Outlook Service
Why do we bring this picturesque title eventually? Simple, this is because Microsoft gives no limitations for every Brute Force Attack activities launched by the Attackers to accounts at Synchronization Feature. Moreover, Microsoft has only changed the format of email address and password that the User used to base64 encoding.
As a proof, we also try to conduct an attack to the account we used with 1.000 login attempts in less than 8 minutes with no stopping.
Note: It’s important to know that there’s nothing wrong with this synchronization feature. Basically, if this feature is able to block; in case there is a password dissimilarity (because the User has changed it legally), so what will happen is the authorized User won’t be able to login when they have a chance to change the ‘saved’ password in their built-in mail application. The problem is, the process of sending email address & password is sent in base64 format so it’ll be easily read and an Attacker would be able to do brute force attack to an account.
III. STEP TO REPRODUCE
3.1. The first step is login to the Attacker account on one of the iDevices. The purpose is gaining a request sent by the Microsoft to the server as explained in 2.4.1.;
3.2. Specify the targeted account as a “target” and prepare the lexicon allegedly used by the target as a password;
3.3. Change an entire format into base64 and specify the parameter from 3.1 to be brute;
Figure 10: Content of the Authorization – Brute Force Parameter Location
3.4. The final step is the Attacker has just to wait the generated status. Using the burp suite, a status with the length of 239-241 will indicate the failure, while the length of 994-999 is succeed.
Figure 11: Response of the Invalid Password – around 239 – 241 Length of Bytes
Figure 12: Brute Force Attack is Success – around 994 – 999 Length of Bytes
IV. RESPONSE FROM MICROSOFT
With the status of one of the world-biggest tech-company, Microsoft keeps fit with their commitment to response every reports of security gaps in less than 24 hours. In this term, approximately 8 hours after the report sent, Microsoft directly responds.
Figure 13: Response from Microsoft
Unfortunately for them, this matter is an invalid security gaps remembering that Microsoft through the MSRC (Microsoft Security Response Center) has their own view regarding the definition of security gaps which can be seen on the official site. Rule is a rule and we can’t deny it.
In another view, it is not surprising if this problem is inconspicuous for Microsoft because they have applied another precautions such as blocking all weak passwords which are common used. On the other hand, Microsoft also applies the best practice in creating the password such as push the minimum length, password complexity, and maximum age of password.
However, there are some concerns from us for this matter:
- How many users will use the password that exceeds the minimum to be determined?
- What is the prevention of the user who create a password similar with email address, username, address, and so on which doesn’t comply with the rules?
When viewed, these concerns seem like to be a responsibility of user that should uses a strong password. However, one thing that we can suggest is “not all the users are accustomed with technology which maybe familiar with the creation of difficult password.”
4.1. Additional Information
On similar blog posted earlier, Microsoft also discusses the “Smart Password Lockout” feature. Unfortunately, until this article is posted, we know well that the feature is not going well.
4.2. Timeline of Reporting
May 24th, 2016 – We send a detailed report along with the video as a proof;
May 25th, 2016 – Microsoft gives a respond 8 hours after the report sent. Unfortunately the report is not included in susceptibility criteria in MSRC view;
May 25th, 2016 – We reply the email and discuss regarding the public disclosure given that the report is not included in susceptibility since this is not a valid vulnerability in MSRC point of view;
May 29th, 2016 – Overall improvement of report structure from previous one;
May 29th, 2016 – Public Disclosure.
V. SUMMARY AND RECOMMENDATION
As we have seen, the susceptibility depends on the degree of difficulty of password used by the user. Given that there is still no indication that Microsoft will fix this (or maybe not), so things below can be done by user:
- Create a complex password which doesn’t relate with personal name, family name, company name, etc. which relates with easily guessed personal things.
- Give a distinction between highly sensitive account with account registered to third-party like e-Commerce, forum, and etc.;
- Don’t ever use the same password between our own email with the password that registered to third part service;
- Always change the password regularly;
- Use the Two Step Verification (2SV) or Two Factor Authentication (2FA). We do not know exactly the availability of 2SV, but 2FA is widely available.
- And of course there are still many things can be done to avoid the “success” of this susceptibility utilization.
6.1. Sub title at point 2.5 was inspired ny one of the session that delivered by SensePost at BlackHat Asia 2014 with the different topic. Nice title!
VII. TIMING DETAIL OF THE VIDEO
For completing the explanation, we upload the newest video for our PoC at https://youtu.be/VS8QSxGVLXo.
In this simple report, we do give the specific explanation related the step that exist on those video:
- 00:00:00 – 00:00:05 = Trying to login with Attacker Account (circle) – Account has been Migrated;
- 00:00:07 – 00:00:12 = Trying to login with invalid password – Authorization Header has Syntax Error;
- 00:00:19 – 00:00:30 = Showing the decode result from base64 that consist of email address including the password that used by the Attacker;
- 00:00:33 – 00:00:50 = Change the Attacker’s email address to the victim’s email address and showing the valid password that used by victim. In this case, no cookies was changed from the previous one;
- 00:00:52 – 00:00:58 = Trying to login with victim’s account (yoko) – Account has been Migrated;
- 00:01:00 – 00:01:05 = Trying to login with invalid password to the victim’s account – Authorization Header has Syntax Error;
- 00:01:08 – 00:01:25 = Preparing the parameter that would like to be attack with Brute Force method. In this case is the content from the Authorization Parameter;
- 00:01:29 – 00:01:35 = Load the dictionary that consist of victim’s email address and the list of password that converted to base64;
- 00:01:38 – 00:01:46 = Showing the password is invalid. In this case is pass8;
- 00:02:30 – 00:02:49 = Stopping the Attacker because the previous dictionary automatically encode the ‘=’ character to %3D. In this part, we re-launch the attack without encode the ‘=’ character;
- 00:02:53 – 00:10:18 = Doing the brute force attack with 1.000 attempts in less than 8 minutes;
- 00:11:03 – finish = Trying to login to Microsoft Service Account via https://login.live.com/. In this case, an Attacker success to login into the victim’s account without get any blocked (after 1.000 attempts?).
Download the paper directly from here: