Week 7

Question 1

Generic Exploit Mitigation Protections

Answer 1

Memory corruption issues in operating systems, including Android, have been exploited by attackers.

Security measures are introduced to prevent and respond to such exploits, aiming to make exploitation more difficult.

Android’s exploit mitigations are derived from the Linux kernel.

Android applications can include native code, which can be exploited if accessible.

Android’s exploit mitigations have been in place since version 4.0 (Ice Cream Sandwich).

Question 2

Stack Cookies - EM

Answer 2

Detects stack-based overflows.

Question 3

safe_iop - EM

Answer 3

Mitigates integer overflows.

Question 4

dlmallocextensions - EM

Answer 4

Prevents vulnerabilities like double free() in heap management.

Question 5

callocextensions - EM

Answer 5

Addresses integer overflows during memory allocations.

Question 6

Format String Protections - EM

Answer 6

Guards against format string vulnerabilities exploitation.

Question 7

NX - EM

Answer 7

Blocks execution of code on the stack or heap.

Question 8

Partial ASLR - EM

Answer 8

Randomizes memory segment locations to thwart ROP attacks.

Question 9

PIE Support - EM

Answer 9

Randomizes all memory components for ASLR, including app_process and linker.

Question 10

RELRO and BIND_NOW - EM

Answer 10

Makes process data sections read-only to prevent GOT overwrites.

Question 11

FORTIFY_SOURCE L1 - EM

Answer 11

Substitutes vulnerable C functions to prevent memory corruption.

Question 12

FORTIFY_SOURCE L2 - EM

Answer 12

Enhances protection with fortified function versions.

Question 13

SELinux Permissive - EM

Answer 13

Implements access control policies, logging without enforcement.

Question 14

SELinux Enforcing - EM

Answer 14

Actively enforces specified security policies.

Question 15

Understanding the Security Model

Answer 15

The security model requires a definition of authorized actions for apps.

Apps must know what they can do and whether other apps are authorized for specific actions.

This requires a clearly defined concept of app identity.

Question 16

Rooting

Answer 16

Methods include placing an ‘su’ binary in /system/bin or xbin.

In code:
Runtime.getRuntime().exec(new String[]{“su”, “-c”, “id”});

Android root manager applications prompt the user for permission.

Post-exploit custom version of ‘su’, for persistence: provided by drozer in the ‘tools.setup.minimalsu’ module.

^^ Uses setuid(0) & setgid(0) for no user prompts.

Question 17

Rooting Methods

Answer 17

Common rooting methods involve using exploits or leveraging unlocked bootloaders.

Question 18

Using an Exploit - Gingerbreak

Answer 18

The Gingerbreak exploit targets the Volume Manager (vold) in Android versions 2.2 to 3.0.

It involves an array access error and manipulation of the Global Offset Table (GOT) to execute the ‘sh’ binary as root.

Users need to have ‘log’ group access to exploit this vulnerability.

Question 19

Using an Exploit – Exynos Abuse – Exploiting Custom Drivers

Answer 19

Custom drivers for hardware can contain vulnerabilities.

An exploit found in Samsung Galaxy S3 devices with Exynos.

Involved a block device, /dev/exynos-
mem, which allowed mapping kernel memory to user
space.

The exploit altered code comparisons (setresuid), granting root access.

Bypassed kptr_restrict, which normally prevents applications from reading kernel pointers.

Question 20

Using an Exploit – Samsung Admire Vulnerability via Symlinks

Answer 20

Loose file permissions in Samsung Admire allowed root access.

An attacker created a symlink and triggered an app crash to write files with world-writable permissions.

This exploit was specific to Samsung Admire.

Question 21

Using an Exploit – Acer Iconia – Exploiting SUID Binaries

Answer 21

SUID binaries owned by root and executable by anyone are prime targets for root exploit developers.

A vulnerability in the Acer Iconia A100’s SUID binary named cmdclient allowed command injection, enabling arbitrary command execution with root privileges.

Question 22

Reverse-Engineering Applications

Answer 22

Reverse-engineering is the process of analyzing and understanding applications without source code.

Tools like Dexdump, Smali, Baksmali, Dex2jar, JD-GUI, and Apktool help with disassembling and decompiling applications.

Question 23

Disassembling DEX Bytecode

Answer 23

DEX files contain Dalvik bytecode, which can be converted into a low-level assembly format.

The ‘dexdump’ tool is used for disassembling DEX files.

Smali and Baksmali are tools that help convert DEX files into more readable class files.

Question 24

Decompiling DEX Bytecode

Answer 24

Decompiling DEX files can be more informative than disassembled code.

Dex2jar is a tool for converting DEX files to Java Class files.

JD-GUI can decompile JAR files back into Java source code.

Question 25

Decompiling Optimized DEX Bytecode

Answer 25

DEX files for system apps are typically pre-optimized and stored as ODEX files.

The ‘oatdump’ tool can disassemble OAT files.

Tools like ‘oat2dex’ can extract DEX files from OAT files.

Question 26

Reversing Native Code in Android

Answer 26

Native components in Android apps are often in machine code for ARM, x86, or MIPS.

Tools like IDA, Apktool, Jadx, and JAD assist in reverse-engineering native code.

Android’s ART system converts DEX files into OAT files, which can also be reverse-engineered.

Question 27

Dealing with ART

Answer 27

The ‘oatdump’ tool can disassemble OAT files, similar to ‘dexdump’ for DEX files.

‘oat2dex’ is a script that extracts DEX files from OAT files for reverse engineering.