I am developing android an app to detect malicious apps .we are planning to detect malicious apps based on the requested permission.....does permission alone will help us to detect malicious apps or do we need to consider characteristics like use of dynamic code, usage of static http url....any help appreciated. ...
I will breakdonw this question is several smallwer parts:
detect malicious apps
This is perhaps the harderst part in what you desire to do. Most anti virus, anti malware, etc. will usually search a "footprint" in the source code of the binary that is generating the instructions. If you found a number above threshold of footprints, you can guess that file is malware.
we are planning to detect malicious apps based on the requested permission
I am going to say explicitly: no...
As far as I have seem, most "weird" requests, are usually due to the programmers not fully understanding what the permission grants, or even why/what is necessary for.
This is so much an endemic problem, that Google itself changed how permissions work (if I am not mistaken, from K to L, or L to M or something in those updates)
Then again, an alarm app, that wants network access, wants to read all files in the system, wants to read/writte anything anywhere, wants to use your gps, etc etc, then that looks like malware on itself (and usually no READING user would use it).
do we need to consider characteristics like use of dynamic code
Yes. While Java itself cannot interpret its code "on-the-fly", DEX allows us to. And the most common hijacks are usually apps that do nothing, but then create an entry point to render javascript content, and perform some unexpected code.
usage of static http url
That is on itself not that much of a risk, since most browsers will request some security credential, and at least warn the user that he is on un-trusted network. A secondary problem that usually arrives is geerating the URL "on-the-fly" then asking an empty request to alter its request to that.
If an app is then requesting any web-based content bypassing the system (not a security issue, sometimes the programmer is simply making "less effort than necessary to fullfill a client request", then looking at static addresses, or even IPs is usually of no significant security value.
Related
I can call other apps' Activities without problem, including sending them some data and receiving some data back. But I am sending and receiving some sensitive information that could arguably be misused if in the wrong hands. My question is, is this data safe when traveling between appications?
For example, I call an Activity like this:
Intent intent = new Intent("com.my.package.MY_REQUEST_ACTION");
intent.setClassName("com.other.package", "com.other.package.UserActionActivity");
signerIntent.putExtra("INTENT_PASSWORD", "1234");
signerIntent.putExtra("INTENT_COMMAND", "COMMAND_DO_SOMETHING");
signerIntent.setType("text/plain");
startActivityForResult(intent, 0);
And return something in UserActionActivity:
Intent result = new Intent("com.other.package.INTENT_RESULT_DESCRIPTION");
result.putExtra("INTENT_RETURN_RESULT", "...");
result.putExtra("INTENT_RETURN_RESULT2", "...");
setResult(Activity.RESULT_OK, result);
finish();
And so on. But how secure are these extra strings? Do I have to worry about them being accessible to other applications (other than the two involved), either intentionally or through some kind of "hack"? Do I need something like public key encryption?
And is the situation different on rooted systems (i.e. an app with root privileges can, without too much effort, read inter-app communication)?
Do I have to worry about them being accessible to other applications (other than the two involved), either intentionally or through some kind of "hack"?
Let's assume for the moment that neither app has been modified by an attacker.
If so, then in principle, the communications that you have established should be private on non-rooted device. In practice, there have been bugs with activity Intent extras, though none that I know of recently. Of your IPC options, activities are probably the worst choice from a security standpoint, as they have other impacts (e.g., appear in the overview/recent-tasks screen) that increase the likelihood that there is some bug that we have overlooked.
In your code, though, both sides assume that the other app has not been modified. In particular:
Unless you have some security that is not shown, any app on the device can run the code in your first snippet and try to trick the app to return the response in the second snippet.
The code in your first snippet assumes that com.other.package has not been modified by an attacker.
There are ways to help defend against this (e.g., custom signature permissions, checking the signature at runtime).
Also, bear in mind that an attacker can find "1234" without much difficulty.
With regards to the comments advising encryption, given the protocol that you are describing, encryption seems like an unlikely solution. If you have to provide a secret (INTENT_PASSWORD) in the IPC protocol, then there is no shared secret that both apps would have to use for encryption purposes, and I'm not quite certain what public-key infrastructure you would use to offer public-key encryption here.
And is the situation different on rooted systems (i.e. an app with root privileges can, without too much effort, read inter-app communication)?
Absolutely. On a rooted device, all bets are off. That is not tied specifically to IPC, though.
short answer: it is not safe but it needs some effort for the attacker.
long answer:
the transfer can be intercepted by a man in the middle attack:
on unrooted phones:
if you send data to intent.setClassName("com.other.package", "com.other.package.UserActionActivity"); somone can uninstall the original "com.other.package" and install his own "com.other.package" with the same activity that receives the unencrypted data.
For example an attacker can disassemble the original software, add code (that does something with the secret data) and reassemble the code to a new apk (with a different certificate)
On rooted devices: I donot know but i assume it is possible that the "exposed framework" is capable to intercept and redefine android os calls.
As far as i understand, an IsolatedProcess is here to run untrusted code.
But if the IsolatedProcess is basicly a process without any permissions, how can one send the untrusted code (lets say a class) to the IsolatedProcess?
I mean the IsolatedProcess have no access to the files in the device , to the internet, or anything else.
So what is the way to send the untrusted code to the IsolatedProcess?
I am trying to pass Constructors to the IsolatedProcess so he can start this untrusted classes safetly, but all the communication between processes must be with Serializable objects, and a Constructor is not a Serializable object.
You're misunderstanding the purpose of isolatedProcess. It doesn't provide APIs to do what you want because it isn't how it's intended to be used and using it like that wouldn't be a good security practice. It's designed to provide a layer of security that an attacker needs to bypass once they've gained remote code execution via an exploit. You simply shouldn't run untrusted Java code because Android isn't designed to do it. It will still have access to native APIs including the kernel's system calls, etc. within an isolatedProcess. isolatedProcess drops nearly all privileges (gets a unique UID / GID and runs in the isolated_app SELinux domain) but it's not a very good sandbox alone. If you're determined to do it, then doing it within isolatedProcess is better than outside it, but you would be rolling your own code for it.
The main user of isolatedProcess is Chrome. Each site instance is rendered by a separate isolatedProcess service. It doesn't run untrusted Java or native code. An attacker needs a remote code execution exploit to gain control over the isolatedProcess. Chrome also doesn't only rely on isolatedProcess for the second layer of defence. It uses a strict seccomp-bpf filter to greatly reduce kernel attack surface.
I am looking for options around creating a multi-platform application that will react to a HTTP call made to it. To explain my situation:
I have software running on client machines which is capable of making HTTP requests, specifically passing information via GET;
I can adapt the software to accept a manually inputted IP address and any other information (such as authentication tokens) but not really change the comms method;
The requirement is that this software can pass small amounts of information, on the fly, to an app running on a smartphone;
I'm able to specify networking restrictions, such as being on the same local network etc;
It's not really viable for me to create a server to sit between the app and the client.
My thinking is that I could create a simple app to effectively act as a server, sitting and listening for a HTTP call and acting on the information passed to it.
Phonegap crossed my mind purely for the cross-platform capability; Ultimately, if it needed to be native development, whilst not preferred, it is an option.
Everything I've found on the subject thus far is either specific to a platform, usually with no alternative on competing platforms, or is reliant on the app as a client or an intermediary server handling the connections.
My question is, is such a thing - effectively setting up an iPhone or Android device as a server with a listening port - actually possible in Phonegap, or at all?
I appreciate that there are some (very valid) security concerns with the above approach - additional controls will be put into place to deal with that, right now I'm at the beginning of the search and looking to see which is the most viable way forward.
I would have to say that your approach is a bad idea. You have to keep in mind that the OS can kill your app if it is in the background any time it feels like it. I would look more into using a push service to send the app any updates. That way, even if the app was killed, when the user opens the app it has the latest info. My 2cents.
I'm trying to make an Android app where I need to determine what kind of service class is using a phone, meaning, I'd like to know if the data connection is used for streaming, e-mail, chat, downloads, conferencing...
How can I do this?
If this is something you absolutely had to do, here's where I'd start.
There is a permission, perhaps the most dangerous of them all, called READ_LOGS. If that permission is set, then you can read the system logs. Find one relating to network access, then parse it through, and try to figure out how the phone is being used. These logs are deleted at reboot, however.
Personally, I wouldn't install that application, however...
Also worth looking at is the TrafficStats class, which will give you basic stuff, but not the details that you want.
No, you cannot know that.
If you could, it'd be a privacy violation ... If an arbitrary app could be installed, and know what I'm using my device. If you could get the application protocol type of all network connections, then you could also get the destination of the connections, and their content as well.
So I have read the LVL docs backward and forward, and have it working with my app. I have seen the questions about the response being cached. But it still leaves me wondering, based on some of the wording in the LVL docs, does Google want us to call the license checker every time the app is initialized? Is that the safest way to implement this? Using the ServerManagedPolicy like Google suggests, do we just call the license check, and either run our app or do whatever we choose if they fail? One of my small concerns is the use of network data. They drill into us the need to be cautious of using resources without informing the user, and it seems to me this is a use of network data without letting the user know.
To add to this, is anyone experiencing any type of delay to their app due to this code? Due to the nature of my app, opening it and then waiting every time for an ok to come through the network would definitely distract from its use. Should I cache the response myself, or am I way over thinking this?
You answered your own question; if you feel that calling the service every time you start would be disruptive (which it would, e.g. the user is out of coverage), then don't do it.
Google make no recommendations about how often to use the licensing service; it's down to how paranoid you as the application developer are about piracy, balanced with how much you feel constantly checking would annoy the user.
Ok, fair, only check it once in a while.. But where can you "safely" store the information, that you should check it once a day only?
Eg, the first time you start the app, you will check it. Result of LVL is valid: so you store the date of the last successful check. But where to store it? Using SharedPreferences ? Is this safe? Because if you have root access on your device you could access the preference and change the valid date (to either way in the future, an yes, ofcourse you can check that in the code :-))
PS. Sorry, could not make a comment :(
Call it every time you start the app. The LVL library, as shipped by Google, will cache the response and use it the next time the user starts the app, thus not requiring a network connection if they restart the application within the cache valid time-frame.
What you likely want to do is change the amount of time the cache is valid. By default, google ships with a fairly low cache-valid time, which resulted in some upset users who were outside of a network when the cache had expired.
Concerning LVL: Although the SDK provides a sample implementation, Google themselves, clearly recommend against using it "as-is".
http://www.google.com/events/io/2011/sessions/evading-pirates-and-stopping-vampires-using-license-verification-library-in-app-billing-and-app-engine.html
After watching that, I believe, LVL is not an option for apps sold for 1-2$. Furthermore, a failed LVL check (if no network is available) will piss off legitimate users.
while it is true, that you can implement some kind of caching LVL responses, it will always boild down to the question, in how far you want to protect against piracy at the expense of legitimate users?
And: developer time is limited, so maybe it is more worthwhile to put efforts in improving an app, instead off wasting to much time trying to cut down illegal usage.