Lewis University Computer Security Programming Worksheet

SEED Labs – SQL Injection Attack Lab1
SQL Injection Attack Lab
Copyright © 2006 – 2020 by Wenliang Du.
This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International
License. If you remix, transform, or build upon the material, this copyright notice must be left intact, or
reproduced in a way that is reasonable to the medium in which the work is being re-published.
1
Overview
SQL injection is a code injection technique that exploits the vulnerabilities in the interface between web
applications and database servers. The vulnerability is present when user’s inputs are not correctly checked
within the web applications before being sent to the back-end database servers.
Many web applications take inputs from users, and then use these inputs to construct SQL queries, so
they can get information from the database. Web applications also use SQL queries to store information in
the database. These are common practices in the development of web applications. When SQL queries are
not carefully constructed, SQL injection vulnerabilities can occur. SQL injection is one of the most common
attacks on web applications.
In this lab, we have created a web application that is vulnerable to the SQL injection attack. Our web
application includes the common mistakes made by many web developers. Students’ goal is to find ways to
exploit the SQL injection vulnerabilities, demonstrate the damage that can be achieved by the attack, and
master the techniques that can help defend against such type of attacks. This lab covers the following topics:
• SQL statements: SELECT and UPDATE statements
• SQL injection
• Prepared statement
Readings. Detailed coverage of the SQL injection can be found in the following:
• Chapter 12 of the SEED Book, Computer & Internet Security: A Hands-on Approach, 2nd Edition,
by Wenliang Du. See details at https://www.handsonsecurity.net.
Lab Environment. This lab has been tested on our pre-built Ubuntu 20.04 VM, which can be downloaded
from the SEED website. Since we use containers to set up the lab environment, this lab does not depend
much on the SEED VM. You can do this lab using other VMs, physical machines, or VMs on the cloud.
2
Lab Environment
We have developed a web application for this lab, and we use containers to set up this web application.
There are two containers in the lab setup, one for hosting the web application, and the other for hosting the
database for the web application. The IP address for the web application container is 10.9.0.5, and The
URL for the web application is the following:
http://www.seed-server.com
We need to map this hostname to the container’s IP address. Please add the following entry to the
/etc/hosts file. You need to use the root privilege to change this file (using sudo). It should be noted
that this name might have already been added to the file due to some other labs. If it is mapped to a different
IP address, the old entry must be removed.
SEED Labs – SQL Injection Attack Lab
10.9.0.5
2.1
2
www.seed-server.com
Container Setup and Commands
Please download the Labsetup.zip file to your VM from the lab’s website, unzip it, enter the Labsetup
folder, and use the docker-compose.yml file to set up the lab environment. Detailed explanation of the
content in this file and all the involved Dockerfile can be found from the user manual, which is linked
to the website of this lab. If this is the first time you set up a SEED lab environment using containers, it is
very important that you read the user manual.
In the following, we list some of the commonly used commands related to Docker and Compose. Since
we are going to use these commands very frequently, we have created aliases for them in the .bashrc file
(in our provided SEEDUbuntu 20.04 VM).
$ docker-compose build
$ docker-compose up
$ docker-compose down
# Build the container image
# Start the container
# Shut down the container
// Aliases for the Compose commands above
$ dcbuild
# Alias for: docker-compose build
$ dcup
# Alias for: docker-compose up
$ dcdown
# Alias for: docker-compose down
All the containers will be running in the background. To run commands on a container, we often need
to get a shell on that container. We first need to use the “docker ps” command to find out the ID of
the container, and then use “docker exec” to start a shell on that container. We have created aliases for
them in the .bashrc file.
$ dockps
$ docksh
// Alias for: docker ps –format “{{.ID}} {{.Names}}”
// Alias for: docker exec -it /bin/bash
// The following example shows how to get a shell inside hostC
$ dockps
b1004832e275 hostA-10.9.0.5
0af4ea7a3e2e hostB-10.9.0.6
9652715c8e0a hostC-10.9.0.7
$ docksh 96
root@9652715c8e0a:/#
// Note: If a docker command requires a container ID, you do not need to
//
type the entire ID string. Typing the first few characters will
//
be sufficient, as long as they are unique among all the containers.
If you encounter problems when setting up the lab environment, please read the “Common Problems”
section of the manual for potential solutions.
MySQL database. Containers are usually disposable, so once it is destroyed, all the data inside the containers are lost. For this lab, we do want to keep the data in the MySQL database, so we do not lose
our work when we shutdown our container. To achieve this, we have mounted the mysql data folder
on the host machine (inside Labsetup, it will be created after the MySQL container runs once) to the
/var/lib/mysql folder inside the MySQL container. This folder is where MySQL stores its database.
SEED Labs – SQL Injection Attack Lab
3
Therefore, even if the container is destroyed, data in the database are still kept. If you do want to start from
a clean database, you can remove this folder:
$ sudo rm -rf mysql_data
2.2
About the Web Application
We have created a web application, which is a simple employee management application. Employees can
view and update their personal information in the database through this web application. There are mainly
two roles in this web application: Administrator is a privilege role and can manage each individual
employees’ profile information; Employee is a normal role and can view or update his/her own profile
information. All employee information is described in Table 1.
Table 1: Database
Name
Admin
Alice
Boby
Ryan
Samy
Ted
Employee ID
99999
10000
20000
30000
40000
50000
Password
seedadmin
seedalice
seedboby
seedryan
seedsamy
seedted
Salary
400000
20000
50000
90000
40000
110000
Birthday
3/5
9/20
4/20
4/10
1/11
11/3
3
Lab Tasks
3.1
Task 1: Get Familiar with SQL Statements
SSN
43254314
10211002
10213352
32193525
32111111
24343244
Nickname
Email
Address
Phone#
The objective of this task is to get familiar with SQL commands by playing with the provided database. The
data used by our web application is stored in a MySQL database, which is hosted on our MySQL container.
We have created a database called sqllab users, which contains a table called credential. The table
stores the personal information (e.g. eid, password, salary, ssn, etc.) of every employee. In this task, you
need to play with the database to get familiar with SQL queries.
Please get a shell on the MySQL container (see the container manual for instruction; the manual is linked
to the lab’s website). Then use the mysql client program to interact with the database. The user name is
root and password is dees.
// Inside the MySQL container
# mysql -u root -pdees
After login, you can create new database or load an existing one. As we have already created the
sqllab users database for you, you just need to load this existing database using the use command. To
show what tables are there in the sqllab users database, you can use the show tables command to
print out all the tables of the selected database.
mysql> use sqllab_users;
Database changed
mysql> show tables;
+————————+
| Tables_in_sqllab_users |
+————————+
SEED Labs – SQL Injection Attack Lab
4
| credential
|
+————————+
After running the commands above, you need to use a SQL command to print all the profile information
of the employee Alice. Please provide the screenshot of your results.
3.2
Task 2: SQL Injection Attack on SELECT Statement
SQL injection is basically a technique through which attackers can execute their own malicious SQL statements generally referred as malicious payload. Through the malicious SQL statements, attackers can steal
information from the victim database; even worse, they may be able to make changes to the database. Our
employee management web application has SQL injection vulnerabilities, which mimic the mistakes frequently made by developers.
We will use the login page from www.seed-server.com for this task. The login page is shown in
Figure 1. It asks users to provide a user name and a password. The web application authenticate users based
on these two pieces of data, so only employees who know their passwords are allowed to log in. Your job,
as an attacker, is to log into the web application without knowing any employee’s credential.
Figure 1: The Login page
To help you started with this task, we explain how authentication is implemented in the web application.
The PHP code unsafe home.php, located in the /var/www/SQL_Injection directory, is used to
conduct user authentication. The following code snippet show how users are authenticated.
$input_uname = $_GET[’username’];
$input_pwd = $_GET[’Password’];
$hashed_pwd = sha1($input_pwd);
…
$sql = “SELECT id, name, eid, salary, birth, ssn, address, email,
nickname, Password
FROM credential
WHERE name= ’$input_uname’ and Password=’$hashed_pwd’”;
$result = $conn -> query($sql);
SEED Labs – SQL Injection Attack Lab
5
// The following is Pseudo Code
if(id != NULL) {
if(name==’admin’) {
return All employees information;
} else if (name !=NULL){
return employee information;
}
} else {
Authentication Fails;
}
The above SQL statement selects personal employee information such as id, name, salary, ssn etc from
the credential table. The SQL statement uses two variables input uname and hashed pwd, where
input uname holds the string typed by users in the username field of the login page, while hashed pwd
holds the sha1 hash of the password typed by the user. The program checks whether any record matches
with the provided username and password; if there is a match, the user is successfully authenticated, and is
given the corresponding employee information. If there is no match, the authentication fails.
Task 2.1: SQL Injection Attack from webpage. Your task is to log into the web application as the
administrator from the login page, so you can see the information of all the employees. We assume that
you do know the administrator’s account name which is admin, but you do not the password. You need to
decide what to type in the Username and Password fields to succeed in the attack.
Task 2.2: SQL Injection Attack from command line. Your task is to repeat Task 2.1, but you need to
do it without using the webpage. You can use command line tools, such as curl, which can send HTTP
requests. One thing that is worth mentioning is that if you want to include multiple parameters in HTTP
requests, you need to put the URL and the parameters between a pair of single quotes; otherwise, the special
characters used to separate parameters (such as &) will be interpreted by the shell program, changing the
meaning of the command. The following example shows how to send an HTTP GET request to our web
application, with two parameters (username and Password) attached:
$ curl ’www.seed-server.com/unsafe_home.php?username=alice&Password=11’
If you need to include special characters in the username or Password fields, you need to encode
them properly, or they can change the meaning of your requests. If you want to include single quote in those
fields, you should use %27 instead; if you want to include white space, you should use %20. In this task,
you do need to handle HTTP encoding while sending requests using curl.
Task 2.3: Append a new SQL statement. In the above two attacks, we can only steal information from
the database; it will be better if we can modify the database using the same vulnerability in the login page.
An idea is to use the SQL injection attack to turn one SQL statement into two, with the second one being
the update or delete statement. In SQL, semicolon (;) is used to separate two SQL statements. Please try to
run two SQL statements via the login page.
There is a countermeasure preventing you from running two SQL statements in this attack. Please use
the SEED book or resources from the Internet to figure out what this countermeasure is, and describe your
discovery in the lab report.
SEED Labs – SQL Injection Attack Lab
3.3
6
Task 3: SQL Injection Attack on UPDATE Statement
If a SQL injection vulnerability happens to an UPDATE statement, the damage will be more severe, because attackers can use the vulnerability to modify databases. In our Employee Management application,
there is an Edit Profile page (Figure 2) that allows employees to update their profile information, including
nickname, email, address, phone number, and password. To go to this page, employees need to log in first.
When employees update their information through the Edit Profile page, the following SQL UPDATE
query will be executed. The PHP code implemented in unsafe edit backend.php file is used to update employee’s profile information. The PHP file is located in the /var/www/SQLInjection directory.
$hashed_pwd = sha1($input_pwd);
$sql = “UPDATE credential SET
nickname=’$input_nickname’,
email=’$input_email’,
address=’$input_address’,
Password=’$hashed_pwd’,
PhoneNumber=’$input_phonenumber’
WHERE ID=$id;”;
$conn->query($sql);
Figure 2: The Edit-Profile page
Task 3.1: Modify your own salary. As shown in the Edit Profile page, employees can only update
their nicknames, emails, addresses, phone numbers, and passwords; they are not authorized to change their
salaries. Assume that you (Alice) are a disgruntled employee, and your boss Boby did not increase your
salary this year. You want to increase your own salary by exploiting the SQL injection vulnerability in the
Edit-Profile page. Please demonstrate how you can achieve that. We assume that you do know that salaries
are stored in a column called salary.
SEED Labs – SQL Injection Attack Lab
7
SQL Statement Execution Phases
Compilation
Parsing & Normalization
Phase
Execution
Compilation Phase
Execution Phase
Query Optimization
Phase
Cache
In this state, the SQL statement is
pre‐compiled into binary. Only
placeholders for data are included in
the prepared statement, not the
actual data. Data will be binded to
this statement later as pure data (so
no more compilation will be
conducted).
Figure 3: Prepared Statement Workflow
Task 3.2: Modify other people’ salary. After increasing your own salary, you decide to punish your boss
Boby. You want to reduce his salary to 1 dollar. Please demonstrate how you can achieve that.
Task 3.3: Modify other people’ password. After changing Boby’s salary, you are still disgruntled, so
you want to change Boby’s password to something that you know, and then you can log into his account and
do further damage. Please demonstrate how you can achieve that. You need to demonstrate that you can
successfully log into Boby’s account using the new password. One thing worth mentioning here is that the
database stores the hash value of passwords instead of the plaintext password string. You can again look at
the unsafe edit backend.php code to see how password is being stored. It uses SHA1 hash function
to generate the hash value of password.
3.4
Task 4: Countermeasure — Prepared Statement
The fundamental problem of the SQL injection vulnerability is the failure to separate code from data. When
constructing a SQL statement, the program (e.g. PHP program) knows which part is data and which part
is code. Unfortunately, when the SQL statement is sent to the database, the boundary has disappeared; the
boundaries that the SQL interpreter sees may be different from the original boundaries that was set by the
developers. To solve this problem, it is important to ensure that the view of the boundaries are consistent in
the server-side code and in the database. The most secure way is to use prepared statement.
To understand how prepared statement prevents SQL injection, we need to understand what happens
when SQL server receives a query. The high-level workflow of how queries are executed is shown in
Figure 3. In the compilation step, queries first go through the parsing and normalization phase, where a query
is checked against the syntax and semantics. The next phase is the compilation phase where keywords (e.g.
SELECT, FROM, UPDATE, etc.) are converted into a format understandable to machines. Basically, in this
phase, query is interpreted. In the query optimization phase, the number of different plans are considered to
execute the query, out of which the best optimized plan is chosen. The chosen plan is store in the cache, so
whenever the next query comes in, it will be checked against the content in the cache; if it’s already present
SEED Labs – SQL Injection Attack Lab
8
in the cache, the parsing, compilation and query optimization phases will be skipped. The compiled query
is then passed to the execution phase where it is actually executed.
Prepared statement comes into the picture after the compilation but before the execution step. A prepared statement will go through the compilation step, and be turned into a pre-compiled query with empty
placeholders for data. To run this pre-compiled query, data need to be provided, but these data will not go
through the compilation step; instead, they are plugged directly into the pre-compiled query, and are sent
to the execution engine. Therefore, even if there is SQL code inside the data, without going through the
compilation step, the code will be simply treated as part of data, without any special meaning. This is how
prepared statement prevents SQL injection attacks.
Here is an example of how to write a prepared statement in PHP. We use a SELECT statement in the
following example. We show how to use prepared statement to rewrite the code that is vulnerable to SQL
injection attacks.
$sql = “SELECT name, local, gender
FROM USER_TABLE
WHERE id = $id AND password =’$pwd’ “;
$result = $conn->query($sql)
The above code is vulnerable to SQL injection attacks. It can be rewritten to the following
$stmt = $conn->prepare(“SELECT name, local, gender
FROM USER_TABLE
WHERE id = ? and password = ? “);
// Bind parameters to the query
$stmt->bind_param(“is”, $id, $pwd);
$stmt->execute();
$stmt->bind_result($bind_name, $bind_local, $bind_gender);
$stmt->fetch();
Using the prepared statement mechanism, we divide the process of sending a SQL statement to the
database into two steps. The first step is to only send the code part, i.e., a SQL statement without the actual
the data. This is the prepare step. As we can see from the above code snippet, the actual data are replaced
by question marks (?). After this step, we then send the data to the database using bind param(). The
database will treat everything sent in this step only as data, not as code anymore. It binds the data to the
corresponding question marks of the prepared statement. In the bind param() method, the first argument
“is” indicates the types of the parameters: “i” means that the data in $id has the integer type, and “s”
means that the data in $pwd has the string type.
Task. In this task, we will use the prepared statement mechanism to fix the SQL injection vulnerabilities.
For the sake of simplicity, we created a simplified program inside the defense folder. We will make
changes to the files in this folder. If you point your browser to the following URL, you will see a page
similar to the login page of the web application. This page allows you to query an employee’s information,
but you need to provide the correct user name and password.
URL: http://www.seed-server.com/defense/
The data typed in this page will be sent to the server program getinfo.php, which invokes a program
called unsafe.php. The SQL query inside this PHP program is vulnerable to SQL injection attacks. Your
job is modify the SQL query in unsafe.php using the prepared statement, so the program can defeat SQL
injection attacks. Inside the lab setup folder, the unsafe.php program is in the image_www/Code/
defense folder. You can directly modify the program there. After you are done, you need to rebuild and
SEED Labs – SQL Injection Attack Lab
9
restart the container, or the changes will not take effect.
You can also modify the file while the container is running. On the running container, the unsafe.php
program is inside /var/www/SQL_Injection/defense. The downside of this approach is that in
order to keep the docker image small, we have only installed a very simple text editor called nano inside
the container. It should be sufficient for simple editing. If you do not like this editor, you can always use
“apt install” to install your favoriate command-line editor inside the container. For example, for
people who like vim, you can do the following:
# apt install -y vim
This installation will be discarded after the container is shutdown and destroyed. If you want to make it
permanent, add the installation command to the Dockerfile inside the image_www folder.
4
Guidelines
Test SQL Injection String. In real-world applications, it may be hard to check whether your SQL injection attack contains any syntax error, because usually servers do not return this kind of error messages. To
conduct your investigation, you can copy the SQL statement from php source code to the MySQL console.
Assume you have the following SQL statement, and the injection string is ’ or 1=1;#.
SELECT * from credential
WHERE name=’$name’ and password=’$pwd’;
You can replace the value of $name with the injection string and test it using the MySQL console. This
approach can help you construct a syntax-error free injection string before launching the real attack.
5
Submission
You need to submit a detailed lab report, with screenshots, to describe what you have done and what you
have observed. You also need to provide explanation to the observations that are interesting or surprising.
Please also list the important code snippets followed by explanation. Simply attaching code without any
explanation will not receive credits.
Name:
Score: ___/50
CPSC 42200 Lab 6: Android Vulnerabilities with DIVA pt. 1
In this lab you will use the Android system emulator you installed previously to investigate
vulnerabilities with the DIVA app.
Setup: Install BusyBox and Diva (5 pts)
Use adb to install the BusyBox and Diva APKs provided on the course Blackboard site on your emulated
phone. Then, drag the app icons onto the emulated phone’s home screen.
Paste here a screenshot of the emulator showing both the app icons on the home screen:
Vulnerability 1. Insecure Logging Demo (7 pts)
Run DIVA and select vulnerability #1, “Insecure Logging”. Enter an easy-to-remember fake 16-digit credit
card number. Then, from the adb device shell, search the device logs and find the logged credit card
number (you may wish to use BusyBox.)
Paste a screenshot or screenshots here showing the command you gave to search the logs, and the
resulting credit card number shown in the log:
Vulnerability 2. Hard-coded Secrets (7 pts)
For this part you must extract a vendor key from the Diva APK. You will need to extract the Java
bytecode from the APK, convert it to JAR format, and use a decompiler to view the source code of a
certain class that has the secret in it.
Once you find the secret value, enter it into item #2 on the DIVA app to verify that it works. Then, paste
here a screenshot of the decompiler GUI showing the class file with the secret value highlighted:
Vulnerability 3: Insecure Credential Storage 1 (7 pts)
In the DIVA app, launch task 3 and enter a username and password of your choice, then press “save.” As
in the previous task, use the decompiler to look at the java class file for this vulnerability. Find the
function that saves the credentials; the class names used for the “editor” object may give a hint about
where they are being stored. Then, go to the debug shell and look in DIVA application’s data folder for
the file storing these credentials in plaintext.
Paste a screenshot of your terminal window showing the filename of the data file containing the
credentials, and its contents.
Vulnerability 4: Insecure Credential Storage 2 (7 pts)
This vulnerability is similar to the previous, except that the credentials are stored in a SQLite3 database.
In the DIVA app, launch task 4 and save a username and password of your choice. Once again, use the
decompiler to look at the Java class file for this vulnerability, to get an idea as to which database and
table stores the credentials. Then, go to the adb shell, find the database file in the app data folders, and
use sqlite3 to find the stored plaintext credentials.
Paste a screenshot or screenshots showing the command line that you used to start sqlite3, and the
sqlite3 commands you used to find and display the credentials from the database.
Vulnerability 5: Insecure Credential Storage 3 (7 pts)
This vulnerability is similar to the previous, except that the credentials are stored in a temporary file. In
the DIVA app, launch task 5 and save a username and password of your choice. Once again, use the
decompiler to look at the Java class file for this vulnerability to get an idea of what the temp file may be
named. Then, go to the adb shell, find the file, and view its contents.
Paste a screenshot of your terminal window showing the filename of the data file containing the
credentials, and its contents.
Vulnerability 6: Insecure Credential Storage 4 (10 pts)
In this vulnerability, the credentials are insecurely saved to the external storage (SD card.) In the DIVA
app, launch task 6 and attempt to save a username and password of your choice. What error message
do you get? Why do you think you get this error?
In the emulator, go to the phone settings and find the place where you can give the DIVA app the
necessary permissions. Take a screenshot of the settings screen where you made this change and paste
it here:
Now you can successfully save the credentials. Look in the decompiled code to see the filename where
the credentials are stored, then find the file in the shell.
Paste a screenshot of your terminal window showing the filename of the data file containing the
credentials, and its contents.
Name:
Score: ___/100
CPSC 42200 Lab 7: Android Vulnerabilities with DIVA pt. 2
In this lab you will continue to use the Android system emulator plus reverse engineering tools to
investigate vulnerabilities with the DIVA app.
Vulnerability 7: Input Validation Issues 1
The tool in DIVA task 7 is a simple SQL database search interface for finding user information. First, try
entering the username “diva” and seeing what information is displayed. Then, find a search string that
you can input into DIVA Task 7 that will show you the user information of all users (hint: SQL injection).
Paste a screenshot of the emulator window showing the search string as well as the user information
(you’ll have to be quick to get the screenshot before the pop-up fades out.)
Vulnerability 8: Input Validation Issues 2
The tool in task 8 is meant to open a URL in a web browser. First, try it with a normal website URL like
https://www.google.com. Then, find a URL that you can put into the field that will show you the
contents of an XML configuration file on the phone.
Paste a screenshot of the emulator window showing your malicious URL and the file information on the
screen.
Vulnerability 9: API Credentials Exposed as Activity.
The app used for obtaining API credentials in the UI has a vulnerability, in that it registers an activity
that is viewable and can be triggered by other apps on the system.
First, use logcat to find the full name of the activity used by the diva app for the credentials screen.
Next, use apktool to extract DivaApplication.apk and get a text-formatted version of
“AndroidManifest.xml”. Look for the “APICredsActivity” and find the name of the specific action that will
show the credentials.
Then, from the root adb shell, use the am start command, using the -n option to start the found
activity by its name, and the -a option to trigger the action by its name. This simulates pressing the
button, and you should see the app screen change to show the credentials. This illustrates that any app
can obtain the credentials by triggering the activity.
Paste a screenshot or screenshots showing 1) the output of logcat with the activity name, and the
successful start of the activity using the am command.
Vulnerability 10: API Credentials as Activity without PIN
In this task, the goal is the same—to trigger showing the API credentials from outside of the app,
without clicking the button. However, this activity seems to have some additional protection.
As with the previous task, look at the “AndroidManifest.xml” file to see which action to trigger. You can
also figure out the activity name from this file, without using logcat—just remember that a slash is
needed in a certain position.
You may try to trigger this action, but you will find that this only makes the app show the PIN entry
screen. You need to give an additional flag to indicate that the user has already registered (you don’t
need the PIN itself.)
To track down what the flag is, first, we go back to the Java decompiler you used in the previous lab.
Open the “classes-dex2jar.jar” that you created previously, then look at “APICreds2Activity.class”. Find
the code that checks a condition before displaying the credential text. It checks that a string option
indexed by a certain number is NOT true. Copy this number, then open “R.class” and search for that
number to find the variable name of that string.
We’re not done yet! Now you have to find the actual string option’s value, which is stored as a resource.
In your decompiled application folder, go to the subfolder res/values/ and open “strings.xml”. Find
the string corresponding to the variable name you got. Now start the activity, but use the additional flag
–ez to set the Boolean string option your found to false. If you do it correctly, there should be no errors
and the app should show the credential screen.
Paste 2 screenshots: 1) The decompiler showing “R.class” with the required variable highlighted; 2) The
command prompt showing the full command to trigger the action with the flag.
Vulnerability 11: Application data insecurely exposed through content provider
Launch task 11, select a PIN, and then re-enter it to view the private notes data. You will discover how to
view this application’s data without entering the PIN, since it is exposed as a content provider.
In the Java decompiler, open “NotesProvider.class” and find the URI of the content provider used by this
activity. Then, from the adb shell, enter the command to get the content provider data by its URI.
Paste a screenshot showing your terminal with the command in the adb shell and the notes data
displayed.
Vulnerability 12: Hard-coded sensitive data part 2
Once again, we want to find the secret vendor key that is hard-coded somewhere in the application.
Look at “Hardcode2activity.class” in the decompiler and note that the secret is stored in an object of
type “DivaJni”. “Jni” stands for “Java Native Interface”, which indicates that this secret is stored in a
native code file. Look at “DivaJni.class” to see the name of the library that is loaded.
In the app folder that you extracted with apktool, search for a file whose name starts with “lib”,
followed by the library name you found, followed by “.so”. This is the shared library file with the native
code in it.
To find hard-coded ASCII data (such as passwords) in a binary file, we can use the “strings” command,
which finds all printable strings within any file type. This commanded is included in all Linux
distributions. You can download a version of “strings” for Windows at https://docs.microsoft.com/enus/sysinternals/downloads/strings .
Use “strings” and look for a string that appears like an ascii password, as opposed to a function or file
name, and type it in the app. You may need to try several strings to find the right one.
Paste a screenshot showing the output of the “strings” command on the library file, with the correct
password highlighted.
Vulnerability 13: Input Validation Issues
The goal in this task is simply to crash the DIVA application by entering a string into the blank. If you
know anything about buffer overflow, then you probably have an idea of what to do. If you successfully
crash the app, it will simply restart, as opposed to giving an “access denied” message.
Paste a screenshot of the phone emulator showing the input you enter to crash the program (before you
push the button and it crashes.)
Name:
Score: ___/50
CPSC 42200 Wireless Security Lab 5: Android Emulator Setup and Root
Shell Exploration
In this lab you will set up an Android system emulator on your own computer, allowing you to further
explore the security features of this mobile operating system.
Part 1. Install Procedure With Evidence
1. Download and install Android Studio (https://developer.android.com/studio) on your machine.
Once it is installed, run it and create a new project of type “Basic Activity”. Name the activity
“CPSC 42200 Sandbox”. You can leave the default settings for everything else. Once the IDE
opens with the code view, you will still need to wait a while for it to download more packages
and sort everything out. If you get error messages, just try to close them and let things go on.
2. Once everything settles down, click on the “Device Manager” tab on the right side of the screen.
Create a new Pixel 2 virtual device; on the “Select a System Image” dialog, choose the “x86
images” tab and select the Android 11.0 (Google APIs) (not Google Play) OS image.
3. Start the emulator, and power on the phone if necessary, so that you see the Android home
screen running in the virtual device. You may need to start the phone buy starting the app with
the green “play” button in the upper right.
Take a screenshot of the entire Android Studio window, showing the running emulator, and
paste it below:
4. Add the folder containing the Android Debug Bridge executable, “adb.exe” to your system
PATH.
5. Open a Command Prompt or Terminal and enter 1) the command to display the list of devices
connected to the debug bridge; 2) the command to restart the bridge in root mode, and 3) the
command to start the shell session on the device.
Paste a screenshot showing all of these commands and the resulting root shell prompt on the
virtual Android device:
Part 2. Questions
Answer the following questions by issuing commands in the connected ADB root shell. You may consult
online references if you do not know the necessary commands.
6. What is the command to view all processes running on the system?
7. How many processes in total are running on the emulated device?
8. What is the form of the username for the per-application accounts on an android device?
9. How many processes are running under such accounts?
10. What is the command to view system services? How many services are running on the machine?
11. Give the full path to the data folder of the “messaging” app.