Real-World Android Apps
Mobile Systems and Smartphone Security
(MOBISEC 2020)
Prof: Yanick Fratantonio
EURECOM 1
Pro-ing up
- Last time: basic things about Android apps
- Today: "complicated" things about real-world apps
- Many of these things are used by malware or have
security repercussions
2
App Signing
- Each app is signed with a certificate
- A certificate is
- the public key of a public/private key pair
- some other metadata identifying the owner of the key
- The owner of the certificate holds the corresponding
private key
3
Primer on cryptographic signatures
- Developer generates a public/private key pair:
- private key: PRIV
- public key: PUB
- The developer keeps PRIV secret
- PUB, as the name suggests, is public
4
Primer on cryptographic signatures
- Two primitives: sign & verify
- sign(MESSAGE, PRIV) ~> SIGN
- Only the developer can create a valid signature
- verify(MESSAGE, SIGN, PUB) ~> VALID / NOT VALID
- Everybody can check whether the signature is valid or not
5
App Signing
- Certificate doesn't need to be signed by cert. authority
- Apps' certificates can be self-signed
- Major difference with SSL certificates
- Purpose: distinguish app authors, NOT identify them
- You can distinguish "system" vs "normal" apps
- System apps are those that are signed with a "system" certificate
- That's how the system deals with "signature" permissions
6
App Signing
- You can determine that a given Facebook app has the
same developer as a given Messenger app
- But by only checking an app's certificate...
- ...you CANNOT determine whether the Facebook app you
have is the legitimate/official one!
7
App's certificate vs. SSL certificate
- Your browser knows that the "facebook.com" website you
are talking to IS the real, legitimate one
- That certificate is signed by another certificate, which is
signed by another certificate, which is signed by ....
- ... which is signed by a certificate that your browser trusts
8
android:sharedUserId (doc)
- Apps can request to be assigned the same Linux User ID
- Only if their certificates are identical
- All security barriers discussed so far are gone
- Two apps with the same Linux User ID share everything
- Both can access each other (private) internal storage
- Both can access each other components, regardless of configuration
<manifest xmlns:android="..." <manifest xmlns:android="..."
package="com.mobisec.app.ONE" package="com.mobisec.app.TWO"
android:sharedUserId="com.mobisec.shareduser"> android:sharedUserId="com.mobisec.shareduser">
9
Resources (doc)
- Resources are the additional files and static content that
your code uses
- drawable, layout, raw
- values
- arrays
- colors
- strings
10
Resources example: strings.xml
- In strings.xml
<resources>
<string name="secret_string">Juicy Secret</string>
</resources>
- In the Java code
String secret = getResources().getString(R.string.secret_string);
- From the docs
11
Resources under the hood
invoke-virtual {p0},
Lcom/example/MyActivity;->getResources()Landroid/content/res/Resources;
move-result-object v3
const v4, 0x7f07002b
invoke-virtual {v3, v4},
Landroid/content/res/Resources;->getString(I)Ljava/lang/String;
move-result-object v1
From res/values/strings.xml
<string name="secret_string">Juicy Secret</string>
From res/values/public.xml (it specifies the mapping)
<public type="string" name="secret_string" id="0x7f07002b" />
12
RunTime.exec() (doc)
- Analogous of C's system() or Python's os.system()
- Runtime.exec("cp ../flag /sdcard/leaked-flag.txt")
13
Reflection (doc)
- Java interface to programmatically "play" with Java
objects beyond what's normally possible
- Bypass access modifiers (e.g., private, protected, final)
- You can invoke private methods or get/set private fields
- Enumerate / iterate over methods/fields of a class
14
Example of Reflection
peppa.pig();
try {
Method m = peppa.getClass().getMethod("pig");
m.invoke(peppa);
} catch (...) {
...
}
15
Reflection Benign Use Cases
- Google gson's library: github
- "Gson is a Java library that can be used to convert Java
Objects into their JSON representation. It can also be
used to convert a JSON string to an equivalent Java
object."
16
Reflection Malicious Use Cases
- Malware authors are big fans of reflection
- peppa.pig();
It's a string!
invoke-virtual {v3, v4},
Lcom/example/Peppa;->pig()V
- peppa.getClass().getMethod("pig").invoke(peppa)
???????
Obfuscation made easy!
17
Dynamic Code Loading
- Apps can "load" additional code at run-time
- This code can be loaded from the file-system
- It could be embedded in the app itself
- It could be a "just-downloaded" piece of code
- Benign apps do this to
- A/B testing
- Sharing common framework
- Download additional parts (e.g., "levels" of a game)
18
Dynamic Code Loading
- Malicious apps do this for... obfuscation!
DexClassLoader classloader = new DexClassLoader(
peppaApkFile.getAbsolutePath(), tmpDir.getAbsolutePath(),
"data/local/tmp/natives/",
ClassLoader.getSystemClassLoader());
Class<?> cls = (Class<?>) classloader.loadClass("com.mobisec.Peppa");
Method m = cls.getMethod("pig");
Execute This! Analyzing Unsafe and Malicious
Dynamic Code Loading in Android Applications, Strings!
Poeplau et al., NDSS 2013
19
Serialization
class Peppa():
def __init__(self, n, s):
p = Peppa(42, "ciao")
self.n = n # int
self.s = s # string
pickle.dumps(p)
def pig(self):
return n*s
"(i__main__\nPeppa\np0\n(d
p1\nS's'\np2\nS'ciao'\np3\ns
S'n'\np4\nI42\nsb."
20
Serialization
- The serialized version ...
- ... encodes details about a specific instance of Peppa
- ... does NOT encode the actual definition of Peppa
- To load the instance of Peppa from the raw bytes
- You code needs to have Peppa's definition within the visible classes
- How is this relevant for Android apps?
21
Serialization
- Objects need to be serialized before are sent via Binder
- Example: Intents!
- Two main interfaces
- Parcelable (doc)
- Implemented by objects whose instance can be written to / restored from a Parcel
- Parcel: a container for an object to be sent via Binder (doc)
- Serializable (doc)
- More generic serializable interface
- Nice tutorial: link
22
