Another (un)smart Smarter app

You might remember we looked at the hardware of the Smarter WiFi Coffee machine and found you could command it without adding it to your network and using the app. Accompanying the device was a new app – the Smarter app. This is a single app that covers both the iKettle 2.0 and the Coffee Machine.

I thought I would take a look at the app to see how it worked and if we could find any more juicy vulnerabilities like we found in the original WiFi kettle app.

Looking at the code of the Android version of the app, the first thing I notice is that it is a relatively small with only a few classes used:

The main bulk of the app is in the smarter classes.

Taking a quick look at the containers I was immediately interested in the async container as I wondered what might be leaving the app and it contained a couple of classes to do with home network scanning.

A quick glance as the 4 classes and the SendEmailBytes.class and SendEmailFile.class immediately caught my eye:

Hang on a sec, isn’t that a username and password stored in clear text in the application!  – I’ve obfuscated them for this post.

Didn’t I see a SendGrid container, complete with SendGrid Class.

SendGrid is an SMTP email service used within applications for sending email. It has an API which can be used to send the email. The API can be configured to be quite restricted in what it can do. In this case it seems Smarter didn’t do this, they just opted to include their full SendGrid username and password.

This would allow anyone to view their account stats and who they have sent email to.

The latest version 3.1.0 from 15 March 2016 fixes this bug

Rather oddly, we looked at an earlier version of 3.1.0 which had the bug, but it has been updated on the Play Store without incrementing the version number.

Hence, you should uninstall and reinstall the app. Even if your phone states it has 3.1.0 installed, you need to reinstall from the Store!

Avoiding the issue

Remove the static credentials. Smarter really should look at using the API in the right way for this app. The SendGrid service does allow very granular control over what the API can do which will limit the exposure, BUT if an application user can get hold of the API key and they will be able to do whatever the app can – in this case send email. Given that the key will be embedded in the application, essentially anyone who wants to would be able to do this

Secondly, and we have said this time and time again, implement some form of code obfuscation to prevent reverse engineering. It’s not going to fix the underlying issue, but it will make it harder for your API key to be accessed.

It could still be possible to obtain it by performing a man-in-the-middle attack against the app if it doesn’t support SSL Certificate Pinning and so thirdly, implement certificate pinning.

Those 3 key issues will massively reduce the risk of an attacker exploiting this or any app.