Insecure Mobile Application Programming Practices - A Case Study

Originally published by Geoff Ellis on June 22, 2017

Designing and releasing Mobile Applications is a popular way for businesses to interact with their customers in this day and age. However, security often takes a back seat to functionality and simplicity - and that can lead to bad things!

Today I’ll provide a case study, showing that even the most experienced programmer and cyber security expert can get caught in the same security traps that befall even the newest app developer. Simon Smith (eVestigator with 21+ years experience in the industry), owner of 1IQ Pty Ltd has released a number of Apps on Google Play. The 3 we’ll look at today are

eVestigator Forensic PenTester

This application is essentially a port scanner. At the end of the port-scanning process the developer asks for your name, email address, and some messages from the user. It then crafts a simple GET request containing all of your information! It also discloses any information about your infrastructure you have included in that request.

The following is crafted request sent by this app. App [NAME] - [PHONE#]&FromName=eVestigatorApp&[email protected]&[email protected]&Message= [MESSAGE]

While the request is sent encrypted via HTTPS, If you managed to successfully create a MITM and able to listen or capturing traffic on a network this app was being used on, you’d know the name, email, phone number of the user, as well as the location of an email script that requires no authentication, and [hypothesising because the script has been removed] possibly the ability to send email to whoever you like from whoever you like. Industry App & VPA

Both of these applications have the same vulnerability. They provide a login interface to a website hosted on the internet. However like the above eVestigator app, the login process consists simply of a crafted GET request to the hosted web application as seen below. [USERNAME]&Password= [PASSWORD] [USERNAME]&Password= [PASSWORD]

As you can see, anyone monitoring a network that these apps were used on, would be able to capture, record, and access the account of anyone who used the apps simply by replaying the captured data. There is no other authentication or verification in place. It also suggests that the password is stored both in plaintext in the database - and the password would likely be stored in plaintext in the web server access logs as well!

Mobile Apps are a comparatively new field in the realm of software development, but it’s been a decade now that Mobile Applications have really taken off. Mobile App Developers need to start taking Security seriously when developing mobile applications, and that especially applies to Security experts and Software Developers that have decades of experience. Security mistakes like this are soooo simple and straightforward that they literally should just never happen.

So, if you’re interested in programming, consider learning secure coding practices as soon as practical. Incorporate it into your training as early on as you can. Don’t think of it as something you’ll add later - because later often doesn’t come until it’s already too late.

End of original article

Selected Comments

Simon Smith

Hello, everyone.

I developed the originals of these. I have been programming for many years and these were ‘never’ at all public production Apps. In fact, they were never used except minimally the port scanner and that has been taken out of context in its use and requirements as a SAAS for one on one clients, for free at no cost. An MITM attack can be performed on practically any App in the AppStore (https or not) if you have the benefit of reverse engineering the APK and having a criminal hacker inside the network - which is a cyber security risk in itself, not a vulnerability. If one was to spend a day, they would be able to find 1000 Apps that could be intercepted. Criminal interception hacking is not a vulnerability.

Ironically the VPA App never even tries to connect to the internet, so that statement is completely false. The domain name was bought by Australia Post as well. It was a proof of concept. The source code does not even attempt to go to the Internet!

All of this has been taken completely out of context and riddled with errors. I will report on this later. This information is misleading and deceptive and unfortunately been taken outside of its intended scope, perhaps not Geoff’s intention.

I agree with Geoff on many levels. The VPA App that is mentioned does not even attempt to access the internet! It can be easily tested by installing a firewall on your Android phone. These Apps were part of an expired account and ‘mock up’. There are always two sides to every story. I will happily talk to anybody who wishes to discuss fact.

Sadly, there are ‘researchers’, not Geoff but others on the internet that have engaged in death threats, false reporting, severe stalking, defamation, character assassination and serious malicious national and international crimes. If they were production Apps then naturally, they would have more than 4 or 5 installs!

I congratulate Geoff on his time, but for the fact had he have spoken to me, I would have told him it would have been better spent doing something elsewhere. It is a very simple, easy, attack (not a vulnerability) to capture the packets of any App regardless of https, in any network, that is why one needs to trust their WiFi and/or VPN provider 100% before running anything.

Unfortunately, because others have taken this too far, some things I cannot discuss as they are subject to litigation due to the level of defamation, stalking, misleading and deceptive reporting, criminality and piracy involved. I always advise people to get both sides of the story. I have built mobile enterprise applications that are still in use 20 years later.

Happy to direct chat with anyone to provide evidence. I don’t advocate for hate speech and don’t think LinkedIn should become a negative playground for such as did Twitter where unfortunately hackers may now be arrested for serious stalking that you would not wish on your worst enemy. That is the last I will speak of it, happy to talk personally, the rest is with the Federal Police and the lawyers as the truth is what I stand for and nobody should ‘guess’, and this post had Geoff had known some factors may very well not exist.

Cheers, Simon Smith

Geoff Ellis

I congratulate Geoff on his time, but for the fact had he have spoken to me,

You mean except for the fact that you had blocked me on linkedin and twitter because you didn’t like the (valid) points I was making on one of your articles posted on linkedin? Clearly not open to criticism or feedback.

I’ll address the rest of the stuff later when it’s not nearly 2am.

James H.

Incredible that you think sending sensitive data in GET requests and allowing for the possibility of Man in The Middle is a good thing for a TOR application. The whole point of TOR is to be “Anonymous” right?

Bryan Onel, CISSP

Don’t forget that information identifying the users using the app was sent to one of Simon’s servers. People are allowed to be anonymous, but not from Simon.

Every time he responds to any news article that mentions a person’s right to privacy, he starts ranting about how that negatively effects investigation of people. He wants to be the almighty keeper of all information and does not care whatsoever if the users of his apps are exposed because of the vulnerabilities he has in his apps. As long as he knows who they are, so he can sue them xD

Bryan Onel, CISSP

inb4 Geoff Ellis gets over 9000 threats from Simon

Geoff Ellis

Came home to legal threats tonight regarding this.

Bryan Onel, CISSP

Classic Simon.

Edward Farrell

Geoff I think you need to file CVEs on these