Sensitive Data Leakage via Ansible Modules
Another way that Ansible can be useful for lateral movement
is through sensitive data leaks.
Although there are protections for credentials
and sensitive data being used in module parameters in Ansible playbooks,
some modules leak data
to /var/log/syslog
in the form of module parameters.
This happens when the set of a module’s parameters are not fixed
and can potentially change
depending on how the module is being run.
A good example of this is the shell Ansible module.
Let’s imagine a scenario where an Ansible administrator wants to run a playbook
on a managed node
to make a database backup from a remote server.
An example playbook might look something like this.
The shell line shows that the playbook will attempt to connect to a server
called databaseserver
and dump the tpsreports database
to a file on the linuxvictim Ansible node.
In this case, because the process is automated and will run frequently,
the administrator placed the username
and password
directly into the playbook.
It should be clear to us by now why this is bad practice.
System administrators sometimes consider plain text
password inclusion to be “safe enough”
in a context like this one,
because the script is readable
only for the Ansible administrator user
and root.
When the Ansible administrator runs the playbook on the node,
in this case our linuxvictim machine,
it attempts to connect to the MySQL server
and dump the database.
However, because of how it is executed, the playbook will log the shell command
to syslog by default.
An exception to this is when the no_log option is set to true in the playbook.
Let’s log in to the linuxvictim host as offsec,
and examine the contents of the syslog file.
The username, password, and host for the MySQL database
are all exposed in the log entry.
With this information, we now have access to the MySQL database
on the remote server.
We can gather more sensitive information
and potentially pivot to that host as well.
While these techniques won’t work in every Ansible infrastructure instance,
they suggest vectors against automated IT configuration engines
we may encounter
during a penetration test.