Communication analysis of the Avalanche Tirol App – Part 2
February 16, 2014
Originally I only wanted to look at the traffic to check why it took so long on my mobile, but than I found some bad security implementations.
1. The web service is password protected, but the password which is the same for all copies of the app is send in the clear
Just look at the request which is send via HTTP (not HTTPS) to the server. Take the string and to a base64 decoding and you get: client:xxxxxx – oh thats user name and password and its the same for any copy of the app.
2. We collect private data and don’t tell our users for what
The app asks following question “Um in den vollen Genuss der Vorzüge dieser App zu kommen, können Sie sich bei uns registrieren. Wollen Sie das jetzt tun? / To get the full use of the app you can register. Do you want to register now?” at every launch until you say yes.
But for what feature do you need to register? What happens with the data you provide? There is nothing in the legal notice of the app. I’m also missing the DVR number from the Austrian Data Protection Authority. Also a quick search in the database didn’t show anything. Is it possible they forgot it?
3. We don’t care about private data which is given to us
The private data you’re asks at every launch until you provide it, is send in the clear through the Internet. A SSL certificate was too expensive?
4. We are generating incremented client IDs to make it easy to guess the IDs of other users
At the first launch of the app on a mobile, the app requests an unique ID from the server which is not something random and not guessable. No its just a incremented integer (can’t be the primary key of the database table?), at least my tests showed this … the value got only bigger and not that much bigger, every time.
And as the image at point 3 shows that everything someone needs to change the user data on the server for an other user is this number, a small script which starts from 1 up to the 20.000 would be something nice …… the question is what else can you do with this ID? Should I dig deeper?
5. We’re using an old version of Apache Tomcat
The web service tells everyone who wants to know it, that its running on an Apache Tomcat/6.0.35. There are 7.0 and 8.0 releases out already, but the current patch release of 6.0 is 6.0.39 released 31 January 2014. But its worse than that, 6.0.35 was released on 5 Dec 2011 and replaced on the 19 Oct 2012 with 6.0.36. Someone not patching for over 2 years? No can’t be, the app is not that old. So an old version was installed in the first place?
ps: If you’re working with Ubuntu 12.04 LTS package … Tomcat is in universe not main … no official security patches.
This are my results after looking at the app for a short period of time … needed to do other stuff in between 😉
No Comments yet »
RSS feed for comments on this post. TrackBack URI
Leave a comment
Powered by WordPress
Entries and comments feeds.
Valid XHTML and CSS.
40 queries. 0.062 seconds.