Daily Archives: December 3, 2020

Hardware Root of Trust – Bios and UEFI

Can you give a hacker your hardware and still trust that computer later? Yes - and here's how.

Imagine that malware with root-level privileges has been found on a machine that you manage. You might immediately re-image the affected machine, but can you be certain that the attacker’s modifications haven’t persisted in low-level firmware or via a malicious kernel-mode driver? This article explains modern and antiquated protections which attempt to prevent attackers who have already achieved root-level access from persisting via kernel-mode drivers or firmware implants. Much of the information comes from the excellent Rootkits and Bootkits book.

Following, I’ll describe a series of test steps which allow security engineers to determine what attack vectors are available to an attacker who is looking to persist their root level privileges beyond the capabilities provided by user-mode exploits.  

TLDR: Here’s a CSV of test cases to evaluate a system’s vulnerability to rootkits and bootkits.

CI/CD With Veracode Docker Images

On November 19, Veracode published new, official Docker images for use in continuous integration pipelines. The images, which provide access to Pipeline Scan, Policy (or Sandbox) scans, and the ability to access Veracode APIs via the Java API Wrapper or via HTTPie with the Veracode API Signing tool, make it easy to include the current version of Veracode tools in your automation workflow.

Why Docker?

Providing official Docker images addresses customer feedback we???ve received regarding the use of Veracode tools in a pipeline. Without using a Docker image, a customer???s script must download the tool each time to the CI/CD runner, adding time to each run, or a customer must implement their own caching mechanism to avoid redownloading the tool every time. Also, any dependencies required by the Veracode tool, including the Java runtime or Python, must be installed on the local machine, potentially raising issues of version compatibility. Last, some continuous integration pipelines, including AWS CloudStar and TravisCI, require external testing tools to be integrated via containers.

The Veracode Docker images address these concerns. Docker automatically provides caching and makes it easy to always use the latest version available. Also, the Docker image contains any dependencies required by the Veracode tool. Last, the Docker images are supported by Veracode, addressing concerns from customers about having to write their own image or rely on a community-provided one.

Securing Docker images

The Veracode Docker image was originally designed and built by Veracode???s product security team for internal use in pipelines by Veracode development teams. The team has done the following to ensure the images are secure:

  • The Docker images are built and published to DockerHub via continuous delivery pipelines that include the most current version of each included tool and scan the images for vulnerabilities.

  • Each image is run with a de-privileged local user to avoid privilege escalation.

  • The underlying tools are developed with a secure SDLC and are tested with Veracode Static Analysis and Veracode Software Composition Analysis in their own development pipelines.

  • The images are based on well-known and widely used base images.

  • Only the prerequisites absolutely needed for downloading the tools in the images are included.

Usage examples

Here are a few samples using the images in continuous integration workflows.

GitLab examples

These examples are drawn from a single workflow that uses all three containers in different stages. (You can see the project in which the workflow is published here.)

Pipeline Scan

Pipeline Scan Static Analysis:
    image: veracode/pipeline-scan:latest
    stage: Security_Scan
    only:
        - development
    script:
        - java -jar /opt/veracode/pipeline-scan.jar -vid ${VERACODE_API_ID} -vkey ${VERACODE_API_KEY} --file target/verademo.war --issue_details true --gl_issue_generation true -jf results.json 2>&1 | tee pipeline_scan_text_output.txt
    artifacts:
        paths:
            - results.json
            - pipeline_scan_text_output.txt
        when: always
        name: "veracode-pipeline-$CI_COMMIT_REF_NAME-$CI_COMMIT_SHORT_SHA"
    allow_failure: false

Sandbox Scan (using the Java API Wrapper)

Sandbox Scan Static Analysis:
    image: veracode/api-wrapper-java:latest
    stage: Security_Scan
    only:
        - release
    script:
        - java -jar /opt/veracode/api-wrapper.jar -vid ${TEAM_ANALYSISCENTER_ID} -vkey ${TEAM_ANALYSISCENTER_KEY}
          -action UploadAndScan -appname "Verademo" -createprofile true -autoscan true -sandboxname "gitlab-release" -createsandbox true
          -filepath ./target/verademo.war -version "Job ${CI_JOB_ID} in pipeline ${CI_PIPELINE_ID}" 2>&1 | tee sandbox_scan_output.txt
    artifacts:
        paths:
            - sandbox_scan_output.txt
        when: always
        name: "veracode-SANDBOX-SCAN-$CI_COMMIT_REF_NAME-$CI_COMMIT_SHORT_SHA"
    allow_failure: true

Dynamic Analysis (using the API Signing image)

Dynamic Analysis:
    image: veracode/api-signing:latest
    stage: Dynamic_Analysis
    only:
        - development
        - release
        - master
    variables:
          VERACODE_API_KEY_ID: ${VERACODE_API_ID}
          VERACODE_API_KEY_SECRET: ${VERACODE_API_KEY}
    script:
        - http --auth-type veracode_hmac PUT https://api.veracode.com/was/configservice/v1/scan_occurrences/?action=RESUBMIT

GitHub example

This example is drawn from a workflow that packages the application before submitting it for Pipeline Scan. Note that this workflow is structured as three jobs that use upload-artifact to share files between jobs; only the Pipeline Scan job is shown below. (You can see the project from which the example workflow was drawn here.)

Pipeline Scan

  pipeline-scan:
    needs: build
    runs-on: ubuntu-latest
    container: 
      image: veracode/pipeline-scan:latest
      options: --user root # our container user doesn't have privs to write to github directories

    steps:
    - name: Retrieve artifact
      uses: actions/download-artifact@v2
      with:
        name: CodePackage
    
    #  Submit  project to pipeline scan
    - name: Pipeline Scan
      run: java -jar /opt/veracode/pipeline-scan.jar --veracode_api_id="${{secrets.VERACODE_API_ID}}" --veracode_api_key="${{secrets.VERACODE_API_KEY}}" --fail_on_severity="Very High, High" --file="project.zip" --app_id="${{secrets.VERACODE_APP_ID}}" --json_output_file="results.json"
      continue-on-error: true # continuing so we can post results to Security tab

    - uses: actions/upload-artifact@v2
      with:
        name: ScanResults
        path: results.json

One interesting point to note in this example is that GitHub restricts write access to the normal working directory (/github/workspace) by anything but the root user of the container. Because Veracode Docker images normally run as a user with lower privileges for security reasons, we have to work around the GitHub restriction by explicitly invoking the root user by setting options: --user root .

Conclusion

Veracode Docker images provide a convenient, simple way to include Veracode automation in your CI/CD workflows. If you have questions or want to share your own experiences, check out the Veracode Community.

Demo walkthrough video

5 ways to take control of data in 2021

COVID-19 changed how economies, consumers, and the supply chain behave. All that change means that significant amounts of legacy data are no longer useful and, in many places, we are starting from ground zero. But for CIOs who are responsible for the infrastructures, platforms, and tools that manage and move data, essential data realities may not have changed, although their scope certainly has.

To read this article in full, please click here