Posted all remaining labs

labs/lab09-riskanalysis.md

@@ -0,0 +1,39 @@
+# Lab: Technical Risk Analysis
+
+## Objectives
+1. Perform a technical risk analysis of a vulnerable system.
+
+## Instructions
+
+You will need to download the entire CTF game source code. Link: https://www.cs.tufts.edu/comp/116/ctf-spring2024.zip (`SHA256(ctf-spring2024.zip)=01cd550167be22700abe56e7d11e2ef2a3554354847c2c709dba7c48ff701404`). This file contains the website including web files.
+
+**10 points.** While the goal of our CTF game was to find and exploit vulnerabilities in a system (i.e., flags), you also performed a number of activities, not limited to:
+
+* Penetration testing
+* "Ethical hacking"
+* Conducting research
+* Gathering artifacts
+* Interviewing people
+
+Imagine that you are a managing consultant for a major security company or the Chief Security Officer (CSO) for the company that owned the system, and assume that the business context of the system is critical, perform a technical risk analysis of the Capture The Flags (CTF) system. That is, you are to apply a general risk management framework (largely taken from Cigital's Risk Management Framework). This framework can be used by managers and software engineers to identify, track, rank, monitor, and understand risks for a project or system. The output of this activity shall be a table with eight columns:
+
+| Column Name | Information | Example (an actual example you can use) |
+|-------------|-------------|-----------------------------------------|
+| *Risk ID* | A sequential identifier for risk | 1 |
+| *Technical Risk* | Brief description | User authentication to the WordPress blog can be brute-forced. |
+| *Techical Risk Indicators* | Evidence of the risk occurring. | Number of incorrect logins for accounts seen in logs; performance of login server has been degrading. |
+| *Related CWE or CVE IDs* | Use comma to separate multiple IDs | CWE-521: https://cwe.mitre.org/data/definitions/521.html  |
+| *Impact Rating* | Use NIST standard: (H)igh, (M)edium, (L)ow | H |
+| *Impact* | Possible results of the risk, impacting the goals of the product. | Increased load on login server; slower performance; possible denial of service |
+| *Mitigation* | Action taken to reduce the probability of the risk actually occurring or how to actually fix the bug. There may be more than one way to mitigate a risk. | Lock out user account on 5 incorrect password tries by setting account lockout flag to true. |
+| *Validation Steps* | How do you ensure that risk was mitigated? | Account lockout flag set for user account on 5 incorrect password tries. |
+
+In practice and in industry, the technical risk analysis table is used to correlate with business risks. Your job is to produce a technical risk table for the entire CTF game. Each of the vulnerabilities that you found in the CTF game should be a technical risk.
+
+Table shall be submitted in one PDF file.
+
+Important: be sure to review the CTF game source code as there are other vulnerabilities that were not visible via playing game.
+
+**OPTIONAL HIGHLY RECOMMEND +0.1 BONUS.** Create and run a static analysis scan of either (1) the Capture The Flags (CTF) game files or (2) an application of your choice, such as your own C/C++, iOS, or Android app using Veracode's Static Analysis tool via https://web.analysiscenter.veracode.com/. Email me if you want an account (free academic license). Please consult with Help (the question mark icon on upper-right corner of screen) for instructions on how to package your application for submission for static analysis scan.
+
+Veracode is an application security company based in Burlington, Massachusetts. Founded in 2006, the company provides an automated cloud-based service for securing web, mobile and third-party enterprise applications. Veracode was co-founded by friend, mentor, and cyber security luminary Chris Wysopal a.k.a., "Weld Pond" --read https://www.washingtonpost.com/sf/business/2015/06/22/net-of-insecurity-part-3/. Veracode is a commercial product but Chris and his team has granted me academic license since fall 2013. Please also read his guest lecture notes (from spring 2012) at https://cs116.org/readings/static-binary-analysis-wysopal-tufts-comp-116.pdf.

labs/lab10-malware.md

@@ -0,0 +1,56 @@
+# Lab: Android Malware Analysis
+
+## Objectives
+1. Analyze and reverse engineer a malicious Android app
+
+## Overview
+In this lab, you will analyze and reverse engineer a malicious Android app.  The point of malware analysis is to understand what the malware does.  The number of malicious Android apps is staggering.  "Every week or so, there’s a new form of Android malware discovered that works in a unique way from what's come before" [1].
+
+### About Android Apps
+Java is the official programming language used to write Android apps.  An Android app is contained in an APK file (Android Package Kit).  An APK file is actually in ZIP format, an archive.  Provided an APK file, you can extract the contents of the app and decompile the app.
+
+### Unzipping the APK file
+Unzipping the APK file via `unzip <name_of_app.apk>` will extract the following contents:
+
+* `AndroidManifest.xml` - contains app configuration details including app permissions, entry classes, API keys; _not human readable_
+* `META-INF`  (directory) - information about the digital signature of the app
+* _`classes.dex` - a single file, compiled and assembled app code; not human readable_
+* `resources.arsc` - contains precompiled resources
+* `res` (directory) - resources not compiled into `resources.arsc` including images, strings, and layouts
+
+### Tool: `apktool`
+`apktool` is used to extract the contents of an APK file.  The contents can be edited.  `apktool` can also be used to rebuild a modified app.  As you can imagine, by modifying contents extracted from an APK file including adding new files, you can build a malicious version of the app.  The output of `apktool` will be a set of files:
+
+* A human readable version of the `AndroidManifest.xml` file
+* `smali` (directory)
+
+Of interest is the content in the `smali` directory.  Smali is an assembler for the DEX format used by Dalvik.  In other words, Smali is assembly code, more human readable.  There is a tool `baksmali` that takes in a `.dex` file as input and the output will be `.smali` files.
+
+## Instructions
+
+Download and unzip the following ZIP file containing Android APK: https://www.cs.tufts.edu/comp/116/sample-spring2024.zip SHA256(sample-spring2024.zip)=`64c23cf9d7f20a8bf7425466b6d696fc115e72b5bb21e95d2d33d810b2e91b83` **WARNING: DO NOT INSTALL THIS APP ONTO YOUR PRIMARY ANDROID DEVICE AS THIS IS LIVE MALWARE!** Answer the following questions:
+
+1. Scan the APK file using VirusTotal. What is the detection ratio as returned by VirusTotal?
+
+2. Using apktool, extract the contents of the APK file via `apktool d <name_of_app.apk>`. Take a look at the `AndroidManifest.xml` file. What permissions do the app have access to? Do any of the permissions look peculiar?
+
+3. Take a further look at the `AndroidManifest.xml` file, are there any peculiar activities or Java packages referenced?
+
+4. Take a look at all the files in the resources folder `res`. Are there any files that look suspicious?
+
+5. Find and list any suspicious HTTP and/or HTTPS URLs used in `.smali` files. In which `.smail` file(s) did you find suspicious HTTP and/or HTTPS URLs?  If you find any suspicious URLs, send them to VirusTotal for analysis, and provide the VirusTotal detection ratio for each URL.
+
+6. What does this app really do, or what do you think this app really do? Provide a brief synopsis. Show all evidence including lines of code in question, and cite any references.
+
+### Optional Tools to Use: `dex2jar` and `JD-GUI`
+One of the outputs of unzipping the contents of an APK file is `classes.dex`, compiled and assembled app code.  A `.dex` file is a compiled Android application code file.  Android programs are compiled into `.dex` (Dalvik Executable) files.  What does that mean?  Take a step back: Java programs are compiled to bytecode.  Generally speaking, bytecode is computer object code that is processed by a software known as a virtual machine (e.g., the Java VM or JVM).  This process is different than what happens when you compile a C/C++ program: a C/C++ program is compiled into machine code which an actual computer can understand and to be directly executed by the CPU.  Dalvik is the virtual machine for Android, not JVM.  Thus, `.dex` files contain bytecode.  Both bytecode and machine code are not human readable and are difficult to edit.  If you are familiar with Java, a .class file is analagous to a `.dex` file --with some notable differences [2].
+
+You may be curious if it is possible to decompile the process: that is, reverse the compilation process from the `.dex` file to the high-level and readable `.java` file.  Yes it is possible but it may not be perfect.  You will need to use two tools: `dex2jar` to decompile the `.dex` file into a `.jar` file (a set of `.class` files), and then use `JD-GUI` to display Java source codes of `.class` files (that is, `.java` files).
+
+* `dex2jar` - https://github.com/pxb1988/dex2jar
+  * https://stackoverflow.com/questions/5257830/how-to-use-dextojar
+* `JD-GUI` - https://java-decompiler.github.io/
+
+## References
+1. "How to Analyze an Android Bot" by Kevin McNamee (RSA Conference 2016) https://comp116.org/readings/mbs-r02-how-to-analyze-an-android-bot.pdf (Links to an external site.)
+2. If you are familiar with Java, you may be curious what's the difference between .class and .dex files: https://stackoverflow.com/questions/8210173/what-is-the-difference-between-class-and-dex-files