For the last few days, the YouTube video of Mr Saket Modi showing the 20 Sec mobile hack in a TV studio in front of honourable Minister of IT and Law, Mr Ravishankar Prasad with some key officials of Government of India including Mr Sajay Bahl, Director general of CERT-In in the audience is creating waves in the security professional circles. (See the video below).
Mr Ravishankar Prasad was distinctly uncomfortable that he was sharing stage with an ethical hacker who was demonstrating the hacking of a mobile which could create a scare among the public about the use of smart phones while the PM has so many times gone about advising villagers to use mobiles for payments.
During the demonstration, Mr Saket Modi installed an app on the demo phone from perhaps his own website. The App asked for permissions for access of SMS, Contact list and location etc which was granted by Mr Saket himself since he was holding the mobile for that crucial 20 seconds. After this, through his laptop he was able to access the SMS, Contact list and location and show it to the public. During the exercise it is presumed that the demo phone was connected to Internet either through Wifi or mobile internet. So also was Saket’s laptop. He also demonstrated the activation of an audio recording service on the mobile.
There is no doubt that the demonstration served the objective of sensitizing the audience about the risk of a malware getting installed in their mobile either through the physical access to the phone made available to a hacker or through a malicious link being opened by the mobile user.
The risk of a “Virus” or a “Trojan” in any computer device is already well known. Whether it can be installed in 20 seconds or more or less depends on the size of the file to be installed and the bandwidth of the internet connectivity.
It is therefore not surprising at all to note that Mobiles have a security risk. In fact every electronic device including the EVMs and Aadhar Biometric Devices have risks that we need to recognize. It is for this reason that the Election Commission refused the request of AAP that the EVMs should be handed over to them to show that it is hackable.
What we need to analyze is how to mitigate such risks. In this respect the Saket’s demonstration fell short of my expectations.
Normally apps are downloaded from the Google PlayStore or Apple Store. In such cases, it is presumed that apps are screened before they are allowed to be uploaded into the PlayStore so that malicious apps can be filtered out. However, except identifying the app with a signature of the app creator as declared (which can be an anonymous or pseudonymous) the app store does little to “Certify the App” as “Reliable”.
Before the App is installed, it asks for certain permissions and if the permissions are not given, the app may not get installed.
The app needs some permissions depending on its functionality. However most apps simply get access to several services in the phone and there is no way Google or Apple may know how the permission would be used subsequently when they allow apps to be uploaded into their stores.
Whether an App is asking for only such permissions that it does require for delivering the services it is supposed to provide and not more is a matter which an ordinary user is unable to find out. At the time of downloading the App he is only interested in using the App and hence he will provide permissions to all services sought by the App.
Some Apps may require what is called “Root Access”. This is normally used when some basic hardware functions need to be tweaked by the App. Most manufacturers block root access by design and void their warranty if this block is removed. Most hackers therefore try to work within the non root access requiring permissions.
When an app is downloaded from a source other than the PlayStore, it would be necessary to provide additional “Permission to install from unknown sources” by going to “settings”. (unless it has already been in the open status). Obviously, in this case one has to trust the site from which the app is being downloaded and there would be no assurance from the PlayStore about any aspect of the app.
Once the permission/s are granted, the app owner may use it for the functionality for which the user downloaded it and also for any other purpose.
The best practice for App developers is to take one time permission each time a specific functionality is required to be used rather than taking it once and holding it permanently. Though this may slow down the operations a little, it is the best practice which should be followed but no body seems to realize as of date.
Hence app owners easily misuse the permissions and commit frauds against the mobile user.
It is also possible for a malicious person to provide one functional app which the user installs and gives permissions and using the permissions, the app owner may install another malicious app without the knowledge of the mobile owner.
Mr Saket Modi says in his video demo that he is using only such permissions as the popular apps like Uber or True Caller use and nothing more.
His statement may be wrong in at least one respect namely the “Audio Recording Permission”. Normally apps donot ask for this permission unless it is a call recording app. Using this permission,he demonstrated that he could activate the recorder remotely and record the sound from the room where the mobile was present. This could be your confidential conversation with your wife in the bed room or the corporate secrets discussed in the Board room. Since this was a demo of the risks, we can ignore this misstatement of Saket for the time being.
Similarly, when a “Permission to Access Camera” is provided, the app can maliciously switch it on and take snaps or video without the knowledge of the user. A permission to read SMS may be misused for reading the OTP sent by a Bank to push through a Banking transaction. Permission for reading call records etc may not be required for most functions but they are often asked for.
I consider that the limited purpose of the demo was to create awareness that “Smart Phones carry the risk of being hacked easily” which puts the user at great risk. Such risks are higher when the user puts through financial transactions of various Bank applications and the UPI applications.
Sensing the aggressive mood of Mr Ravi Shankar Prasad, Mr Saket Modi was perhaps not very honest in saying that BHIM or other UPI apps donot carry risks of the type he was discussing. Unfortunately, once a person gets access to SMS and therefore the OTP, most of the financial applications which depend on the 2 Factor authentication are vulnerable.
RBI and the Government may be thinking that 2 Factor authentication is great but the way it is being implemented now is amenable to be misused very easily. In US, OTP based authentication has already been degraded by the Government as per its security policies. But in India we are using OTP even for Aadhar based authentication and for the issue of e-Sign digital certificates with which contractual documents can be signed.
I would like to say that the Government has not fully assessed the risks of OTP based authentication for Banking and Aadhar KYC and its faith on OTP as a 2 factor authentication is misplaced.
Mr Saket Modi was seen assuring the Minister that frauds in India is about a third of what it is in US and got a special applause for the same. Either he did not know or did not want to confide that in India we donot have a proper recording of frauds and hence we record only around 10 to 20% of financial frauds and ignore the others. Our statistics are therefore unreliable.
I consider that the demo was good for awareness creation, but it did not focus on providing a clear picture of what kind of solutions we need to think of to prevent these risks.
Where is the Solution?
As a solution, Mr Saket Modi spoke of on app “Unhack” and there are many other similar apps which basically check the “Permissions Granted” to different apps and list them as risk factors. Some apps may provide you an option to remove permissions already granted.
These apps which monitor “Permissions” do serve a purpose but they cannot prevent the misuse of the permissions granted in good faith and misused later.
If therefore we want to look for solutions, we need to prevent misuse of “Permissions Granted”. In the demo we did not see any useful discussions on such solutions.
Mr Ravi Shankar Prasad repeatedly drew the attention of Mr Saket Modi to the Information Technology Act 2000/8 and Saket also acknowledged it.
It must be noted here that under Section 43 of ITA 2000/8, if the permissions obtained under one pretext are used for purposes other than the disclosed use, it can be considered as “Unauthorized Access” and penalized under Section 43 and Section 66 of ITA 2000/8.
Indian law is robust and does not consider “Permission Granted for a certain purpose as a universal consent for the receiver to do whatever he wants with the information”. Hence if the app owner requires a permission for a certain functionality and obtains it, he cannot use it for any other purpose without being liable under Section 43/66.
The key to this deterrence is to bind the app owner to disclose what permissions he seeks and why he is seeking them before the installation of the App so that if there is any misuse, he can be charged under Section 43/66.
Mr Ravi Shankar Prasad needs to look at creating a deterrence around this Section 43/66 in ITA 2000/8 by forcing the app owners to disclose the permission information. This is the solution that the Government should work on.
I donot know what is the purpose of these permissions in the first place and how can I be assured that these permissions would not be misused later on.
During the discussions, Mr Sanjay Bahl of CERT-IN referred to the C-DAC application called M-kavach and stated that it can be used for mobile security.
When we look at this app, we note that it does present an EULA. However the EULA provides “No Warranties” and proclaims “No Liability for Damages”, though it claims Copyright protection.
This is typical of all software providers that they take it as their birth right to place a software product for public use but donot take any liability for any bugs and vulnerabilities in the software.
It is unfortunate that CDAC also follows this principle which I consider as a “Fraud Against People”.
Every software developer must state that to the best of his knowledge and good faith, the software does not contain any bugs.
He should also introduce a “Bug Bounty” program and seek the assistance of the good intentioned security professionals to point out bugs if they find it, for which atleast a nominal reward or recognition may be given.
We had recently pointed out this requirement while discussing the Abhinav Srivastava’s case. If despite this, bugs are found, it should be examined if the disclosure was made in good faith or recklessly to mislead the users and action initiated under ITA 2000/8.
Further, if he EULA for M-Kavach is accepted ,it immediately asks for the following permissions such as
- “Permission to Manage Phone Calls”
- “Permission to access photos, media and files on the device”
- “Permission to access contacts”
- “Permission to Send and View Messages”
- “Permission to access this device’s location”
So, it is clear that CDAC (Hyderabd) is no better than Mr Saket Modi in failing to inform the users of the app about why they need permissions of different types.
Only when the Government shows the way, we can insist that private app providers may also follow this good practice.
Since we are discussing the safety of mobile apps who get permission for a functional requirement and use it for a different purpose, the only way security can be provided is to bind the app owner to certain security commitments and then haul him under ITA 2000/8 if he fails.
Safe App Certification Progam
For proper implementation of this requirement, Government may consider introduction of a “Safe App Certification Program” which will ensure that
a) the App owner is known through a KYC process
b) Provides a commitment that he has taken reasonable security measures to ensure that the app is bug free at the time of release,
c) Provides for a bug bounty program to further crowd source the security against bugs and vulnerabilities,
e) Provides a Cyber insurance cover to the users to atleast a nominal extent to cover losses arising out of the vulnerabilities in the app.
For the solution to be successfully used, there is also a need for creating appropriate evidentiary support to ensure that the app owner can be hauled up under the Indian law. This can be taken care of by the Safe App certifying agency which can also make periodical re-assessments for continuing the security certification.
The system will be like the ISI mark for manufactured products and the Certifier can digitally sign the registered app and provide a list of such certified products in the CERT-In site or the certifier’s site.
If we think India has to use more of mobile apps for financial transactions and the vulnerabilities as demonstrated exist, the only way by which the Government can assure the public is to introduce such “Safe App Certification”.
While the Government ponders over this thought which I am sure will take its own time….. I urge some enterprising private party to come up with such a certification for which we can draw up certain norms and provide a kind of “Audit Certificate” to say that the App owner follows the recommended process for certification.
In the meantime, if any App owner wants to use a Certified Disclosure through the CEAC service of Naavi, they are welcome.
Look forward to comments…