Disclaimer: This post focuses on Debian-based and Fedora/RHEL-based distributions and packaging.
Everybody using a GNU/Linux distribution most likely knows that packages used by the given distribution are somehow signed and such signatures are somehow verified. Usually, this knowledge comes with the first requirement to import some key when an extra package repository is being added to the system (the standard repositories of a distribution use keys that are present and trusted by default). While users don’t usually pay much attention to the key import process and the particular key used, these keys and signatures are actually parts of the critical security mechanisms in their systems.
We are writing to inform you of a recently discovered security issue in the CFEngine Enterprise web UI, Mission Portal. The issue has been fixed in the recently released 3.21.6 and 3.24.1 versions. Prior versions (3.24.0, 3.21.5, and below) are affected. We have no indications of this issue being exploited or known outside of the company. The issue was discovered thanks to the vulnerability scanning software Acunetix by Invicti.
Description On the affected versions, some fields lack input validation, allowing an authenticated user with administrator-level privileges to enter javascript into input text fields, which will be evaluated by other users of the system who open up the same form. In addition to fixing this specific issue of confirmed XSS, we also added much more strict input validation to many other fields in Mission Portal, to prevent similar issues, even though we were not able to find something exploitable in those cases.
Today, we are pleased to announce the release of CFEngine 3.25.0! The code word for this release is auditability. Being a non-LTS (not supported) release, this release allows users to test the new functionality we’ve been working on before it arrives in an LTS release ~1 year from now.
What’s new The audit log CFEngine Mission Portal now logs user actions in a structured audit log. This means you can go back and see who edited group data, who deleted a host, who created a user, etc. The audit log can be filtered by time and date, resource type, who performed the action, and what was affected.
Within the configuration management space, people often distinguish between agent-based and agent-less approaches. In short, an agent-based solution means that you install a software agent to run in the background / periodically on the system. That software agent then makes changes to the system as desired, and also commonly communicates over the network to send and receive updates, policy, commands, scripts, data, etc. On the other hand, an agentless system does not involve installing something new, they instead rely on some software which is (presumed) already installed, like the SSH server, which can be used to acces and make changes to the system.
The rather serious recent OpenSSH vulnerability CVE-2024-6387 could affect as many as 14 million server instances exposed on the internet. Let’s make it easy to examine your infrastructure and see if you need to do any upgrades or mitigations.
On the back of my CFEngine T-shirt it says:
Know more, React faster When I have a problem to solve in CFEngine I look for an easy and correct solution. CFEngine Build is a good first place to look. Two modules stand out as possibly useful;
Security Technical Implementation Guides (STIGs) are an excellent body of knowledge to leverage in securing your infrastructure. With the stig-rhel-7 module you can easily add inventory and remediation policy for RHEL 7 with CFEngine. Do note that as of March 2024 this module does not provide comprehensive coverage but rather an initial 10 findings are implemented.
Setup To start I installed CFEngine Enterprise on a local virtual machine, logged in and started a new Build project with the stig-rhel-7 module added and configured to enforce (as opposed to only warn).
Having a list of software that is allowed to be installed on a host is a strategy to prevent and fix security gaps and maintain compliance with operational guidelines. This zero-trust methodology ensures that only explicitly permitted applications are allowed to be present on a host unlike package block-listing which enumerates an explicit list of software that is not allowed to be present. In fact, with a software allow-list, you are essentially block-listing everything except the software you allow.
Can you trust the integrity of your base operating system runtime?
Jason Rogers and Dr. Wesley Peck of Invary join Cody, Craig and Nick to chat about their Runtime Integrity technology. They discuss the challenges of Trust, Information Technology Knowledge Management, and how Invary fits in the SecOps, Systems Automation, Security and Compliance landscape. Nick shares an example of an early integration between CFEngine and the Invary RISe agent1 with reporting in Mission Portal and talks about the different ways to approach integration.
For the holiday season gift yourself an improved infrastructure security posture.
Join Craig, Cody, and Nick as they wrap up 2022 and the 20th episode of “The agent is in” reviewing CFEngines’ 2022 Holiday Security Calendar which has advice picked straight from industry standard security hardening guides like the OpenSCAP Security Policies and Security Technical Implementation Guides (STIGs). Craig demos new modules like maintainers-in-motd, file-permissions, enable-aslr, highlights guidance on writing your own security policies and more.
Thank you for following along with our security themed holiday calendar. Today, we summarize the last half of the calendar, in case you missed some days.
Part 1 recap (12/25) A couple of weeks ago, on the 12th of December, we posted a recap of the first 12 days:
cfengine.com/blog/2022/security-holiday-calendar-part-1
File integrity monitoring with CFEngine (13/25) On the 13th, we took a look at how you can use File Integrity monitoring in CFEngine for similar functionality to AIDE:
