System security

Scope of safety tests

The scope of the tests included security verification of the eAuditor V9 AI system:

• Threat Modeling,
• Penetration testing of web applications and REST APIs,
• Thick client (agent) application security testing.

Components tested:

• Web application “eAuditor”,
• Agent,
• REST APIs used by agents.

A total of 126 vulnerability tests were conducted as part of the tests. Where vulnerabilities occurred, they were analyzed and removed.

Threat modeling

Threat modeling is a process in which potential threats have been identified, classified and prioritized.

Penetration testing of web applications and REST APIs

Penetration testing is a basic security assessment process that allows assessing the technical level of security of networks and services, as a whole. In addition to the technical aspect of security, properly executed penetration tests can also illustrate the effectiveness of processes within an organization – for example, answer the question of whether the implemented process for updating systems is working properly and is effective, and illustrate the effectiveness of an organization’s response to IT incidents. Penetration tests are designed to assess the IT environment for known as well as unknown (“0day”) vulnerabilities that compromise the security of the information processed by the organization.

The OWASP ASVS (Application Security Verification Standard) was used in the process of testing web applications.

The OWASP ASVS (Application Security Verification Standard) defines best practices for testing applications and protection mechanisms of web applications. The use of the OWASP ASVS standard on allowed, among other things. for verification of the following types of vulnerabilities:

• “Injection” attacks – e.g. SQL injection, XML injection, code injection, command injection,
• Manage authentication and authorization,
• Cross-Site Scripting (XSS) attacks – Reflected, Stored, DOM-based,
• Dangerous direct references to objects located on servers,
• Configuration errors that directly affect security,
• Availability of sensitive data without authentication/authorization,
• Protection of the transmission channel (configuration of SSL/TLS, or other protocols used),
• The ability to bypass authentication, or vulnerability to “Local/Remote File Inclusion” attacks,
• Cross-Site Request Forgery,
• Vulnerability of system components (e.g., errors in the web server, or running modules),
• “Open Redirection.

In addition, checks collected within the OWASP REST Security Chear Sheet available at:

https://cheatsheetseries.owasp.org/cheatsheets/REST_Security_Cheat_Sheet.html

 

Thick client application evaluation

The thick-client application security tests were designed to assess the application’s security for known as well as unknown (“0-day”) vulnerabilities that compromise the security of the information processed with it.

The following aspects were evaluated:

• Publicly known vulnerabilities in software and libraries used,
• Business logic of the application,
• Solution architecture,
• Security of data stored on the station with the client installed – for example, encryption keys, credentials, sensitive information and others,
• How to communicate with the server – including ensuring proper authentication of clients and authorization of operations,
• Security of communication with the server – ensuring confidentiality and integrity of transmitted data,
• Vulnerabilities of heap and stack overflows – “Stack Overflow”/”Heap Overflow”,
• Vulnerabilities related to incorrect estimation of the range of values of accepted variables (“Integer Overflow”),
• Incorrect passing of arguments to functions that operate on strings (“Format String”),
• Errors due to type incompatibility (“Type Confusion”),
• Security of processes/application resources – e.g., credentials in process memory, process permissions, security of used resources (shared memory, “pipes”, or other IPC mechanisms), or permissions to used files,
• Vulnerability to DLL hijacking attacks,
• Permissions for services (“services”) of the application,
• Proper use of cryptography within the application.

Examination of the source code

No source code study was conducted.

Tools used

The analysis of this type of software included. The following tools:

• IDA Professional and Hex-Rays Decompiler – disassembling and decompiling code to thoroughly understand application functionality, or reviewing applications for programming errors,
• Burp Suite Professional – as a tool for analyzing HTTP/HTTPS traffic when this type of communication is used by an application,
• Wireshark – to analyze network traffic,
• WinDbg – a debugger for the Windows platform – control the application during testing, as well as control the used memory/objects during detailed analysis,
• GDB – a debugger for the Linux platform – controls the application during testing, as well as controls the memory/objects used during detailed analysis,
• Tools to control access to system files/objects – e.g.. Process Monitor (Windows Sysinternals tool).

Vulnerability classification

Common Vulnerability Scoring System (CVSS).

The pentester team relied on the Common Vulnerability Scoring System (CVSS) to accurately assess the risk posed by the detected vulnerability. This results in the ability to accurately reflect the risk of an identified vulnerability numerically, along with showing the result in the form of a descriptive representation (risk – low, medium, high, critical).

The base score consists of the following:

• Attack Vector (Attack Vector/AV) – reflects the context in which the vulnerability can be exploited:
  • Network (Network/N) – the vulnerable element is related to the network stack/vulnerability can be exploited remotely,
  • Adjacent/A – the attack must be launched from the same shared physical network (e.g., Bluetooth/IEEE 802.11), logical network (e.g., local IP subnet) or a specially restricted administrative domain,
  • Local (Local/L) – an attack that can be carried out locally, e.g. with commands issued locally on a keyboard, or remotely with an authenticated SSH session,
  • Physical (Physical/P) – the attack requires the attacker to directly (physically) interact with the device,
• Attack Complexity/AC – describes conditions beyond the attacker’s control that are necessary to exploit the vulnerability:
  • Low (Low/L) – the attacker can expect repeated success when exploiting a vulnerable element,
  • High (High/H) – a successful attack depends on conditions beyond the attacker’s control, such as the need to bypass advanced security mechanisms before exploiting the vulnerability itself.
• Privileges Required/PR – shows the level of privileges an attacker must have to exploit the vulnerability:
  • None (None/N) – the attack can be carried out without authentication,
  • Low (Low/L) – basic permissions are required to exploit the vulnerability, which normally only affects a specific user’s settings and data,
  • High (High/H) – the attack requires permissions that provide significant (e.g., administrative) control over the vulnerable component, allowing access to settings and files throughout the component.
• Required User Interaction/UI – takes into account the requirements for human (e.g., application user) interaction in the process of carrying out an attack:
  • None (None/N) – the attack can be carried out without interaction from the victim,
  • Required (Required/R) – the success of the attack depends on a specific interaction of the victim.
• Scope (Scope/S) – determines whether the vulnerable part of the system affects other additional elements beyond its security scope:
  • Unchanged/U – the exploited vulnerability can only affect resources managed by the same security authority,
  • Changed (Changed/C) – the exploited vulnerability may affect resources beyond the scope of security managed by the security authority for the vulnerable element.
• Confidentiality/C – determines the impact of successful exploitation of vulnerabilities on the confidentiality of processed data:
  • None (None/N) – there is no loss of confidentiality within the vulnerable element,
  • Low (Low/L) – there is some loss of confidentiality, but disclosure of information does not cause direct, serious loss to the affected element,
  • High (High/H) – there is a complete loss of confidentiality, as a result of which all resources within the affected component may be disclosed,
• Integrity (Integrity/I) – determines the impact of successful exploitation of vulnerabilities on the integrity of processed data:
  • None (None/N) – there is no loss of system integrity,
  • Low (Low/L) – modification of data by an attacker is possible to a limited extent,
  • High (High/H) – there is a complete loss of system integrity.
• Availability (Availability/A) – shows the impact on the availability of the attacked element due to a successfully exploited vulnerability:
  • None (None/N) – has no effect on accessibility within the affected element,
  • Low (Low/L) – performance is limited or there are interruptions in resource availability,
  • High (High/H) – there is a complete loss of accessibility to the attacked resource.

Implementing entity

The entity implementing the security tests was an entity independent of BTC Sp. Ltd. holding, among other things. The following certifications:

• OSCE (Offensive Security Certified Expert),
• OSCP (Offensive Security Certified Professional),
• CSSA (Certified SCADA Security Architect),
• CISSP (Certified Information Systems Security Professional),
• CISA (Certified Information Systems Auditor).