Résumé
ONYEDIKACHI BERNARDCLOUD · DEVSECOPS · AI
RésuméGet in touch
CASE 31INFRASTRUCTURE AS CODE

On-Prem IaC Pipeline Assessment

An on-premises IaC pipeline had insecure provisioning defaults, including shared directories, stored SSH keys, and unrestricted sudo. I traced the full path from the web application to root on the provisioning host and identified the hardening controls needed at each step.

Status: ASSESSED · VERIFIED

DOMAIN
Infrastructure as Code
PLATFORM
Vagrant, Ansible, Docker
SEVERITY
Critical
OUTCOME
Full attack path documented

TOOLS

VagrantAnsibleDockerSSHNmapBashLinuxInfrastructure as Code
RESULT
BEFOREShared dirs, stored keys, sudo ALL
AFTERAttack path documented
01

Objective

I set out to identify vulnerabilities within an on-premises IaC pipeline and determine how insecure provisioning configurations could allow an attacker to move from the web application to root access on the provisioning host.

02

Scenario

An on-premises environment used Vagrant, Docker, and Ansible to provision a web application and database. The Vagrantfile and provisioning configuration contained several security weaknesses. I wanted to trace whether those weaknesses could be chained into a full path from the web application to the host operating system.

03

What I found

FINDING 01 (CRITICAL): WEB APPLICATION VULNERABLE TO COMMAND INJECTION

The web application's database testing endpoint accepted unsanitised input, which allowed command execution inside the web container. The container ran as root.

web-containerCOMMAND INJECTION
Endpoint:            /api/testDB
Vulnerability:       Command injection
Container user:      root

FINDING 02 (CRITICAL): SSH KEY AND SHARED DIRECTORY EXPOSED IN CONTAINER

The web container had access to an SSH private key stored in the provisioning directory and a shared /tmp/datacopy directory that bridged the container and the host.

container-exposureKEY EXPOSED
SSH key:             Stored in provisioning directory (accessible from container)
Shared directory:    /tmp/datacopy (host-to-container mount)

FINDING 03 (CRITICAL): PROVISIONING USER HAD UNRESTRICTED SUDO

The provisioning user on the host had NOPASSWD: ALL sudo privileges, meaning any access to that account gave full root control of the host.

sudo-configSUDO ALL
User:                <REDACTED> (provisioning user)
Sudo privileges:     (ALL : ALL) ALL, (ALL) NOPASSWD: ALL
Root access:         Immediate via sudo

The full chain ran from command injection in the web app, to an SSH key in the container, to the provisioning user on the host, to root through unrestricted sudo.

04

What I did

  1. Reviewed the Vagrantfile

    I identified Docker networking, shared directories, SSH configuration, deployment keys, and privileged provisioning settings.

  2. Assessed the web application

    The database testing endpoint was vulnerable to command injection, providing root access inside the web container.

  3. Enumerated the container

    I found an SSH private key in the provisioning directory and a shared directory linking the container to the host.

  4. Traced the path to the host

    The SSH key and shared directory allowed authenticated access to the provisioning user on the host.

  5. Confirmed root access

    The provisioning user's unrestricted sudo privileges provided immediate root access to the host.

EVIDENCE

TEXT
# Attack path summary
Step 1:  Command injection in web app (/api/testDB)
Step 2:  Root shell in web container
Step 3:  SSH key found in provisioning directory
Step 4:  Authenticated to host as provisioning user
Step 5:  Unrestricted sudo to root on provisioning host
05

Validation

The full path from web application to root on the provisioning host was confirmed. Each step was reproducible through the insecure provisioning configuration.

06

Before and after

CONTROLBEFOREAFTER
Web application inputUnsanitisedRisk documented; input validation recommended
Container userRootRecommended: non-root user
SSH keys in containerAccessibleRecommended: remove from container, use agent forwarding
Shared directoriesHost-to-container mountRecommended: remove or restrict
Provisioning user sudoNOPASSWD: ALLRecommended: scoped sudo with specific commands only
Network segmentationNot enforcedRecommended: isolate provisioning network
07

What I recommend

  1. 01Sanitise all application inputs, especially endpoints that interact with databases or system commands.
  2. 02Run containers as non-root users and avoid storing credentials inside containers.
  3. 03Remove SSH keys and sensitive files from provisioning directories that are mounted into containers.
  4. 04Restrict sudo privileges for provisioning users to only the specific commands they need.
  5. 05Isolate the provisioning network from the application network.
  6. 06Review Vagrantfiles and Ansible playbooks for hardcoded credentials, shared directories, and elevated privileges before deployment.

“An IaC pipeline is not inherently secure simply because infrastructure deployment is automated. Every credential, shared directory, privilege, and provisioning action becomes part of the attack surface and must be deliberately hardened.”

WHAT I LEARNED

SKILLS IT PROVES

  • Infrastructure as Code Security
  • Vulnerability Assessment
  • DevSecOps
  • Vagrant
  • Ansible
  • Docker Security
  • Linux Security
  • SSH Security
  • Credential Security
  • Access Control
  • Least Privilege
  • Security Hardening
  • Attack Path Analysis
  • Container Security
  • Infrastructure Security
View my labs on GitHub