google cloud messaging security
Asked Answered
A

7

11

Company creates a project and receives a sender ID. Company creates an app, bakes in its sender ID and places the app in the store.

Attacker reverse engineers the app and extracts both the sender ID and the server interface used to receive GCM registration IDs.

Attacker creates his own app, bakes in Company's sender ID and server registration interface, puts app in the store. The attack app basically impersonates Company's real app as far as GCM goes: it registers to receive messages from Company's sender ID and then sends its GCM registration ID to Company's servers just like the "real" app does.

Now Company wants to broadcast some information to all instances of its app. Maybe it's a reminder than an update is available. Is there any way to differentiate the "attack app" (which registered just like the real one) from "real" versions of the Company's app?

Airhead answered 5/7, 2012 at 21:7 Comment(1)
Nice question but probably OT here.Tobey
C
1

The same problem could also have existed with C2DM, which you can sniff the sender email address, instead of project ID for GCM.

C2DM or GCM, should never be used to send sensitive user information (i.e. account name, private information, etc), it's mainly useful for notification, which the real app can use it to perform further actions.

I can't see how useful a notification can be to a 'fake/hack' app, what are they going to do with 'You have new message' notification?

Cards answered 6/7, 2012 at 3:24 Comment(1)
do you have any sources?Ampereturn
E
3

I think from your scenario it's not possible for the attacker to send a message to the user even if he has the registration id. The company server which sends the messages they need to authenticate (OAuth2) there account first through Google. So only if the attacker knows the password of the sending party and the registration id than it can send the user. But the password of the sending party of course is never send to the client side.

Etz answered 6/7, 2012 at 5:48 Comment(0)
W
2

well, this might even work in a debug version of the attackers app, but he can not put his app in the store. part of the GCM identification is the app id which needs to be unique in the store.

War answered 5/7, 2012 at 21:14 Comment(0)
C
1

The same problem could also have existed with C2DM, which you can sniff the sender email address, instead of project ID for GCM.

C2DM or GCM, should never be used to send sensitive user information (i.e. account name, private information, etc), it's mainly useful for notification, which the real app can use it to perform further actions.

I can't see how useful a notification can be to a 'fake/hack' app, what are they going to do with 'You have new message' notification?

Cards answered 6/7, 2012 at 3:24 Comment(1)
do you have any sources?Ampereturn
A
1

The GCM Registration ID is requested by Google, requested from the app and submitted to your server. When someone with a different app (but the same sender ID) creates a Regid, it still has to be committed to the server, and you first have to explicitly send a message to that specific regid.

An app installation, whether legitimate or not, can never receive messages it is not authorised for. (Provided you declare and use the C2D_MESSAGE permission)

Apollinaire answered 2/12, 2012 at 21:33 Comment(0)
P
0

Actually, google let's you register a Server Key for GCM, which lets you White-List Server IP's... So you should add your server IP and you would be safe, since only your server is allowed to send messages with that key.

Pica answered 31/3, 2013 at 3:11 Comment(0)
F
0

GCM is safe in this case.
You even can't use your Sender ID in your original app before you register the app in GoogleApiConsole. This means you point private key fingerprint in GoogleApiConsole. It's enough.

File answered 4/12, 2013 at 10:9 Comment(0)
S
0

I would suggest having your own "interim server" which uses the API key (sender ID as you referred to it). Instead of embedding it in the app itself.

Subulate answered 12/8, 2015 at 18:12 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.