daemonCodeReview.md

Table of Contents

1. Firmware Analysis Report
2. Abstract
3. Target(s)
   1. Sample 1
      1. name: mod4logd.c
      2. obtained as:
      3. source language:
   2. Sample 2
      1. name: S80sampled
      2. obtained as:
      3. source language:
4. Methods
   1. Applicable Standards
   2. Applicable Attack Vectors
   3. Suggested Tests, Manual
      1. Test Set: Sample 1
      2. Test Set: Sample 2
   4. Suggested Tests, Automatic (SAST)
5. Findings
   1. Results: Sample 1 Manual Review
   2. Results: Sample 1 SAST Scan results
   3. Results: Sample 2 Manual Review
   4. Results: Sample 2 Scan Results
6. Conclusion
   1. Attack Surface
      1. Data Paths
      2. Data Path protections
      3. Valueable data
      4. Valueable data protections

Firmware Analysis Report

This report serves as a template for analyzing the attack surface of firmware samples. Samples may

Abstract

Target(s)

Sample 1

name: mod4logd.c

obtained as:

• source code
• compresed binary
• encrypt

source language:

• C, C++
• PHP
• SH
• N/A

Sample 2

name: S80sampled

obtained as:

• source code
• compressed binary
• encrypted
• other

source language:

• C, C++
• PHP
• SH
• N/A

Methods

Applicable Standards

• OWASP
• SANS
• CERT
• CVE
• MITRE / CWE / CWE Top 25
• NVE
• PA-DSS

Applicable Attack Vectors

• Data / Input Validation
• Authentication
• Session Management
• Authorization
• Cryptography
• Error Handling
• Logging / Auditing
• Secure Code Environment
• Bad Coding Practices

Suggested Tests, Manual

Test Set: Sample 1

1. Data / Input Validation

   • CWE-665 Improper Initialization
   • Stack Overflows
   • Formatted Strings

2. Session Management

3. Authorization

   • CWE-732 Incorrect Permission Assignment

4. Logging / Auditing

Test Set: Sample 2

1. Data / Input Validation

   • CWE-665 Improper Initialization
   • Stack Overflows
   • Formatted Strings

Suggested Tests, Automatic (SAST)

• CodeQL (GitHub)
• SonarQube
• Snyk
• Veracode
• AppScan
• Checkmarx
• ShellCheck

Findings

Results: Sample 1 Manual Review

The code in Sample 1, mod4logd.c, is a very short program with limited scope. A brief manual review of the code, after successfully compiling and running, showed no obvious security vulnerabilities. Special attention was paid to variable declarations, variable initializations, data types, and string formatting. The program was then uploaded to github.com for use with the github SAST tool 'codeql'.

Results: Sample 1 SAST Scan results

Before the code in Sample 1 could be scanned with CodeQL, a special YAML file needed to be configured for the mod4logd.c code. A 'dry' run was configured first in which no security scanning was done; but would confirm that CodeQL could compile and run the binary produced by internally compiling the c code. The configuration was set for an Ubuntu 20.04 environment, assigned the necessary libraries, and instructed to run 'make' in the same manner as was done on the development box.

After making a few edits to the YAML file to succesfully compile the c code, the testing queries 'security-and-quality' and 'security-extended' were added to the YAML file instructions. The code was then scanned again with the targeted security queries.

The results came back with no alerts or warnings. Just to confirm the code scanner was working as intended, a deliberate vulnerability was then added to mod4logd.c in the form of an unitialized variable that was then called in a function named '_dobadidea'. On the development box the unitialized variable caused no problem in compiling or running the function. The modified program was then pushed to the same github repository and an automatic re-scan was then triggered for CodeQL. The second round of CodeQL scanning correctly identified the unitialized variable as a security vulnerability and logged an alert. Having confirmed the scanner was functioning, the deliberate flaw was removed and the code recomitted to the original repository.

Results: Sample 2 Manual Review

A manual review of the daemon shell S80sampled did not produce any obvious vulnerabilities.

Results: Sample 2 Scan Results

An automated scan of the script S80sampled produced alerts on the use of variables when calling 'printf()'

In S80sampled line 6:
  printf "Starting $DAEMON_NAME: "
         ^-----------------------^ SC2059: Don't use variables in the printf... 
format string. Use printf "..%s.." "$foo".

In S80sampled line 13:
  printf "Stopping $DAEMON_NAME: "
         ^-----------------------^ SC2059: Don't use variables in the printf...
format string. Use printf "..%s.." "$foo".

For more information:
  https://www.shellcheck.net/wiki/SC2059 -- Don't use variables in the printf...

After making the suggested edits at lines 6 & 13, the shell script was rescanned and the results produced no errors or alerts.

Conclusion

While the code for Sample 1 is quite small and presented no obvious security vulnerabilities during the manual and automated testing; the process was very useful in building the workflow you see here. This work flow has become the basis of a template for further code testing.

Attack Surface

The attack surface for Sample 2 can be described as:

Data Paths

1. Argument strings

   • This program relies on properly formated string arguments provided by the user. This could possibly be exploited. CWE-135

2. Libraries

   • n/a

3. Data ingest

   • n/a

4. Data export

   • n/a

Data Path protections

1. Authentication

   • There is no explicit user authentication built into this script. CWE-287

2. Authorization

   • There is no explicit user authorization built into this script. CWE-285

3. Activity Logging

   • There is no activity logging built into this script. CWE-778, OWASP top 10.

4. Data Validation

   • n/a

Valueable data

1. Secrets & Keys

   • n/a

2. Intellectual Property

   • n/a

3. Critical Business Data

   • n/a

4. Personal or PII data

   • n/a

Valueable data protections

1. encryption & checksums

   • n/a

2. access auditing

   • n/a

3. data integrity

   • n/a

4. operational security controls

   • n/a