/
/
Open Vulnerability Assessment Language (OVAL) in a Nutshell - Part 2

Open Vulnerability Assessment Language (OVAL) in a Nutshell - Part 2

Article
August 27, 2022
Profile Icon

Jason Franscisco

Introduction

This blog post is in continuation to our previous post titled Open Vulnerability Assessment Language in a Nutshell.

To further explain about the OVAL, let’s consider the latest CVE (CVE-2022–0540) for the Atlassian Jira Server product. This vulnerability in Jira Seraph allows a remote and unauthenticated attacker to bypass authentication by sending a specially crafted HTTP request.

We have used Jira version 9.1.0. to demonstrate this vulnerability in our blog. Do not have Jira or the latest update of it? You can download the latest version of Jira software using this link.

For Windows:

Download the latest Windows version of Jira software using the same link above. After the successful installation, grab the fingerprints of the application using registry editor.

Registry Editor

Find fingerprints using the search string as shown above and choose a result which is relevant.

Registry Editor

As shown above, a key is identified that can be used to check the existence of the application and the version of the installed application. The subkeys DisplayName and DisplayVersion hold the name of the application and the version of the installed application. The above information that is gathered is enough to develop Security content (OVAL Definition) for Jira Software as explained below.

OVAL Definition Flow Diagram

In the above diagram, state represents the OVAL States and object represents OVAL Object. * for the OVAL States denotes that there can be any number of state (i.e. 0 or many). OVAL Object collects information from a given endpoint and compares it with as many defined OVAL States, which results in the outcome for above hierarchy test (represented as OVAL Test).

A hierarchy above test is criterion that has test_ref attribute used to refer to the defined OVAL test_id (i.e which is below its hierarchy).

In the same hierarchy level of criterion, there is an Extend Definition that has * denotes there can be any number of extend_defintion in its top hierarchy criteria (represented as OVAL Criteria). The extend_defintion has def_ref attribute that refers to the definition of the given id (which is below its hierarchy, also represented as OVAL Definition).

criterion and extend_definition will be grouped into criteria that have used any logical operator to make up the final decision/result of the definition.

Hierarchy above criterion and extend_definition is criteria (OVAL Criteria). The * denotes that there can be any number of criteria in its top hierarchy definition (OVAL Definition). metadata is also placed in the same criteria level.

The Element which is above one hierarchical level is considered as parent element and the down to the parent hierarchal level elements are considered to be child elements. Ex: definition is the parent element while metadata and criteria are child elements.

Developing Security Content (OVAL Definition)

Example for the structure of OVAL Definition
Example for the structure of OVAL Definition

Code Description
<?xml version="1.0" encoding="UTF-8"?> This is used for definition following standard XML version 1.0 and can be encoded using UTF-8 format.
<oval_definitions>...</oval_definitions> This is a parent element for the OVAL definition. It should be defined with namespace attributes that the file requires.
xmlns="http://oval.mitre.org/XMLSchema/oval-definitions-5" This is the default namespace.
xmlns:oval="http://oval-mitre.org/XMLSchema/oval-common-5" It refers to a common schema.

This namespace can be used in both ways:

  1. <oval:product_name>Loginsoft Threat Research</oval:product_name>
  2. <product_name xmlns="http://oval.mitre.org/XMLSchema/oval-common-5"> Loginsoft Threat Research</product_name>

xsi:schemaLocation This attribute is used to identify the schema file for validating the Definition

Sections in OVAL Definition

Definitions:

It is written as <definitions>. It can have one to many <defintion> elements

Definitions

Attributes of <defintion> are:

id(required): This attribute holds the definition ID. It should be unique for every definition in an OVAL definition file. OVAL defines a pattern.

oval:[A-Za-z0–9_\-\.]+:def:[1–9][0–9]*

id="oval:org.loginsoft.windows.jiraserver.cve:def:1000

Code Description
<?xml version="1.0" encoding="UTF-8"?> This is used for definition following standard XML version 1.0 and can be encoded using UTF-8 format.
<oval_definitions>...</oval_definitions> This is a parent element for the OVAL definition. It should be defined with namespace attributes that the file requires.
xmlns="http://oval.mitre.org/XMLSchema/oval-definitions-5" This is the default namespace.
xmlns:oval="http://oval-mitre.org/XMLSchema/oval-common-5" It refers to a common schema.

id="oval:org.loginsoft.windows.jiraserver.cve:def:202205401000"

In this, 202205401000 is a numerical value taken from CVE-2022–0540 and random 1000 appended. This will ensure that every CVE in the Jira server windows platform will have a unique Vulnerability class definition ids.

version(required): This attribute holds the current version of the definition file. It accepts only the non-Negative Integer values. The value starts with “1” and is incremented each time the definition is updated.

version="1" It defines that the written definition is the first release.

class(required): The <defintion> element can be categorized into 5 classes depending on their kind. They are:

Code Description
<?xml version="1.0" encoding="UTF-8"?> This is used for definition following standard XML version 1.0 and can be encoded using UTF-8 format.
<oval_definitions>...</oval_definitions> This is a parent element for the OVAL definition. It should be defined with namespace attributes that the file requires.
xmlns="http://oval.mitre.org/XMLSchema/oval-definitions-5" This is the default namespace.
xmlns:oval="http://oval-mitre.org/XMLSchema/oval-common-5" It refers to a common schema.

class="inventory" to check if the Jira server is installed on the Windows platform.

class="vulnerability" to check if the installed Jira server is Vulnerable to CVE-2022–0540.

deprecated(optional): This attribute holds the boolean value. The default value is “false” and a value of “true”, signifies that the definition cannot be used or referenced.

Elements of <definition> are:

1.Metadata:

Example for metadata and its sub-child

It can be used to specify all information related to the purpose of the definition. It also has some child and sub-child elements.

title: It holds the short string that holds the purpose of the definition. It is a required element. Min and Max occurrence is 1.

<title>Atlassian Jira Server and Data Center is installed on Windows</title> is the title for <definition class="inventory/>, the purpose of the definition is to check if the Jira Server is installed.

<title>Atlassian Jira Server Authentication Bypass in Jira Seraph</title> is the short string given because the purpose of definition(i.e CVE-2022–0540) is also vulnerable.

affected: It holds the information of a system to which the definition is written. It is an optional element, MinOccurs is 0 and MaxOccurs is many.

It has 2 child elements platform and product with MinOccurs 0 and MaxOccurs many.

It has the attribute “family(required)”. The attribute value can be chosen depending on the purpose of the definition.

<affected family="windows"> The purpose of this definition is to check Jira server Vulnerability in windows.

<platform> Microsoft Windows</platform> defines the platforms in windows that are affected like Microsoft Windows10, Microsoft Windows NT , etc…

<product>Atlasssian Jira Server and Data Center</product> can be used to define affected products in definition.

reference: It is used to define external sources related to the purpose of the definition. It is an optional element. MinOccurs is 0 and MaxOccues is many. It has 3 attributes.

<reference source="CPE" ref_id="cpe:2.3:a:atlassian:jira"/> refers to the Common Platform Enumeration(CPE) id for Atlassian Jira products.

<reference source="VENDOR" ref_id="JRASERVER-73650" ref_url="https://jira.atlassian.com/browse/JRASERVER-73650"/> refers to an external source of advisory.

<reference source="CVE" ref_id="CVE-2022-0540" ref_url="https://nvd.nist.gov/vuln/detail/CVE-2022-0540"/> refers to an external source of the National Vulnerable Database(NVD).

description: It holds the description for the purpose of definition. It is a required element with Min and Max occurrence as 1.

<description>...</description> is the detailed information of vulnerability.

<xsd:any>: From the above picture, the oval_repository element was written to maintain the status of definition for company purposes.

2. Criteria:

It has decision-making intelligence that defines the outcome of the definition. Decision-making power is using logical operators with the comparison results pulled from OVAL Tests. There can be multiple nested criteria. Each criteria can have 1 or more criterions. The criterion have the attribute test_ref which is a reference id for OVAL Test.

criteria

Attributes of <criteria> are:

operator(required): It provides a logical operator that can be used to evaluate the result based on the criterion. Its default value is “AND”.

comment(optional): A short string to describe the purpose of the criteria.

<criteria comment="Check Jira" operator="OR"> In this, operator="OR" will define a logical operator “OR” which evaluates to overall TRUE if any of the criterion resulted in TRUE. comment="Check Jira" defines  if the Jira server is installed on windows. negate(optional): The result of the criteria is negated. Its default value is “false”. Example: If negate="true" and the criteria result is TRUE then negate of it is NOT TRUE. applicability_check(optional): Checks if OVAL Definition applies to a given system.

Elements of <criteria> are:

criteria: This element can be used to define sub-criteria. The Min occurrence is 1 and Max is many.

extend_definition: It allows the existing definition to be extended by another definition. This works by evaluating the extended definition and then using the result within the logical context of extending the definition.

<extend_definition comment="Atlassian Jira Server and Data Center is installed for windows" definition_ref="oval:org.loginsoft.windows.jiraserver.cve:def:1000"/>

Attributes of <extend_definition> are:

  • definition_ref(required): It requires a definition id that is being extended. The id is of definition id pattern. definition_ref="oval:org.loginsoft.windows.jiraserver.cve:def:1000" refers to another definition id to be extended.
  • comment(optional): comment=".." A short string to state the purpose of extend_definition.
  • negate(optional): Refer above
  • applicability_check(optional): Refer above.

criterion: This element can be used to specify a test to be included in the definition’s criteria. Min occurrence is 1 and Max is many.

Attributes of <criterion> are:

  • test_ref(required): It requires a test id that refers to a test element. There is a pattern defined for test id.
  • oval:[A-Za-z0–9_\-\.]+:tst:[1–9][0–9]*
  • comment(optional): A short string for the purpose of the test element.
  • applicability_check(optional): Refer above
  • negate(optional): Refer above

Tests:

The element is written as <tests> . It can have multiple test types.

OVAL Tests are responsible for comparing the expected endpoint value in definition with the system characteristic endpoint retrieved from scanning(i.e OVAL Object and OVAL State). According to the schema, a test can only contain one object, and state can be 0 to any.

tests

Attributes of test are:

xmlns: It is the namespace attribute used to specify the schema from which the test type is used. The <registry_test> belongs to the windows schema, for that reason xmlns="http://oval.mitre.org/XMLSchema/oval-definitions-5#windows" attribute is used, alternatively the attribute <windows-def:registry_test> can also be used as mentioned above.

The registry test is used to check metadata associated with Windows registry key. It extends the standard TestType as defined in the oval-definitions-schema. The required object element references a registry_object and the optional state element specifies the registry data to check.
  • id(required): It requires a unique test id with the defined test id pattern. This id can be referenced from test_ref attributes.
  • check(required): This attribute is used to check the number of items defined in the state that should be matched with the OVAL Object. This attribute can be ignored if no state references are defined in a test. This has predefined values.
  • check="all" returns true if all the individual conditions in the test results to true.
  • check="at least one" returns true if at least one of the individual conditions results in true.
  • check="only one" returns true if only one of the individual conditions results in true.
  • check="none satisfy" returns true if none of the individual conditions results in true.

In the above code two state_ref are used and check="all" will return true only if both states evaluate to true when compared with OVAL Object. Similarly, in the above case, if check="at least one" is used then it returns true even if any one state evaluates to true when compared with OVAL Object.

  • check_existence(optional): This attribute is used to check the number of collected values needed with the OVAL Object to evaluate the result to true. The default value is at_least_one_exists .
  • check_existence="at_least_one_exists" used to check if at least one of the info is collected with specified OVAL Object.
  • check_existence="all_exist" used to check if every info is collected with specified OVAL Object.
  • check_existence="any_exist" used to check if any of the info is collected with specified OVAL Object.
  • check_existence="none_exist" used to check if none of the info is collected with specified OVAL Object.
  • check_existence="only_one_exists" used to check if only one info is collected with specified OVAL Object.
  • state_operator(optional): It provides the logical operator that can be used to evaluate the result based on comparing each referenced state. It is not needed when there are no state references. Its default value is “AND”.
  • state_operator="AND" returns true if every state evaluates to true.
  • state_operator="OR" returns true if any state evaluates to true.
  • state_operator="ONE" returns true if only one state evaluates to true.
  • state_operator="XOR" returns true if an odd number of times the state evaluates to true.
  • version(required): Refer above.
  • comment(optional): Refer above.
  • deprecated(optional): Refer above.

Elements of the test are:

notes: Refer above.

object: It has the object_ref attribute with the object id. For test , it can only have one object. There is a predefined pattern for <object id=""/>.

oval:[A-Za-z0–9_\-\.]+:obj:[1–9][0–9]*

state: It has the state_ref attribute with the state id. For test, state can be any. There is also a predefined pattern for <state id=""/>.

oval:[A-Za-z0–9_\-\.]+:ste:[1–9][0–9]*

Objects:

This element is written as <objects> . OVAL Object is used to define “What to be checked/collected” at an endpoint. Attributes are the same for every object type but the child elements differ based on the object type.

objects

<registry_object> it is an element predefined in the windows schema.

Attributes of the object are:

xmlns: It is the namespace attribute used to specify the schema from which the test type is used. The <registry_test> belongs to the windows schema, for that reason xmlns="http://oval.mitre.org/XMLSchema/oval-definitions-5#windows" attribute is used, alternatively the attribute <windows-def:registry_test> can also be used as mentioned above.

  • id(required): It is the <object id=""/> that will get referenced from object_ref in other elements of OVAL.
  • version(required): Refer above.
  • comment(optional): Refer above.
  • deprecated(optional): Refer above.

Elements for <registry_object> are:

behaviors: This element is used to specify a more detailed registry_object. It has 3 attributes. Min occurrence is 0 and Max is 1.

max_depth(optional): It defines the depth of recursion to perform when <behaviors recurse_direction="" max_depth=""/> is specified. The default value is -1. Value 0 is equivalent to no recursion, value ‘1’ will recurse for one step in the direction specified.

recurse_direction(optional): It defines the direction for recursion. ‘up’ represents the parent keys, ‘down’ represents the child keys. The default value is ‘none’.

windows_view(optional): It defines the type of view to be used on a scanning system. This is useful only in the case of 64-bit Windows machines to test if the 32-bit application is installed on a 64-bit machine. The default value is ‘64-bit’.

If the 32-bit installer of Jira Server is installed on the 64-bit windows then the above case is helpful. Windows will provide an alternative file system for a 32-bit installer in 64-bit architecture(i.e WOW6432) so this behavior is specified, based on this OVAL will take care of the file structure.

hive: It defines to which hive the registry key belongs. Its values can be any one of the following HKEY_CLASSES_ROOT, HKEY_CURRENT_CONFIG, HKEY_CURRENT_USER, HKEY_LOCAL_MACHINE, and HKEY_USERS. Min and Max occurrence is 1.

<hive>HKEY_LOCAL_MACHINE</hive> contains information about the local system.

key: It defines the registry key to be tested. Min and Max occurrence is 1.

<key>SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\3069-1244-9928-3021</key> will be the key used to check the existence of Jira Server on a Windows machine.

name: It defines the value associated with the specified name in the specified registry key. Min and Max occurrence is 1.

<name>DisplayName</name> will be used to get its associated value for key ‘DisplayName’.

States:

This element is written as <states> . OVAL State is used to define “Expected value” to check at an endpoint defined in the OVAL Object. There can be any number of states in OVAL Tests. Attributes are the same for every state type but the child elements differ based on the state type.

States

<registry_state> it is the element taken from the windows schema.

The registry_state element defines the different metadata associate with a Windows registry key. This includes the hive, key, name, type, and value. Please refer to the individual elements in the schema for more details about what each represents.

Attributes of the state are:

xmlns: It is the namespace attribute used to specify the schema from which the state type is used. The <registry_state> belongs to the windows schema, for that reason xmlns="http://oval.mitre.org/XMLSchema/oval-definitions-5#windows" attribute is used or as mentioned above <windows-def:registry_state> can be used.

  • id(required): It is the state id that will get referenced from state_ref in other elements of OVAL.
  • version(required): Refer above.
  • comment(optional): Refer above.
  • deprecated(optional): Refer above.

Elements of <registry_state> are:

hive: It defines to which hive the registry key <key/> belongs. Its values can be any one of the following HKEY_CLASSES_ROOT, HKEY_CURRENT_CONFIG, HKEY_CURRENT_USER, HKEY_LOCAL_MACHINE, and HKEY_USERS. Minimum occurrence is 0 and Maximum occurrence is 1.

key: This element specifies a registry key to be tested. Minimum occurrence is 0 and Maximum occurrence is 1.

name: Specifies value of a registry key to test. Minimum occurrence is 0 and Maximum occurrence is 1.

last_write_time: Specifies last modified time of any key or value to test. Minimum occurrence is 0 and Maximum occurrence is 1.

type: It allows to specify a registry type to check the type of key. Minimum occurrence is 0 and Maximum occurrence is 1.

value: It allows to specify a value to be tested with the value that the registry key holds. Minimum occurrence is 0 and Maximum occurrence is 1.

<value operation="pattern match">^J[Ii][Rr][Aa] .*$</value> Matches any string with a given regex.

operation="pattern match" is used to add regex functionalities to OVAL. This will work only with datatype="string" . datatype="string" is the default datatype in OVAL, so no need of mentioning datatype in this case.

The string datatype describes standard string data. Expected operations within OVAL for string values are ‘equals’, ‘not equal’, ‘case insensitive equals’, ‘case insensitive not equal’, ‘pattern match’.

Regex breakdown

^ will make sure that the string starts with its followed letter (i.e J ).

[Ii] will make sure that after J there can be any small case i or capital I .

A similar case to the letter with braces [ ] .

blank space is to make sure the very next letter after Jira is space (i.e not any alphabet or digit).

.* wildcard will consider any string after Jira .

<value datatype="version" operation="less than">8.13.18</value> It is used to test whether the given value is less than the collected endpoint/DisplayVersion value got from an object.

The version datatype represents a value that is a hierarchical list of non-negative integers separated by a single character delimiter. Note that any non-number character can be used as a delimiter and that different characters can be used within the same version string. So ‘#.#-#’ is the same as ‘#.#.#’ or ‘#c#c#’ where ‘#’ is any non-negative integer. Expected operations within OVAL for version values are ‘equals’, ‘not equal’, ‘greater than’, ‘greater than or equal’, ‘less than’, and ‘less than or equal’.

windows_view: It is used to specify the view (32-bit or 64-bit) that is needed to check with an object.

Variables:

This section is used to store constant/dynamic values specified or collected from the system. These variables can be further used in OVAL Objects or the OVAL States.

Complete OVAL Definition.

Explanation and working of each element are shown in the mind map link here.

Scanning

After developing the definition you can scan against a system by using an open-source tool called OpenSCAP.

You can follow this guide for OpenSCAP installation and Usage.

oscap oval eval --report Jira-win-report.html CVE-2022-0540-win-jira.xml

Command Prompt

Results:

The following are the possible results from the OpenSCAP tool.

The following screen shows the result of “Not installed”, it shows false for both Class columns (i.e inventory and vulnerability).

Results

The following screen shows the result of “Installed but not vulnerable”, it shows true for Class inventory and false for Class vulnerability.

Installed but not vulnerable

The following screen shows the result of “Installed and vulnerable”, it shows true for both Class columns (i.e inventory and vulnerability) In OVAL, each complete unit of information is called a definition. A collection of definitions is called a repository.

Installed but not vulnerable

For more Atlassian Jira definitions you can check our OVAL-Repository GitHub repo.

Author:

Raveen Gatla – Vulnerability Researcher

References

OVAL Definition Tutorial

OVAL Definition Tutorial Common XML Concepts,Definition structure,Variables Complex objects Behaviors..

OVAL Content Creation Tutorial

The Open Vulnerability and Assessment Language (OVAL) is an XML-based community standard for representing and..

What Is OVAL? A Community-Driven Vulnerability Management Brain! - DZone Security

The Open Vulnerability and Assessment Language (OVAL ®) is a critical component of most enterprise’s endpoint…

OVAL - OVAL Repository Overview

Open Vulnerability and Assessment Language (OVAL®) is a community effort to standardize how to assess and report upon..

Getting Started - The OVAL Community Guidelines documentation

Are you new to OVAL? Wondering what it is and how it’s used? Read on! OVAL is an open, standardized assertion language…

Schema documentation for oval-definitions-schema.xsd

The following is a description of the elements, types, and attributes that compose the core schema for encoding Open..

Open Vulnerability and Assessment Language - Element Dictionary

The OVAL Schema is maintained by The MITRE Corporation and developed by the public OVAL Community. For more information..

Explore Cybersecurity Platforms

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Suspendisse varius enim in eros.

Learn more
white arrow pointing top right

About Loginsoft

For over 20 years, leading companies in Telecom, Cybersecurity, Healthcare, Banking, New Media, and more have come to rely on Loginsoft as a trusted resource for technology talent. From startups, to product and enterprises rely on our services. Whether Onsite, Offsite, or Offshore, we deliver. With a track record of successful partnerships with leading technology companies globally, and specifically in the past 6 years with Cybersecurity product companies, Loginsoft offers a comprehensive range of security offerings, including Software Supply Chain, Vulnerability Management, Threat Intelligence, Cloud Security, Cybersecurity Platform Integrations, creating content packs for Cloud SIEM, Logs onboarding and more. Our commitment to innovation and expertise has positioned us as a trusted player in the cybersecurity space. Loginsoft continues to provide traditional IT services which include Software development & Support, QA automation, Data Science & AI, etc.

Expertise in Integrations with Threat Intelligence and Security Products: Built more than 200+ integrations with leading TIP, SIEM, SOAR, and Ticketing Platforms such as Cortex XSOAR, Anomali, ThreatQ, Splunk, IBM QRadar & Resilient, Microsoft Azure Sentinel, ServiceNow, Swimlane, Siemplify, MISP, Maltego, Cryptocurrency Digital Exchange Platforms, CISCO, Datadog, Symantec, Carbonblack, F5, Fortinet, and so on. Loginsoft is a partner with industry leading technology vendors Palo Alto, Splunk, Elastic, IBM Security, etc.

In addition, Loginsoft offers Research as a service: We're more than just experts in cybersecurity; we're your accredited in-house research team focused on unraveling the complexities of cybersecurity and future technologies. From Application Security to Threat Research, our seasoned professionals have cultivated expertise in every facet of the field. We've earned the trust of over 20 security platform companies, who count on our research and analysis to strengthen their cybersecurity solutions.

Interested to learn more? Let’s start a conversation.

Book a meeting

IN-HOUSE EXPERTISE

Latest Articles

Get practical solutions to real-world challenges, straight from experts who conquered them.

View all our articles

Sign up to our Newsletter