Update 15 March 2019: After another test, we can confirm, that the developers of the Transparent Clock & Weather app fixed the issue that was leaking the exact GPS location of the mobile phone.
Update 06 February 2019: The developers of the Transparent Clock & Weather app contacted our team to confirm our observations. They were using third party API providers that didn’t provide encryption. In addition, they mentioned that the app was never intended to make requests every 15 seconds, and that if that happened it should have been a bug. They talk with the third party API providers to secure the API. Now the API works over TLS.
Our team re-evaluated the Transparent Clock & Weather application, and was able to confirm that third party providers are now contacted using encrypted communications with TLS. However, the app stills performs at least one unencrypted request to one of the providers (met.no), and then it gets redirected by the API to continue communicating via TLS. This single unencrypted request exposes the exact GPS location of the mobile phone (latitude and longitude). The fact that the API endpoint is forcing the app to use TLS indicates that the app has not been fully fixed yet. We are working together with the developers of the application to make the app more secure.
Summary
In this blog, we report some key issues on the 'Transparent clock & weather' android application after assessing the network traffic generated by it. In our analysis we found:
How a seemingly benign application may leak sensitive information that may put users at risk. We provide details about how the information is leaked.
We examine what an attacker may be able to do if is able to retrieve this information.
About the application
The 'Transparent clock & weather' application is developed by MACHAPP Software Ltd. According to Google Play Store, the application has 50 million downloads. It has been rated by more than 700,000 users, with a score of 4.4 out of 5.
The latest version of the app, 1.41.01, may request access to:
Calendar
Location
Storage
Other: full network access, prevent phone from sleeping, run at startup, receive data from the internet, control vibration, view network connections, com.google.android.finsky.permission.bind_get install_referrer_service (this gives the developers information on how the users arrived to the app before installing)
Note that after installing it, the application explicitly requests access to the location. It has access to the network by default, but not to the calendar and storage.
Details of the 'Transparent clock & weather' application as it appears in the Google Play Store. Reference: https://play.google.com/store/apps/details?id=com.droid27.transparentclockweather
information leaked
Upon setting a location for the app to show the time and weather, the application communicates over the network to send the user location. The communication is over HTTP, using GET requests, and none of the transferred data is encrypted. The first request performed by the application is shown in Figure 1. It can be seen from the screenshot, that the location of the user hasn't been set (lat=0, lon=0), and that the user or app uses by default metric units.
Figure 1. First HTTP request performed by the 'Transparent clock & weather' android application.
The second request performed by the application (see Figure 2) shows that a specific location has already been set by the user. The coordinates 50.075538099999996, 14.437800500000002 are the location of the center of Prague, Czech Republic. This is because the location has been put manually, by typing an address or name of a city. In the request it can be observed that the unit system has not been altered, still metric.
Figure 2. Second HTTP request performed by the 'Transparent clock & weather' android application. The application sends in plain HTTP over the network coordinates of the location sent by the user.
The contacted hostname is tcw.fcawx.net. The domain was first created in 2015-04-01, and it's registered by Gandi SAS, a French company that provides domain name registration as well as other services, including web hosting.
What is most interesting to see from these connections, is the actual behavior. As shown in detail in Figure 3, the user connects to the external server (IP 94.237.26.97) via the standard TCP handshake. Once the connection is established, the user sends an HTTP GET request to the server, sending the information shown above, including coordinates, auth token, and units used. After that, the server acknowledges the transmission, but instead of answering with a typical HTTP response, the connection is closed.
This indicates that these connections are actually not retrieving any data.
Figure 3. Details of the TCP connection generated by the 'Transparent clock & weather' shows that there is no data retrieved from the server.
We let the application run for some time, and we found that actually, the application is performing connections every roughly 15 seconds (See Figure 4). Which raises the question: why a weather application needs to update itself every 15 seconds in the first place? What is the purpose of these periodic requests if there is no data retrieved?
Figure 4. The 'Transparent clock & weather' application generates periodic requests to their server, sending the user location, and no responses are obtained.
In a similar case we analyzed as part of our work in CivilSphere, we observed that sometimes the server is responding with HTTP/XML data. As you can see in Figure 5, the amount of HTTP responses obtained are not proportional with the number of requests sent by the user. Out of 10 requests the user sends, the server responds one or two times with data regarding the weather.
Figure 5. In a capture from a different user, the server responds sporadically to the requests sent by the user. The ratio of responses is disproportionate.
Mapping your every move?
An attacker with access to this data over a few days or weeks, can guess important information, such as:
Frequently visited places
Location of your work offices
Location of your home
If you visit clients, or institutions, where are they located
If your travel patterns are stable, meaning you have a strict routine, an attacker can predict where you will be approximately at which time.
If several people is using the app, an attacker tracking them can determine if they are meeting together or not.
It is quite possible for an attacker with access to this data to map your movements, and learn vital information that may put you or people close to you, at risk.
Figure 6. Using the information leaked by the 'Transparent clock & weather' application, an attacker can map your most common visited places, including where you work and where you live.
Conclusion
If you are a person at risk or that may be target of a cyber attack because of the type of work you do, it is important to understand that your phone is critical to ensure your physical safety. Mobile phones are not as secure as we tend to think. We recommend to keep only the most critical applications installed, and not trusting third party apps. Even a Weather application may put you at risk.