Vulnerability Assessment

Lecture Notes

This lecture will present an overview over vulnerability assessment processes and methodologies

Download here

Practical tasks

This exercise will be used to explore aspects of an auditing and or assessment, complementing the work developed in the last laboratory.

As the scope we consider all hosts and services available at the laboratory network. The assessment should not try to pentest the systems, but small explorations are allowed. No data should be corrupted, and no credentials should be modified. Normal operation of the VMs should not be disrupted.

Auditing Linux Systems

One of the lab virtual machines has an open access ubuntu system with OpenSCAP (oscap) installed. This tool will enable us to demonstrate the operation of several SCAP mechanisms, especially the ones related with the validation of policies.

In order to proceed, create a folder in the user account with your name. Do all work inside this folder, so that you do not impact your colleagues.

Download the compressed XML OVAL definitions from Canonical. The definition files follow the following file naming convention:com.ubuntu.<example release name>.usn.oval.xml.bz2 Therefore, the OVAL definitions are specific for each distribution, as they relate with the actual software and configurations of that distribution.

wget https://security-metadata.canonical.com/oval/com.ubuntu.$(lsb_release -cs).usn.oval.xml.bz2

Uncompress the data:

bunzip2 com.ubuntu.$(lsb_release -cs).usn.oval.xml.bz2

Check the content of the XML file and analyze its structure. Take one vulnerability, such as USN-7792-1 and CVE-2025-32728 and identify the test that is conducted to determine the existence of the vulnerability.

Using OpenSCAP you can evaluate the OVAL and generate an html report for all definitions:

oscap oval eval --report report.html com.ubuntu.$(lsb_release -cs).usn.oval.xml

The output to stdout should be a series of lines for all the definitions being validated. A few minutes later, the tool should end.

The output is generated in the file report.html. You can transfer the file using scp and view it on your laptop:

scp user@IP:myfolder/report.html .

Analyze the report produced.

  • Is there any vulnerability in the system?
  • Are there critical vulnerabilities?

As you can see, the results display the details of each vulnerability, as well as a link to the CVE for each vulnerability. If you see any result listed as true, you will want to address that vulnerability immediately. Do understand, there are quite a lot of vulnerabilities tested , so hopefully the Ubuntu server will come up false for every test. But this is commonly not the case. If updates are lacking, new OVAL definition files may uncover other known vulnerabilities.

Of course, you don’t really have to scroll through the entirety of the results. You can always do a quick glance at the OVAL Results Generator Information to see how many vulnerabilities are:

  • Unpatched (red)
  • Patched (green)
  • Errors (yellow)
  • Unknown (blue)
  • Other (white)

Another system is present in the network for you to assess. Repeat the steps and analyze the report.

What differs from the previous system?

  • The operating system version
  • Installed packages and their versions
  • Network services running
  • Configuration settings
  • Missing updates

What is the impact of these differences in the vulnerabilities found?

Tasks:

  • Combine all data from your assessment (network, and scap)
  • Write a short summary to the network owner with the most relevant findings
  • Include some recommendations

Developing custom controls

You can also create custom OVAL definitions to validate your own hardening controls. Popular lists of OVAL definitions to harden systems can be found in several places, either created by the community, or by specific communities and even standardization entities. Some examples are:

For the purpose of this lab, we will consider a custom definition, which we plan to validate the compliance of a system. The definition is custom, but it could have been obtained from one of the previous sources. The definition aims to assert if root can login into the system.

<?xml version="1.0"?>
<ns0:oval_definitions
  xmlns:ns0="http://oval.mitre.org/XMLSchema/oval-definitions-5"
  xmlns:ns1="http://oval.mitre.org/XMLSchema/oval-common-5"
  xmlns:ns2="http://oval.mitre.org/XMLSchema/oval-definitions-5#independent"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://oval.mitre.org/XMLSchema/oval-definitions-5 oval-definitions-schema.xsd
                      http://oval.mitre.org/XMLSchema/oval-common-5 oval-common-schema.xsd
                      http://oval.mitre.org/XMLSchema/oval-definitions-5#independent independent-definitions-schema.xsdi">

  <ns0:generator>
    <ns1:schema_version>5.11</ns1:schema_version>
    <ns1:timestamp>2017-10-09T12:00:00</ns1:timestamp>
  </ns0:generator>

  <ns0:definitions>
    <ns0:definition id="oval:no_direct_root_logins:def:1" class="compliance" version="1">
      <ns0:metadata>
        <ns0:title>Direct root Logins Not Allowed</ns0:title>
        <ns0:description>Detailed description...</ns0:description>
        <ns0:reference ref_id="no_direct_root_logins"/>
      </ns0:metadata>
      <ns0:criteria operator="AND">
        <ns0:criterion comment="serial ports /etc/securetty" test_ref="oval:no_direct_root_logins:tst:1"/>
        <ns0:criterion comment="serial ports /etc/securetty" test_ref="oval:etc_securetty_exists:tst:2"/>
      </ns0:criteria>
    </ns0:definition>
  </ns0:definitions>

  <ns0:tests>
    <ns2:textfilecontent54_test id="oval:no_direct_root_logins:tst:1" check="all" check_existence="all_exist" 
        comment="no entries in /etc/securetty" version="1">
      <ns2:object object_ref="oval:no_direct_root_logins:obj:1"/>
    </ns2:textfilecontent54_test>
    <ns2:textfilecontent54_test id="oval:etc_securetty_exists:tst:2" check="all" check_existence="all_exist"
        comment="/etc/securetty file exists" version="1">
      <ns2:object object_ref="oval:etc_securetty_exists:obj:2"/>
    </ns2:textfilecontent54_test>
  </ns0:tests>

  <ns0:objects>
    <ns2:textfilecontent54_object id="oval:no_direct_root_logins:obj:1" comment="no entries /etc/securetty" version="1">
      <ns2:filepath>/etc/securetty</ns2:filepath>
      <ns2:pattern operation="pattern match">^$</ns2:pattern>
      <ns2:instance datatype="int" operation="greater than or equal">1</ns2:instance>
    </ns2:textfilecontent54_object>

    <ns2:textfilecontent54_object id="oval:etc_securetty_exists:obj:2" comment="/etc/securetty file exists" version="1">
      <ns2:filepath>/etc/securetty</ns2:filepath>
      <ns2:pattern operation="pattern match">^.*$</ns2:pattern>
      <ns2:instance datatype="int">1</ns2:instance>
    </ns2:textfilecontent54_object>
  </ns0:objects>

</ns0:oval_definitions>

Background: What is /etc/securetty?

On many Linux systems, the /etc/securetty file acts as an access control list for the root user. It contains a list of “safe” TTY (teletypewriter) devices from which the root user is allowed to log in directly.

  • If a TTY is listed in this file, root can log in from it.
  • If a TTY is not listed, root login is denied.
  • If the file is empty, root cannot log in directly from any TTY device.
  • If the file does not exist, the behavior can vary, with some systems defaulting to allowing root login from anywhere—a significant security risk.

The most secure policy is for the file to exist but be completely empty, forcing all users (including administrators) to log in with their own account and use sudo to perform privileged tasks. This creates a clear audit trail.

Prerequisites

  • A Linux Virtual Machine
  • Sudo/root privileges on the VM.
  • The openscap-scanner package installed

The provided OVAL XML file, saved as securetty_check.xml.

Part 1: Auditing the securetty Configuration

We will use the provided OVAL definition, which checks for two conditions:

  • The /etc/securetty file must exist.
  • The file must be empty.

Step 1: Create a Non-Compliant State

Most default systems are already compliant. To test our OVAL definition, we will intentionally create an insecure configuration by allowing root to log in from a local TTY.

Open a terminal in your Linux VM.

Important: First, back up the original file so you can easily restore it later.


sudo cp /etc/securetty /etc/securetty.bak

Now, add tty1 to the file. This change will allow the root user to log in directly from the first virtual console. We use tee to write to the file with sudo.

echo "tty1" | sudo tee /etc/securetty

Verify that the file now contains content.

cat /etc/securetty

Expected output: tty1

Step 2: Run the OVAL Scan

With the system in a non-compliant state, let’s run the OpenSCAP scanner. Navigate to the directory where you saved securetty_check.xml.

Execute the evaluation, generating an HTML report.

oscap oval eval --report report-fail.html securetty_check.xml

The scanner will immediately report the result as false in your terminal, indicating a failed check.

Definition oval:no_direct_root_logins:def:1: false

Step 3: Analyze the Results

Open the report-fail.html file in a web browser to inspect the detailed results. The report will show that the definition failed because the content of /etc/securetty did not match the expected state (an empty file).

Step 4: Remediate the Configuration and Verify the Fix

Now, let’s restore the secure configuration and confirm it with another scan. To remediate the system, we need to make the /etc/securetty file empty again. The truncate command is perfect for this.

sudo truncate -s 0 /etc/securetty

Verify that the file is now empty. The cat command should produce no output.

cat /etc/securetty

Run the OVAL scan again, saving the output to a new report file.

oscap oval eval --report report-pass.html securetty_check.xml

The terminal output should now be true, confirming compliance!

Definition oval:no_direct_root_logins:def:1: true

(Optional) When you are finished with the lab, restore the original file from your backup.

sudo mv /etc/securetty.bak /etc/securetty

Part 2: Your Turn! Author a New OVAL Definition

Now it’s your chance to create a new OVAL definition from scratch. Choose one of the following security controls, write the OVAL XML, and test it using the same methodology as in Part 1 (configure-fail, remediate-pass).

Choose a Security Control:

  • File Permissions: The file /etc/shadow, which contains hashed user passwords, must be owned by root and have permissions of 000 (no permissions for anyone). Hint: You will need a unix-def:file_test.
  • Prohibited Package: The rsh-server package (provides an insecure remote shell service) must not be installed. Hint: Use an rpminfo_test or dpkginfo_test and set check_existence="none_exist".
  • Service Disabled: The avahi-daemon service (for zero-configuration networking, often unneeded on servers) must be disabled. Hint: Use a unix-def:service_test.
  • Kernel Parameter: The kernel parameter net.ipv4.conf.default.accept_source_route (which can pose a security risk) must be set to 0. Hint: Use a unix-def:sysctl_test.

References

Previous
Next

Last updated on 26 Sep 2024