The Deception of Privacy in Telemedicine by Some Apps
or
HIPPA Be Damned
Overview:
Telemedicine is quite popular with this pandemic. We have even participated in setting up in setting up a couple of clinics. One of our core principals is the fact that we are huge on privacy. Now pretty much the majority of web uses some level of ad tracking for general website visits, and this is accepted. However, when it comes to patient data, at what point does one cross that line.
I subscribe to the old method, privacy is paramount. There is no middle ground, there is no interpretations and there are no excuses. Of course, we are in the minority of such thinking. The transmission of patient data, the storage of patient data, cannot nor should it be intermingled with Ads or treated insecurely. The same deference given to an inpatient meeting must be used in telemedicine.
The app analyzed below is from a company I was exposed to recently. I found it odd so I dug deeper, I cannot for legal reasons reveal the name of this company as I have no desire to be sued, nor do I wish to enter into a philosophical debate about privacy with them as I suspect I know where it will go. What I want you take from the below is not the code per say – put the plain language in it. Anyone can learn to read code if you try, look for what is called strings and with that plain language you can understand or have an idea of what is going on. In other words, look at the words and not the numbers.
Medical data is sanguine, it is sacred. As I like to say but most developers will disagree, if you are a building a house, you don’t put materials in the mix that are nonessential to the purpose of the functionality of that house. Same logic should go for your code.
Good reader I give you –
MD5: 7f0925681255b9664e8132d77550492a
SHA1: e7aa24e86c65da790feb33f91e1d4ce6ffa3b3c9
SHA256: 5e13ba145eb6b485a02e1a8c97cb87080a83f62f8b3feb06cbd1e1d54ce1de19
FYI – The above is the HASH IDs of the file.
Figure One:
android.permission.ACCESS_COARSE_LOCATION:
android.permission.ACCESS_NETWORK_STATE
android.permission.BROADCAST_STICKY
android.permission.GET_ACCOUNTS
android.permission.MODIFY_AUDIO_SETTINGS
android.permission.READ_EXTERNAL_STORAGE
android.permission.READ_PHONE_STATE
android.permission.RECORD_AUDIO
android.permission.USE_CREDENTIALS
android.permission.WRITE_EXTERNAL_STORAGE
The app in question request that you allow on your phone the above permissions. Now, as I mentioned previously lets take the techno jargon out of the discussion and bring this down to a level of basic common sense. The app is replacing a visit to the doctor's office including all correspondence which includes paperwork. The rule is simple, the same level of privacy and deference that is given to the patient in a conventional visit must be adhered to in the telemedicine session – so what does each one of these do:
- android.permission.ACCESS_COARSE_LOCATION : Allows an app to access approximate location.
- android.permission.ACCESS_NETWORK_STATE: Allows applications to access information about networks.
- android.permission.BLUETOOTH: Allows applications to connect to paired bluetooth devices.
- Android.permission.BROADCAST_STICKY: Allows an application to broadcast sticky intents. Let me explain what this means. If an Activity calls onPause with a normal broadcast, and this can be for a wide variety of reasons, receiving the Broadcast can be missed. A stick broadcast can be checked after it is initiated onResume because it sits in the cache. Problem here is that as of June of this year this was deprecated and should not be used.
- android.permission.CAMERA: Required to be able to access the camera device.
- android.permission.GET_ACCOUNTS: Allows access to the list of accounts in the Accounts Service.
- android.permission.INTERNET: Allows applications to open network sockets.
- android.permission.MODIFY_AUDIO_SETTINGS: Allows an application to modify global audio settings.
- android.permission.READ_EXTERNAL_STORAGE: Allows an application to read from external storage.
- android.permission.READ_PHONE_STATE: Allows read only access to phone state, including the current cellular network information, the status of any ongoing calls, and a list of any PhoneAccounts registered on the device.
- android.permission.RECORD_AUDIO: Allows an application to record audio.
- android.permission.USE_CREDENTIALS: Google got rid of this permission prior to Android 6.0, that means one the libraries being used by the APP is asking for this. This allows the application to request authentication tokens.
- android.permission.WRITE_EXTERNAL_STORAGE: Allows an application to write to external storage.
Some of these permissions are simply intrusive and it is obvious that the designer has not bothered to upgrade. One of those most insidious permissions is requesting the PHONE_STATE. Would you give all this information to the receptionist at your doctor’s clinic?
Figure Two:
public voidperformClick(String paramString) {
try {
boolean bool;
JSONObject jSONObject2 = new JSONObject();
jSONObject2.put("asset", paramString);
jSONObject2.put("template", this.zzvz.zzdE());
JSONObject jSONObject1 = new JSONObject();
jSONObject1.put("ad", this.zzvx);
jSONObject1.put("click", jSONObject2);
if (this.zzvw.zzq(this.zzvz.getCustomTemplateId()) != null) {
bool = true;
} else {
bool = false;
}
jSONObject1.put("has_custom_click_handler", bool);
this.zzvy.zza("google.afma.nativeAds.handleClickGmsg", jSONObject1);
return;
} catch (JSONException jSONException) {
zzb.zzb("Unable to create click JSON.", (Throwable)jSONException);
return;
}
}
Reference is made to google.afma.nativeAds.handleClickGmsg. This above is located under com.google.android.gms - GMS stands for Google Mobile Services.
Figure Three:
public String zzjw() {
return "google_analytics_v4.db";
}
public String zzjx() {
return "google_analytics2_v4.db";
}
Two references to Google Analytics found in the zzr.class file.
Figure Four:
final Messenger zzavX = new Messenger(new Handler(this, Looper.getMainLooper()) {
public voidhandleMessage(Message param1Message) {
if (param1Message == null || !(param1Message.obj instanceof Intent))
Log.w("GCM", "Dropping invalid message");
Intent intent = (Intent)param1Message.obj;
if ("com.google.android.c2dm.intent.REGISTRATION".equals(intent.getAction())) {
GoogleCloudMessaging.zza(this.zzavY).add(intent);
return;
}
if (!GoogleCloudMessaging.zza(this.zzavY, intent)) {
intent.setPackage(GoogleCloudMessaging.zzb(this.zzavY).getPackageName());
GoogleCloudMessaging.zzb(this.zzavY).sendBroadcast(intent);
}
}
});
This is in the GoogleCloudMessaging.class file. Google Cloud Messaging WAS a mobile notification service developed by Google for third-party app developers to send notification data to applications that target the Android Operating System. This feature is deprecated, and Firebase is used in its place. The medical application apparently has not upgraded. If used properly you can notify a client app that new email or data is available to sync.
Figure Five:
public classzzan {
private String zznv = "googleads.g.doubleclick.net";
private String zznw = "/pagead/ads";
private String zznx = "ad.doubleclick.net";
private String[] zzny = new String[] { ".doubleclick.net", ".googleadservices.com", ".googlesyndication.com" };
private zzaj zznz;
More references to ads. DoubleClick is owned by Google, specifically ad-serving, ad-delivery, and behavioral targeting. This is in the zzan.class file.
Figure Six:
local_0 = unaff_v3.mPubScreenWebView;
ref_00 = new WebViewClient();
local_0.setWebViewClient(ref_00);
local_0 = unaff_v3.mPubScreenWebView;
ref = local_0.getSettings();
ref.setJavaScriptEnabled(true);
local_0 = unaff_v3.mPubScreenWebView;
local_0.setLayerType(1,null);
local_0 = unaff_v3.mPubScreenWebView;
local_0.loadUrl("http://www.tokbox.com");
return;
The above reveals things to us.
- The application and the associated portal connect to a company called TokBox. This is a platform as a service company that provides a hosted infrastructure for real time communications.
- There are insecure connections that are being made. All traffic needs to be secure and not over port 80.
- Webview allows you to display web content as part of your activity layout, think of it like a scaled down browser. If your going to use it at least have the decency to use clearCache() which deletes any files stored locally.
Conclusion:
Is this malware, obviously not. However, when you have something as sensitive as a telemedicine app where your data is being broadcast through the internet care must be taken. The app asks for the permissions mentioned above which I find not only intrusive but also goes into the company’s desire to collect ad data. At its core the app is for tracking because in the analysis we Chrome opening up to create a session to their portal, so the only thing that app is doing is taking a lot of permissions, tracking the user, and then opening up a chrome session to the portal. The user would be far safer just using the chrome browser if need be.
So we have an apk that is basically a tracker, a telemedicine app associated with an ad network, and actively broadcasting to their platform as a service component over an insecure channel, at some point when do you say NO! As a collective society we seem to be okay with giving our information away at an alarming rate. Your patient data is not only sensitive but in the wrong hands can be used against you.
A telemedicine app should be treated the same way as a face to face visit with paper records. Would you sign an agreement when you go to the doctor that would allow him to use your statistics for participation in advertising? I would hope not. Worse this company’s public facing website was riddled with SQL injection issues and a path traversal problem. However here is the onion. In their privacy statement they clearly tell you that they participate in ad collection, so by downloading their app and using their portal you are consenting.
Is it right, I surely don’t think so but people treat electronics in a different standard then they do in person visitation. Do not give your identity or privacy away for the sake of convenience because when the data breach comes and it will, the company will be protected and you will have no recourse when your data has leaked because no one does accurate code review. You should not have to pay to go see a doctor and then have your data sold. More importantly, protect yourself, because no one else is going to do it for you.
Guard yourself, ask questions, take your data seriously, and if you are confused, contact us – we share the knowledge