• IM+ Raises Security Concerns (Updated)

August 29, 2008 – 10:31 am

Following my first look at IM+, I got an interesting email from Scott A. McIntyre, security officer for XS4ALL.  Scott took the time to analyze the packets that IM+ sends over air to verify my assumption that no proxying was involved.  He found that some proxying is taking place, and some very strange things are happening with SHAPE servers.  

The original email with his analysis is after the jump.  Meanwhile, I have asked IM+ developer SHAPE Services for a comment.  I’m willing to accept that they’re simply doing something stupid rather than something evil.

Update - SHAPE Services has responded to the story with some clarification.  Their email is below, after Scott’s, but the bottom line is that IM+ does use proxy servers, which SHAPE claims are on the up-and-up.

Update 2 - Another round of emails from SHAPE.  This time, on the issue of logging.  The good news is that they say no customer chats or login information are logged.  Everything else is for support purposes, and they claim to have a solid security record.

The willingness of SHAPE Services to quickly address these concerns and set the record straight says a lot; they could have ignored me entirely.  Clearly, their reputation has value to them, even if the application itself is free.  Their one true mistake was not specifying the gateway/proxy functionality in the iTunes write-up.  A mistake that they tell me will likely be fixed next week.

My hope is that you’ll take all of the information into account when making a judgement about this application.  The existence of a security analysis is not itself an indictment of IM+.  This is simply the system at work.

Dave,

As soon as IM+ was released I analysed the network traffic and came to the conclusion that in fact it is doing proxying, just in a different way, and worse, it looks potentially primed to share sensitive data with the company that makes IM+.

From actual network captures performed yesterday:

The app looks up some host in Germany, which is the “gateway” for the company that makes the client.  When it connects, it sends:

0×0030:  3b90 f309 fe00 4741 736b 4761 7465 4f70  ;…..GAskGateOp
0×0040:  7420 6c63 6b65 7928 2920 6272 2849 5048  t.lckey().br(IPH
0×0050:  4f4e 4529 2076 6572 2831 2e30 2920 696d  ONE).ver(1.0).im
0×0060:  6569 2831 3131 3131 3131 3131 3131 3131  ei(1111111111111
0×0070:  3131 2920 7264 7228 6661 6c73 6529       11).rdr(false)

Okay, so, this release doesn’t send your IMEI, but there’s certainly nothing stopping a future version doing it!

This seems to be a form of license check.  It would send your IMEI to the company, which checks to see that you have a valid license.  They sell this client for other devices, it’s free for iPhone.

This generates a unique ID:

0×0030:  1a7a 70d2 0023 4964 2069 6e73 7428 3441  .zp..#Id.inst(4A
0×0040:  4245 3242 3437 4236 3237 5f44 3737 3746  BE2B47B627_D777F
0×0050:  3737 4238 4141 3529 0a                   77B8AA5).

Which if it did an actual comparison would probably activate the client on non iPhones.

As an ACK to the license being installed, the iPhone sends:

0×0030:  3b90 f325 fe00 5c49 6420 696e 7374 2834  ;..%..\Id.inst(4
0×0040:  4142 4532 4234 3742 3632 375f 4437 3737  ABE2B47B627_D777
0×0050:  4637 3742 3841 4135 2920 696d 6569 2831  F77B8AA5).imei(1
0×0060:  3131 3131 3131 3131 3131 3131 3131 2920  11111111111111).
0×0070:  7264 7228 6661 6c73 6529 2070 7274 636c  rdr(false).prtcl
0×0080:  2832 3030 2920 6376 6572 7369 6f6e 2831  (200).cversion(1
0×0090:  2e30 29                                  .0)

Which is essentially the “login” to the system as well.  This generates the response of:

0×0030:  1a7a 70d3 0020 5264 7220 6970 2837 302e  .zp…Rdr.ip(70.
0×0040:  3338 2e32 342e 3137 2920 706f 7274 2833  38.24.17).port(3
0×0050:  3030 3030 290a                           0000).

HELLO…

AS      | IP               | AS Name
32613   | 70.38.24.17      | IWEB-AS – Groupe iWeb Technologies inc.

Some Canadian hoster which I am pretty darn certain is NOT America Online.  If you look for login.oscar.aol.com, you’ll get an IP like:

AS      | IP               | AS Name
1668    | 205.188.179.233  | AOL-ATDN – AOL Transit Data Network

But that may vary depending on various factors.  No matter what, this is not AOL though.

From there, the iPhone connects to the iWeb site, offering the same “here is my ID and IMEI” authentication check, which causes the second server to generate a list of services supported:

0×0030:  1a7a 7230 012a 4964 2073 6964 2837 3235  .zr0.*Id.sid(725
0×0040:  3932 2d38 3631 3731 290a 5472 616e 7370  92-86171).Transp
0×0050:  2074 7228 4929 2064 6573 6328 4943 5129  .tr(I).desc(ICQ)
0×0060:  0a54 7261 6e73 7020 7472 2841 2920 6465  .Transp.tr(A).de
0×0070:  7363 2841 4f4c 290a 5472 616e 7370 2074  sc(AOL).Transp.t
0×0080:  7228 4d29 2064 6573 6328 4d53 4e29 0a54  r(M).desc(MSN).T
0×0090:  7261 6e73 7020 7472 2859 2920 6465 7363  ransp.tr(Y).desc
0×00a0:  2859 6168 6f6f 290a 5472 616e 7370 2074  (Yahoo).Transp.t
0×00b0:  7228 4a29 2064 6573 6328 4a61 6262 6572  r(J).desc(Jabber
0×00c0:  290a 5472 616e 7370 2074 7228 4729 2064  ).Transp.tr(G).d
0×00d0:  6573 6328 476f 6f67 6c65 2054 616c 6b29  esc(Google.Talk)
0×00e0:  0a54 7261 6e73 7020 7472 2850 2920 6465  .Transp.tr(P).de
0×00f0:  7363 284d 7953 7061 6365 290a 5472 616e  sc(MySpace).Tran
0×0100:  7370 2074 7228 5429 2064 6573 6328 5472  sp.tr(T).desc(Tr
0×0110:  616e 736c 6174 6f72 2920 6973 626f 7428  anslator).isbot(
0×0120:  7472 7565 290a 5472 616e 7370 2074 7228  true).Transp.tr(
0×0130:  5a29 2064 6573 6328 534d 532b 2920 6973  Z).desc(SMS+).is
0×0140:  626f 7428 7472 7565 2920 6372 6564 6974  bot(true).credit
0×0150:  7328 2d31 2920 656e 6428 7472 7565 290a  s(-1).end(true).

Quite interesting.  It looks like the system is meant to dynamically update the protocols supported on the fly.

Keeping in mind that all of this is to the Canadian site, the next few packets are the interesting ones:

0×0030:  33ad f3cc fe00 404c 6f67 696e 2074 7228  3…..@Login.tr(
0×0040:  4129 206c 676e 2849 6d70 756c 7374 6573  A).lgn(Impulstes
0×0050:  7465 7234 2920 7077 6428 3030 3433 3030  ter4).pwd(004300
0×0060:  3537 3030 3436 3030 3444 3030 3537 3030  570046004D005700
0×0070:  3546 3030 3043 29                        5F000C)

The gateway server takes the (A) style login data (AOL), the username, and some encoded password, and then passes the data on to AOL.

So it effectively operates just like Palingro or the other proxying servers, using your IMEI & license (if you have one) as your authentication credential to the German IM+ system and proxies your connections on from there.

In my opinion, this is even worse than Palingro/etc as it appears to be a direct connection when it definitely is not.

Regards,

Scott

The response from SHAPE:

Dear Dave,  

Thank you for the attention to our service.
Below is the answer from our developers, please pass it to Scott from XS4ALL.

We feel very sorry if the information in IM+ or on our websites was
misleading in any way. All our IM+ implementations, except versions
for Symbian and Windows Mobile devices, are connecting to IM services
through the gateways, developed by us and hosted in Europe and North
America. Even though we might also implement direct connection for
iPhone version, like for Symbian and Windows Mobile, our experience
shows it is by far not the best approach regarding service
reliability, upgrade capabilities and features. That’s why we’ve
implemented the gateway-based approach, like we (and all other mobile
IM vendors) do on other platforms.

SHAPE Services is developing mobile IM clients since 2003 and we
believe there’s no way we can be suspected in any illegal or dangerous
activities.

We’d be happy to see your suggestions on how can we avoid such
misunderstanding among other IM+ for iPhone users. 

In case you have any additional questions, feel free to send them to me or to Alex Makarov, Head of Development at SHAPE (CCd).

Thank you in advance.
Maria Dyatlova
Alliance Manager
SHAPE Services

Followup from SHAPE:

No conversations, credentials or other personal data is stored on the gateways. Credentials are only used once per each login procedure, and are not stored anywhere. Messages are passed through the gateways and are also not stored or logged. We only keep registration-related information (that is, license keys) and some non-personal information for statistics, such as device model, IMEIs, connection method to provide better support etc. This system is in use for more than four years and we had no complains about any security breaches.

For closed environments where conversation logging is mandatory we provide dedicated gateways setup with support of commercially available IM archiving services.