Insecure CSL Dualcom mobile app

CSL Dualcom, the intruder alarm signalling provider, recently released a mobile app. It’s aimed at installers, and appears to allow them to perform site surveys (see signal strength for different networks) and view the status of devices they have installed. The promotional video also shows two pieces of data – ICCID and chip number – that, in my opinion, could be used to clone the CSL Dualcom device.

From promotional video

From promotional video

This is relatively sensitive data so I thought I’d take a quick look at the security measures they have taken in the app.

Unfortunately a number of basic and unforgiveable mistakes have been made.

Using Burp Suite, I proxied the traffic between the iOS app and CSL to see what was happening. I then downloaded the Android APK and viewed it in a decompiler.

No HTTPS

Nothing I can see in the traffic or app indicates that HTTPS is used anywhere – it’s all HTTP, albeit on a non-standard port 15136.

No HTTPS

No HTTPS

This means that all data sent between the app and server is sent in the plain, and can be intercepted or altered by anyone in the middle.

On a mobile app, this is totally unforgiveable, for a number of reasons:

  1. There are no cues to the user that the app is not using HTTPS. A browser makes it pretty clear when a site is using HTTPS. An app doesn’t.
  2. A mobile app can and will be used on unsecured WiFi and untrusted network connections. This massively increases your exposure to attack compared to using a trusted machine on a trusted network.

HTTPS is essentially free these days. The actual certificate is not expensive (and, for a mobile app, you can get away with self-signed and pinned certificates), and the increase in processing power required on the server and client is minimal.

Poor code quality

There are a number of signs that the code quality of the app is not up to scratch.

It sends your IMEI to their servers when it first runs, but the end-point just responds to tell you it’s invalid JSON. So you are sending sensitive information in the clear, but it’s being discarded anyway.

IMEI request

IMEI request

IMEI response

IMEI response

This is really quite sloppy and should have failed testing.

The code has typos in it e.g. IEMI, phon, etc.

Typos

Typos

Human readable error messages sent as responses end up as nonsense when presented to the user:

This makes sense…

 

But this makes no sense...

But this makes no sense…

Conclusion

I’ve not even actually logged into the app yet, but the lack of HTTPS should be enough to stop anyone from using this app.

The lack of HTTPS was reported to CSL Dualcom on the 26th June 2015. A review of the Androud app on 28th October 2015 shows that it is using HTTPS, but this has not been checked for further issues.

 

Leave a Reply

Your email will not be published. Name and Email fields are required.