Jul 282017
 

Mail.ru logo1.) Introduction

Of course you could say: “If you’re going to use Russian software, that’s what you’d have to expect!”. But yeah. I’ve actually used tools written by Russian developers before, and they used to be very slim and fast, so I thought, why not give it a shot. Background is that I’ve finally ditched my ancient Nokia E72 “smart phone” based on Symbian 9.2 / S60 3rd, which has become almost unusable because of its lack of modern SSL ciphers (most websites won’t let you connect anymore) and because of its Skype and ICQ clients being banned from their respective servers.

So I finally went ahead and got myself an Android 7.1.1 device, the Blackberry KEYone, my second attempt at using the OS (first was a Motorola Milestone 2 with Android 2.1, a failure because of many reasons).

Anyway, I had to find an eMail app that would let me do two things:

  1. Display and send everything as plain text (I hate HTML mails and find them pretty insulting to be honest)
  2. Allow me to connect to mail servers which support only older SSL/TLS protocols and ciphers (I’ve got no choice here)

2.) The Mail.ru email client on Android

2a.) The app itself

So, I tested a lot of clients, one of which was [Mail.ru], a pretty high-ranked email app (4.6/5) with more than 10 million installs out there. Superficially, it looks just like pretty much any other email client, because there are likely readily available Android libraries for implementing email clients:

Mail.ru client ad

An image directly from the Google play store, showing the apps’ GUI (click to enlarge)

So they advertise it with slogans like “ideal application for any mail” and “add all your email boxes in one application”. Actually, it’s ideal for just one thing: To hand over all your email accounts and emails to a Russian company and with it the Russian government – because in Russia, companies have to yield to the government and grant it full access to user accounts and data by default.

I guess free Russian developers and actual Russian software companies have to be treated very differently!

What I did was to enter my own email account credentials in the Mail.ru app to be able to fetch my emails via IMAP. I found that the client does not meet my personal requirements (no way to force plain text email), so after my quick test, I just uninstalled the app.

2b.) What the app does without you noticing

However, by that time, the Mail.ru app had already leaked my account credentials to certain mail.ru and my.com servers (my.com is a part of the bigger Mail.ru group), which had now started to log into my account from Russia – periodically checking all my email boxes and downloading every single message stored on my own server. Let’s have a look at the logs!

Here is their first connection attempt, coming from 5.61.237.44 (sapif30.m.smailru.net) as well as the second one from 94.100.185.215 (rimap21.i.mail.ru):

Tue 2017-07-25 14:59:27: Session 5554; child 3; thread 1232
Tue 2017-07-25 14:59:26: Accepting IMAP connection from [5.61.237.44:42273]
Tue 2017-07-25 14:59:27: SSL negotiation successful (♡)
Tue 2017-07-25 14:59:27: --> * OK ♡ IMAP4rev1 ♡ ready
Tue 2017-07-25 14:59:27:  1 OK LOGIN completed
Tue 2017-07-25 14:59:27:  1 OK LIST completed
Tue 2017-07-25 14:59:27:  * BYE IMAP engine signing off (no errors)
Tue 2017-07-25 14:59:27: --> . OK LOGOUT completed
Tue 2017-07-25 14:59:27: IMAP session complete, (2654 bytes)
Tue 2017-07-25 14:59:27: ----------
Tue 2017-07-25 15:00:04: ---------- Partial transcript, remainder will follow.
Tue 2017-07-25 15:00:04: Session 5556; child 4; thread 3588
Tue 2017-07-25 14:59:28: Accepting IMAP connection from [94.100.185.215:53424]
Tue 2017-07-25 14:59:28: SSL negotiation successful (♡)
Tue 2017-07-25 14:59:28: --> * OK ♡ IMAP4rev1 ♡ ready
Tue 2017-07-25 14:59:28:  1 OK LOGIN completed
Tue 2017-07-25 14:59:28:  * CAPABILITY ♡
Tue 2017-07-25 14:59:28: --> 2 OK CAPABILITY completed

You might have guessed it, the ♡ marks things I cut from the logs for privacy reasons. Guess I got a bit too creative. ;) Anyway, this was only the beginning. Later, some mail collector servers from the IP range 185.30.17*.** (collector*.my.com) started to log in and download all my emails from all my folders! Here’s just a small excerpt from the commands issued with one of my archive folders serving as an example – most of the stuff has been cut out to make it more concise:

Tue 2017-07-25 14:59:29: <-- 3 LIST "" "*"
Tue 2017-07-25 14:59:31: <-- 23 FETCH 22:* (UID FLAGS)
Tue 2017-07-25 14:59:52: <-- 49 STATUS "Archives" (UIDNEXT MESSAGES UNSEEN UIDVALIDITY)
Tue 2017-07-25 14:59:52: <-- 49 STATUS "Archives" (UIDNEXT MESSAGES UNSEEN UIDVALIDITY)
Tue 2017-07-25 14:59:53: <-- 50 STATUS "Archives/2013" (UIDNEXT MESSAGES UNSEEN UIDVALIDITY)
Tue 2017-07-25 14:59:53: <-- 51 SELECT "Archives/2013"
Tue 2017-07-25 14:59:53: <-- 52 FETCH 1:* (UID FLAGS)
Tue 2017-07-25 14:59:53: <-- 53 UID FETCH 7 (RFC822.SIZE BODY.PEEK[] INTERNALDATE)

All of those are just the remote commands issued to my server. Note that in IMAP4, UID FETCH <UID> BODY.PEEK[] at the bottom is an actual message download. Needless to say, there were thousands of those going unchecked, because it took me 3 days to discover the leak. And I only discovered it coincidentally too. So by that time they had long downloaded all my emails from my own server to Russia. If you're not running your own mail server, you wouldn't even notice this.

So if you just happened to enter your AOL, Yahoo, gmail or Hotmail accounts, you'd never see those Russian servers accessing those accounts remotely!

3.) This can't be ok, can it?

This behavior is completely unacceptable and has been reported to Google as it is borderline regarding Googles' own privacy policy:

Privacy Policy & Secure Transmission

If your app handles personal or sensitive user data (including personally identifiable information, financial and payment information, authentication information, phonebook or contact data, microphone and camera sensor data, and sensitive device data) then your app must:

  • Post a privacy policy in both the designated field in the Play Console and from within the Play distributed app itself.
  • Handle the user data securely, including transmitting it using modern cryptography (for example, over HTTPS).

 

The privacy policy must, together with any in-app disclosures, comprehensively disclose how your app collects, uses and shares user data, including the types of parties with whom it’s shared.

Prominent Disclosure Requirement

If your app collects and transmits personal or sensitive user data unrelated to functionality described prominently in the app’s listing on Google Play or in the app interface, then prior to the collection and transmission, it must prominently highlight how the user data will be used and have the user provide affirmative consent for such use.

First of all, the mail collectors drop down to cryptographic ciphers even I wouldn't use anymore when asked to do so. I mean, it sounds hypocritical coming from me (because I'm actually using very old ciphers too, as I'm out of options on my ancient server), but they do fall back to what's by no means "modern cryptography". Also, the leaking of account credentials and data to Russian servers and the continuous use of said data even after the user has stopped using Mail.ru services is not mentioned anywhere while installing or using the app, not that I could see at least.

I most definitely didn't give my consent to having the app use my data like this - I wasn't presented with an EULA during the installation or use of the software. Also, the (Russian...) email they had sent me after accounts were set up in the app didn't show an EULA or privacy statement either. It's even worse considering [Mail.ru's history] in terms of handling that information.

None of this is new either, see e.g. [this Reddit] (MyMail is from my.com - as said, a part of the Mail.ru Group).

Well, I started to look around and found a Mail.ru [user agreement] online. The interesting part is point 4.1.3:

4.1.3 In addition to the registration procedure on the Internet Service specified in clause 4.1. the user may be granted the right to register through using its data (login and password) of the e-mail box registered at the third person’s resource.

Irrespective of using any method of registration on the Internet Service the User’s password used to visit the Internet Service shall be beyond the reach of Mail.Ru.

Now that part is a bit problematic. The "third person's resource" is clearly your own mail account on some other server. So like my email account on my own server. The question is, what exactly does it mean when they say that the users' password shall be "beyond the reach of Mail.Ru"? Guess they'd mean my actual plain text password, right?

Well, no matter if they use hashes with <-- 2 authenticate CRAM-MD5, or instead just plain text <-- 1 LOGIN ♡@♡.♡ ♡♡♡♡♡♡, they do have my password stored away on their servers as clear text (probably on some encrypted file system? But still.). I wouldn't call that "beyond the reach of Mail.ru" anymore.

I guess I could have misread the user agreement (that I wasn't even presented with!) somewhere, but it doesn't seem to me as if they'd be following their own rules regarding privacy?!

If you're using the Mail.ru app I can only advise you uninstall it if you haven't done so already and to change all account passwords ever entered in the application to stop the Russian collector servers from logging into your accounts and "stealing" your email even after app deinstallation.

On a side note: Since K-9 Mail isn't exactly right for me either, I settled with [R2Mail2], which is being developed in Austria by the company [RundQuadrat]. I've been talking with its developer over the last few days, and he seems a like a nice family guy. I do like the client, as it has an impressive feature list, let's just name a few:

  • Manually configurable SSL/TLS cipher list, you can pick which ciphers you want or don't want to use, including the option to support a few deprecated ciphers.
  • Data oriented encryption with either S/MIME, or even PGP and PGP/MIME for emails and also arbitrary files (a small tool for file encryption is embedded in the client).
  • Support for Microsoft Exchange servers
  • Option to stop syncing in the background, so a full shutdown of the app is possible with ease.
  • Full plain text support, so you can force all messages to be displayed and sent in plain text only.
  • The client itself can be password protected and can be instructed to store all local data in encrypted form.
  • Extremely configurable: Reply/Forward Prefixes, host name use in EHLO command, notification LED color ( :roll: ), IPv4/IPv6 preference, Certificate store access & configuration, peak day/time option to boost synchronization, sync grouping with other apps to save battery, local email pruning and many, many other things.

It does come at a price though, as it costs 4.80€. But if you want a seriously powerful and I'd say more trustworthy email application for Android, you might give this a shot. Otherwise, maybe just go with the free K-9 mail app if you want plain text and don't need to rely on mail servers with antiquated SSL/TLS implementations.

But no matter what, stay away from Mail.ru and MyMail!

May 152014
 

Important Edit: I have decided to host updates for Windows XP Professional x64 Edition starting now. The updates will be hacked where necessary to work smoothly on XP x64, unmodified updates will also be re-hosted! You can find them all in a page pinned to the weblog on the top right, [here is the link]!

XP Hex hackingOk, so we all know that besides those “Malicious Software Removal” updates and that fancy [Internet Explorer hotfix], XP is and will stay dead in the water, when it comes to Microsofts support for patches, right? That might be true for Windows XP 32-Bit, but what if I told you that there is a real way to keep XP x64 alive and secure all the way until July 2015? Since the newer XP x64 shares a large code base with Windows Server 2003 (which keeps being supported until 2015-07-14), the logical thing would’ve been to just try out those updates where applicable. It ain’t all so easy though…

Install error

Trying to install the update for [KB2926765] succeeds on Server 2003, but fails on XP x64!

This update actually replaces the 32-Bit and 64-Bit versions of shlwapi.dll, which exists on both operating systems in the same version. So what’s going on? We can find the solution by unpacking the update file WindowsServer2003-KB2926765-x64-ENU.exe with 7zip or WinRAR. Inside you’ll find an update/ folder and in it, the file update_SP2QFE.inf.

When opened, the culprit can be found at the very end of the file:

[Prereq.XPAMDInstallBlock.Section]
    PresentOp=CheckReg,HKLM,"SYSTEM\CurrentControlSet\Control\ProductOptions",ProductType,0x00000000
    NotEqualOp=CheckReg,HKLM,"SYSTEM\CurrentControlSet\Control\ProductOptions",ProductType,0x00000000,!=,"WinNT"
    Display_String="%WrongProductMessage%"

When you open the registry editor and check those keys, you’ll find that “WinNT” string. And that means, that the prerequisites of the installer update.exe in the same folder are not met. And that’s the updater launched for the actual installation. So then, just edit the INF and install? Yeah, that’s what I thought. Forget about it right away! Each update comes with a catalog file – KB2926765.CAT in this case – which amongst other files holds cryptographic signatures of the INF files included. Change one of those INF files and it’s this one for you:

INF modification doesn't work

INF modification doesn’t work!

So then I found [this guy right here], who seems to be some serious Windows hacker. Like SERIOUS serious. I thought that hacking update.exe would be the next step, so I fired up the IDA disassembler and tried my luck together with my trusted old XVI32 hex editor to try and duplicate this guys hack to cancel out the INF file verification code:

So the assembly patch would generate hexadecimal binary opcodes (the instructions mov eax, 1 and retn 4 were added), which I then tried to enter into the file at the proper offset with a hex editor. Now I am no software reverse engineer and my x86 assembly is rusty, x86_64 non-existant. In the end, this failed miserably. The x86_64 code differs greatly from the x86_32 one shown at the blog post linked to above, so I was unable to port the solution over. It’s definitely possible, but it’s also a bit over my head.

And then I found a guy called 5eraph, who [assembles updates for Windows XP Pro x64 Edition] on RyanVMs forums, and his collection is still being maintained. In more recent times he had decided to include updates that were blocked on XP x64, especially since the end of Windows XP support. According to him, some of the updates showed clear signs of having been targetted at XP x64 just as well (you can find the signs if looking through all the INFs), if it wasn’t for the added crap in the update_SP2QFE.inf file and its siblings found in other Windows updates.

But he found a way. And again, the way was to patch update.exe. [See here]! Now I don’t know how this hack was developed, but basically you just need to edit a few strings with a hex editor. Here is the table with offsets as well as old values and new values in hexadecimal:

00016A90: 50 44 
00016A91: 72 75 
00016A92: 65 6D 
00016A93: 52 6D 
00016A94: 65 79 
00016A95: 71 53 
00016A96: 75 65 
00016A97: 69 63 
00016A98: 73 74 
00016A9A: 74 6F 
00016A9B: 65 6E 
00016AA0: 50 44 
00016AA2: 72 75 
00016AA4: 65 6D 
00016AA6: 52 6D 
00016AA8: 65 79 
00016AAA: 71 53 
00016AAC: 75 65 
00016AAE: 69 63 
00016AB0: 73 74 
00016AB4: 74 6F 
00016AB6: 65 6E

And what’s it look like when viewed in a hex editor? Let’s check it out in XVI32, stock version and modified version, the fields from the list have been marked in red to make it more clear. Just jump to offset 0x00016A90 and start editing:

So all you need to do is to change the data to some bogus crap, that exists nowhere else. You need to be very careful though, touch one wrong byte and the file will be damaged and will crash or behave erratically when launched. If everything has been done right, just launch the new, modified update.exe and something like this should greet you:

And just to verify that it actually did what it should, a quick version compare of the patched file shlwapi.dll in %WINDIR%\system32\ before installation and after installation & reboot is enough:

So, as I had hoped, it is indeed possible to refactor Server 2003 x64 updates for XP x64, even now where Microsoft is actively trying to block out the operating system from its updates. Now, not all updates will require this, as [reported by Sjaak Trekhaak] and confirmed by me. But those which do can be fixed!

Unless Microsoft finds some new way to harass what few XP x64 users remain, this is the way to go. It would be necessary to filter the updates though, as real Windows Server 2003 systems do feature components that XP x64 does not have, like an Active Directory LDAP server for instance. So a user would need to check this out on his own, or just rely on 5eraphs update pack of course. While I do prefer do pull this off myself, using 5eraphs stuff is much easier of course, no hex editing on your own, so you might wanna go with that instead.

And I do have bad news too after all. I can’t prove it, but due to the code base itself, it is highly likely that none of this works with Windows XP Pro x86 / 32-Bit…

In any case, Windows XP Professional x64 Edition lives on! The final battle ain’t over yet!

Thanks and greets fly out to 5eraph for his great XP x64 support, to RyanVM for hosting that cool forum and to [Remko Weijnen] for his elite hacking skills!

May 302013
 

Hack logoTonight at around 10:30PM, XIN.at came under attack by what I assume to be a larger bot network. As a result, all CPU-intensive web applications on my server, including this weblog, forums, CMS’ etc. went offline because of the attacks causing excessive PHP CPU cycle usage and timeouts of all scripts. It seems the primary target of the attacks was this weblogs login page, but the largely inactive forum was also a target obviously. Log file analysis suggests, that this was a distributed brute force attack to break into XIN.at web services (and probably a few thousand other web services on other servers). The attacking hosts were many machines spread across multiple IP pools, so I have to assume that this is some major attack to break into multiple web services at once, for purposes currently not known to me.

Amusingly, the attack failed on this server while remaining in its infancy. As a security measure, runtime of PHP scripts is limited on this server. The attack was so massively parallelized, that it simply overloaded everything, causing all scripts to return HTTP 503 errors to almost all attacking hosts. In laymans terms: This server was simply too SLOW to allow the attackers scripts to ever succeed. I can only laugh about that simple fact. This server was just too old and crappy for this shit. ;)

Well, still, for that reason, this weblog and most of XIN.at’s web services went offline for around 2½ hours. For now, it is back online, and hopefully the brute force attacks have ceased by now, as my monitoring would suggest. We’ll see.

Feb 012012
 

Tux is dying. Sometimes.There has been a recent [security advisory] about a certain exploit, that affects most Linux Kernels v2.6.39-rc1 and newer, if they contained the upstream patch [198214a7]. The flaw came with a re-enabled mem_write() function and enhancements made to the handling of the /proc/pid/mem permission checks when writing to running programs memory via the facility. It is possible to use this to escalate a users privileges, supposedly all the way up to root. Now that alone is bad enough, but the enhancement has been back-ported by some distributors like RedHat, and hence has also hit CentOS and Scientific Linux even though their kernel versions are <2.6.39-rc1. By now there are kernel updates available to get the problem fixed. In the meantime, there is some sample code available to show wether your specific machine is vulnerable to this kind of /proc/pid/mem hijacking or not. See the source code:

expand/collapse source code
  1. /*
  2.   simple reproducer that tests whether we have commit 198214a7ee50375fa71a65e518341980cfd4b2f0 or not
  3.  */
  4.  
  5. #define _LARGEFILE64_SOURCE
  6. #include &lt;stdio.h&gt;
  7. #include &lt;stdlib.h&gt;
  8. #include &lt;sys/types.h&gt;
  9. #include &lt;sys/stat.h&gt;
  10. #include &lt;fcntl.h&gt;
  11. #include &lt;unistd.h&gt;
  12.  
  13. char *s = "not vulnerable";
  14. char *s2 = "vulnerable";
  15.  
  16. int main(int argc, char **argv)
  17. {
  18.  
  19.   int fd;
  20.   loff_t r;
  21.  
  22.   fd = open("/proc/self/mem", O_RDWR);
  23.   if(fd &lt; 0) {
  24.     perror("open: ");
  25.     goto end;
  26.   }
  27.  
  28.   if(lseek64(fd, (off64_t) &amp;s, SEEK_SET) &lt; 0) {
  29.     perror("lsee64: ");
  30.     goto end;
  31.   }
  32.  
  33.   if(write(fd, &amp;s2, sizeof(s2)) &lt; 0) {
  34.     perror("write: ");
  35.   }
  36.  
  37. end:
  38.   close(fd);
  39.   printf("%s\n", s);
  40. }

You can compile and test the code with GCC:

$ gcc test.c -o test
$ ./test

In case your system is vulnerable, the code will just output “vulnerable”, otherwise it will say “write: : Invalid argument” and “not vulnerable”. In that case your kernel is either too old to have the enhancement or has been fixed already. If your system is vulnerable, updating your Kernel to a fixed version or even downgrading in case there is none available for your distribution is highly recommended.