{"id":1462,"date":"2016-03-10T03:26:06","date_gmt":"2016-03-10T07:26:06","guid":{"rendered":"http:\/\/jeffq.com\/blog\/?p=1462"},"modified":"2016-03-14T15:51:06","modified_gmt":"2016-03-14T19:51:06","slug":"dteenergy-insight","status":"publish","type":"post","link":"http:\/\/jeffq.com\/blog\/dteenergy-insight\/","title":{"rendered":"CVE-2016-1562: Unauthenticated “filter” parameter leads to customer information leak in the DTE Energy Insight app"},"content":{"rendered":"

BACKGROUND<\/h4>\n

Here in southeast Michigan nearly all of our electricity (and a good chunk of our natural gas) comes from DTE Energy<\/a>, which serves 2.1 million people in the greater Metro Detroit area. DTE recently upgraded most of their electricity meters to ZigBee<\/a>-enabled smart meters, and as part of this rollout they released the DTE Energy Insight app<\/a>\u00a0which allows customers to view their energy usage, set targets, and earn a host of achievements (no Steam cards sadly) when meeting different energy goals. In addition, at no charge DTE sends customers\u00a0an “Energy Bridge”, a small device that connects to a\u00a0home network and monitors the ZigBee messages generated by a\u00a0smart meter to give real-time energy consumption information.<\/p>\n

\"\"<\/a>
The DTE Energy Insight app and the Energy Bridge device<\/figcaption><\/figure>\n

Given my curious nature I decided to poke around to discover how exactly the app and the Energy Bridge worked. This post is about a vulnerability in the app itself (although I’ve been tinkering with my Ettus Research B200 SDR<\/a> to intercept the ZigBee messages\u00a0as well).<\/p>\n

<\/p>\n

METHODOLOGY<\/h4>\n

By rooting my phone and using ProxyDroid<\/a>\u00a0to forward all traffic to a mitmproxy<\/a>\u00a0proxy running on my PC I deduced that the\u00a0Insight app was attempting\u00a0to connect to\u00a0apps.dteenergy.com<\/code>\u00a0via TLS (non-TLS connections were\u00a0rejected). Even though I had the certificate authority that mitmproxy generates installed to the\u00a0trust store on my phone the app refused to communicate through the TLS proxy, so naturally I suspected some form of certificate pinning<\/a> or a custom trust store was being used by the app.<\/p>\n

Decompiling the app’s APK with Apktool<\/a>\u00a0proved a somewhat frustrating experience; the app appeared to have been run through an obfuscator<\/a>. The res\/raw\/<\/code> directory in the APK did provide hints, though; the app contained two .bks (BouncyCastle<\/a> keystore) files. Unfortunately, the keystores were password protected. However, the resource IDs for these files gave me an anchor in the code, and I was able to follow the decompiled code to the function that loads the keystores through javax.net.ssl.TrustManagerFactory<\/code>.<\/p>\n

\"Decompilation<\/a>
Decompilation of .bks loading procedure<\/figcaption><\/figure>\n

res\/raw\/dtecomodo.bks<\/code> had resource ID 0x7f070009<\/code>, and the decompilation clearly showed that the password “vectorform” was being used. This code existed in the com.vectorform.wattsonandroid.c.a<\/code> class, which let me know that Vectorform<\/a>\u00a0developed the app for DTE.<\/p>\n

\"dtecomodo.bks<\/a>
dtecomodo.bks contents<\/figcaption><\/figure>\n

The keystore itself contained a certificate chain for the AddTrust External CA Root as well as the Comodo High-Assurance Secure Server CA, an intermediate authority. So, the Insight app wasn’t specifically pinning to a certificate for the API endpoint, but it enforced that the certificate that apps.dteenergy.com<\/code>\u00a0presented must be issued by the specific AddTrust\/Comodo chain given in the file. To bypass this restriction I added the mitmproxy root CA to the keystore and recompiled the app with Apktool.<\/p>\n

\"Modified<\/a>
Modified dtecomodo.bks file<\/figcaption><\/figure>\n

The modified APK communicated through the mitmproxy — success<\/a>!<\/p>\n

\"mitmproxy<\/a><\/p>\n

Every API endpoint required that an HTTP Basic Access Authentication<\/a>\u00a0header was\u00a0provided that contained the DTE customer’s username and password (the same one they use to access their online billing). The IdentityService<\/code> endpoint returned a dteSAML<\/code> variable, which needed to be included in all requests to endpoints that queried the customer’s actual energy usage.\u00a0Presumably this is a SAML<\/a> token, which likely\u00a0is passed along to backend DTE servers that actually monitor the customer’s usage. This led me to believe that data for the application is managed separately from the actual usage data. This was further confirmed by investigating the api\/Customer<\/code> endpoint which returned a DTEID<\/code> that could be used in some requests; dteSAML<\/code> was only needed when querying actual usage data.<\/p>\n

Basic tests such as requesting information for a different DTEID<\/code> via a GET to api\/Customer<\/code> showed that most endpoints were correctly checking access controls. Of interest was the api\/Notification<\/code> endpoint, which accepted a curious filter<\/code> parameter. Un-URL-encoded, the parameter read as follows:<\/p>\n

DTEID eq <dteid> and IsRead eq false and NotificationType.IsNotification eq true<\/code><\/p>\n

This suggested that the filter<\/code> parameter accepted arbitrary queries against a JSON-like database and returned the results.\u00a0I wrote a script to request arbitrary filter parameters; the only authorization needed was\u00a0the username and password for my DTE account passed as a Basic Access Authentication header.<\/p>\n

VULNERABILITY<\/h4>\n
\"Sample<\/a>
Sample result from a modified filter parameter<\/figcaption><\/figure>\n

As suspected, the filter<\/code> parameter was essentially a read-only SQL injection attack; the server would respond with whatever was\u00a0asked of it.\u00a0Thus, a filter of Customer.Zipcode eq 48346<\/code> would return the app’s database for every user with a 48346 ZIP code.\u00a0In addition to api\/Notification<\/code> there were a number of other endpoints that also accepted a filter<\/code> parameter, e.g. api\/CustomerProject<\/code>.\u00a0This resulted in the compromise of the entire database.<\/p>\n

CONCLUSION<\/h4>\n
\"Her
This xkcd needs no introduction<\/figcaption><\/figure>\n

Classic SQL injection attacks rely on string manipulation to escape the value of a parameter and modify the behaviour of the underlying query.\u00a0While not as serious as a full injection vulnerability (which would allow us to invoke the ghost of Bobby Tables), allowing an authenticated user to specify the full parameter to a WHERE-like clause is nearly as dangerous (especially if the table contains personal data on every user of your app!).<\/p>\n

If I may editorialize, DTE Energy Insight is a pretty slick app. It’s clear that a lot effort was put into its user interface and design. Although this article doesn’t cover the Energy Bridge device, my tinkering with it has shown\u00a0me that the engineers that worked on it were security contentious. The endpoints that deal with customer energy information require a SAML token, and those such as api\/Customer<\/code> don’t return information if a DTEID<\/code> different than that of the logged in user is requested.<\/p>\n

The filter parameter was likely a dirty hack — I’m sure there’s an engineer somewhere that cringed when they wrote it. Although the app is relatively obscure in the grand scheme of things the personal information of perhaps hundreds of thousands of users will always be a juicy enough target to warrant malicious activity. Techniques such as certificate pinning or custom trust chains protect against nefarious men-in-the-middle; they can’t guarantee the secrecy of an insecure API.<\/p>\n

RESPONSIBLE DISCLOSURE<\/h6>\n