myMail Manages Your Mailbox… in a Strange Way!

myMail is a popular (10M+ downloads!) alternative email client for mobile devices. Available for iOS and Android, it is a powerful email client compatible with most of the mail providers (POP3/IMAP, Gmail, Yahoo!, Outlook, and even ActiveSync). Recently, I was involved in an incident that was related to a malicious usage of myMail. I had a closer look at the application, how it works and found something weird…

[Note: I tested the Android version of this app, iOS was not tested and I don’t know if it behaves in the same way]

I installed the version 6.4.0.24788 on an lab Android device. This device is configured to use a BurpSuite instance to log and inspect all the HTTP traffic. As usual, for the Android ecosystem, many permissions are requested by the application, besides the classic one (access to contacts, Internet, storage, …), those ones look more suspicious:

android.permission.REQUEST_INSTALL_PACKAGESAllows an application to request installing packages.
android.permission.WRITE_CONTACTSAllows an application to change contacts

Once you installed the application on your device, it’s time for the basic configuration. This is a pretty straightforward process: You enter your credentials (email address + password) and the application takes care of everything for you (if your email platform supports autodiscovery services).

Now that you entered your email and password, you can consider them as lost because myMail will send them to the backend architecture:

GET /cgi-bin/auth?Password=XXXXXXXX&mobile=1&mob_json=1&simple=1&useragent=android&Login=johndoe%40pwn3d.be&Lang=en_GB&mp=android&mmp=mail&DeviceID=9ff695be583a7eb72048dbe5e321189a&client=mobile&DeviceInfo=%7B%22playservices%22%3A%2211400000%22%2C%22Timezone%22%3A%22%2B0100%22%2C%22OS%22%3A%22Android%22%2C%22DeviceName%22%3A%22samsung%20GT-S7275R%22%2C%22Device%22%3A%22GT-S7275R%22%2C%22AppVersion%22%3A%22com.my.mail6.4.0.24788%22%7D&idfa=f70118e8-2e56-4e75-aa3e-8ab003c1ce24&appsflyerid=1613031754648-6863156579261663340&current=google&first=google&md5_signature=be20216f2b3114b37c3c6a6977d04f89 HTTP/1.1
User-Agent: mobmail android 6.4.0.24788 com.my.mail
Host: aj-https[.]my[.]com
Connection: close
Accept-Encoding: gzip, deflate

Indeed, the application does not talk directly to your mail server but uses the my.com cloud infrastructure to take care of all email-related communications. The mobile app is just a client for the API and all traffic happens over HTTPS. This technique is used to provide the “push services”:

Once configured, the app will poll the myMail cloud for messages:

GET /api/v1/messages/status?prefetch=1&sort=%7B%22type%22%3A%22id%22%2C%20%22order%22%3A%22desc%22%7D&snippet_limit=183&last_modified=1613681670&folder=0&offset=0&limit=20&email=johndoe%40pwn3d.be&token=1600745569219451055721945105573116678049%3A510f584c63015605190504070904050007020a01040003000406010403000000040200090c0d06030006030102090403XXXXXXXXXXXXXXXX&htmlencoded=false&mp=android&mmp=mail&DeviceID=9ff695be583a7eb72048dbe5e321189a&client=mobile&playservices=11400000&os=Android&os_version=4.2.2&ver=com.my.mail6.4.0.24788&vendor=samsung&model=GT-S7275R&device_type=Smartphone&country=GB&language=en_GB&timezone=%2B0100&device_name=samsung%20GT-S7275R&idfa=f70118e8-2e56-4e75-aa3e-8ab003c1ce24&device_year=2011&connection_class=MODERATE&current=google&first=google&appsflyerid=1613031754648-6863156579261663340&reqmode=fg&ExperimentID=Experiment_simple_signin&isExperiment=false&md5_signature=e29d6417e6ab8e90eabab6bdc5096c9e HTTP/1.1
Accept-Encoding: gzip, deflate
User-Agent: mobmail android 6.4.0.24788 com.my.mail
Cookie: Mpop=1613681611:510f584c630156051905000017031f051c054f6c5150445e05190401041d5b56585955565c19XXXXXXXXXXXXXXXX:johndoe@pwn3d.be:;domain=my.com
Host: aj-https[.]my[.]com
Connection: close

Because all the traffic is passing through the cloud, your attached files are also stored on their infrastructure. Here is an example of file download:

GET /cgi-bin/readmsg/cacert.cer?rid=354637854942502553472181455302888008800&&id=16130393950000000005;0;0&notype=1&notype=1&mp=android&mmp=mail&DeviceID=9ff695be583a7eb72048dbe5e321189a&client=mobile&playservices=11400000&os=Android&os_version=4.2.2&ver=com.my.mail6.4.0.24788&vendor=samsung&model=GT-S7275R&device_type=Smartphone&country=GB&language=en_GB&timezone=%2B0100&device_name=samsung%20GT-S7275R&idfa=f70118e8-2e56-4e75-aa3e-8ab003c1ce24&device_year=2011&connection_class=MODERATE&current=google&first=google&appsflyerid=1613031754648-6863156579261663340&reqmode=bg&ExperimentID=Experiment_simple_signin&isExperiment=false&md5_signature=3b75207d6ed3ff58fbbf874a2f13bebb HTTP/1.1
Accept-Encoding: gzip, deflate
User-Agent: mobmail android 6.4.0.24788 com.my.mail
Cookie: Mpop=1613681611:510f584c630156051905000017031f051c054f6c5150445e05190401041d5b56585955565c19XXXXXXXXXXXXXXXX:johndoe@pwn3d.be:;domain=my.com
Host: af[.]attachmy[.]com
Connection: close

But the worst has to come…

Once I completed my investigations, I first un-configured my test account. Before, I performed a proper logout:

GET /cgi-bin/logout?mp=android&mmp=mail&DeviceID=9ff695be583a7eb72048dbe5e321189a&client=mobile&playservices=11400000&os=Android&os_version=4.2.2&ver=com.my.mail6.4.0.24788&vendor=samsung&model=GT-S7275R&device_type=Smartphone&country=GB&language=en_GB&timezone=%2B0100&device_name=samsung%20GT-S7275R&idfa=f70118e8-2e56-4e75-aa3e-8ab003c1ce24&device_year=2011&connection_class=GOOD&current=google&first=google&appsflyerid=1613031754648-6863156579261663340&reqmode=fg&ExperimentID=Experiment_simple_signin&isExperiment=false&md5_signature=11f4aa0e644d79f8cadfb4aa0cd3b2e5 HTTP/1.1
Accept-Encoding: gzip, deflate
User-Agent: mobmail android 6.4.0.24788 com.my.mail
Cookie: Mpop=1613681611:510f584c630156051905000017031f051c054f6c5150445e05190401041d5b56585955565c195XXXXXXXXXXXXXXXX:johndoe@pwn3d.be:
Host: aj-https[.]my[.]com
Connection: close

While checking my mail server logs later, I saw this:

Feb 18 21:27:48 marge dovecot: imap-login: Login: user=, method=PLAIN, rip=185.30.176.168, lip=192.168.255.13, mpid=5140, TLS, session=<0JtFK6K7+7C5HrCo>
Feb 18 21:27:49 marge dovecot: imap(johndoe): Logged out in=275 out=1145

The my.com cloud infrastructure is still connecting to the mail account at regular intervals! Connections are coming from two /24:

  • 185.30.176.0/24
  • 185.30.177.0/24

The next step was to kill the app still running on the phone (but unconfigured). Same effect, polling was (and is still now) ongoing.

Once authenticated, my.com keeps a session with the mail server to fetch new emails. In my lab, it was a simple IMAP server:

root@marge:/var/tmp# net stat -anp |egrep "185\.30\.[76]*"
tcp 0 0 192.168.255.13:993 185.30.177.72:32735 ESTABLISHED 27234/dovecot/imap-

Let’s switch our cap now and try to think like an attacker. myMail can also be very interesting because you can test credentials belonging to your target without any connection directly from your network/devices! The application can be used as a “proxy”. In the case I was involved, one of the user who was detected as a myMail user never installed the application! This is perfect to monitor / steal data from your victim’s mailbox which leaving artefacts.

Conclusion: from a user’s experience, myMail is a nice application to handle multiple mailboxes, especially when you don’t have a built-in push notification service but, if you use it in a corporate environment, you should keep in mind that they have ALL your data in their hands! By the way, my.com is an international subsidiary of mail.ru, which provides the well-known mail service with the same name. The application code is also full of Java classes like “ru/mail/mailapp/DTOConfigurationImpl.java” with references to mail.ru URLs:

  • hxxps://e[.]mail[.]ru/fines/documents?openStatus=1
  • hxxps://clicker[.]bk[.]ru/api/v1/clickerproxy/mobile https://aj
  • hxxps.mail[.]ru/api/v1/gibdd/gmap
  • hxxps://help[.]mail[.]ru/mail/account/login/qr#noaccount
  • hxxps://account[.]mail[.]ru/login?opener=androidapp
  • hxxps://e[.]mail[.]ru/payment/center
  • hxxps://m[.]calendar[.]mail.ru/
  • hxxps://touch[.]calendar[.]mail.ru/
  • hxxps://touch[.]calendar[.]mail[.]ru/create
  • hxxps://todo[.]mail[.]ru/?source=webview
  • hxxps://todo.mail.ru/?source=superapp
  • hxxps://iframe[.]imgsmail[.]ru/pkgs/amp.viewer/2.3.1/iframe.html
  • hxxps://amproxy[.]imgsmail[.]ru/ hxxps://help[.]mail[.]ru/mailhelp/bonus/offline/ua?utm_source=mail_app& utm_medium=android
  • hxxps://help[.]mail[.]ru/mail-help/bonus/offline/support?utm_source=mail_ app&utm_medium=android

5 comments

  1. Thank you for the post. We spotted same credential caching behavior with Nine for iOS. I contacted the company behind this email client (9Folders https://www.9folders.com/en/index.html). They replied that it is mentioned in the privacy policy… However, no way to see the privacy policy without configuring the account… so entering your credentials and sending them to 9Folders cloud infra.

    And for Outlook, this behavior is documented here : https://docs.microsoft.com/en-us/exchange/clients/outlook-for-ios-and-android/passwords-and-security?view=exchserver-2019

  2. According to a colleague, yes it seems to be the same behaviour. But the question is, why do it keep the connection and polling once disconnected from the app!?

  3. Isn’t this the same thing Outlook Mobile did when it was rebranded from Acompli?

  4. Thank you very, very much!!
    This should be published on broadest effect.
    Kindly

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.