USN-8832-1: Ubuntu 24.04 Booth Authentication Bypass — Detection, Patching, and Hardening Guide

Canonical has published USN-8832-1, an Ubuntu security notice addressing a serious authentication bypass vulnerability in Booth on Ubuntu 24.04 LTS (Noble Numbat). According to the advisory, the flaw could allow unintended access to network services — which, in the context of Booth, is a significant problem.

For those who don't run Pacemaker-based high-availability (HA) stacks: Booth is the ticket manager for geo-distributed Linux clusters. It arbitrates which site holds a "ticket," and that ticket determines which cluster site is allowed to run a given service or resource group. Booth daemons (boothd) communicate across sites over the network, and access control to the Booth service is a trust boundary. If that trust boundary can be bypassed, an attacker positioned to reach the Booth port can potentially influence or abuse cluster-facing network services — in a worst case, tampering with HA arbitration or pivoting into services that assume Booth-level trust.

HA clustering infrastructure typically sits in the most critical tier of an environment: database clusters, payment processing backends, healthcare record systems. An authentication bypass here is not a theoretical nuisance — it is a direct threat to availability guarantees and to the integrity of failover decisions.

Technical Analysis

Affected Products and Platforms

• Product: Booth (cluster ticket manager for Pacemaker/Corosync geo-clusters)
• Affected platform: Ubuntu 24.04 LTS (Noble)
• Affected package: booth (and the booth-pacemaker integration where deployed)
• Advisory: USN-8832-1 — Booth vulnerability and the corresponding entry at ubuntu.com/security/notices/USN-8832-1

Note on CVE attribution: The source advisory summary does not publish a CVE identifier in the headline material. Defenders should track USN-8832-1 directly and confirm any CVE mapping on Canonical's notice page before keying vulnerability-scanner exceptions. Do not dismiss the issue for lack of a CVE — USNs frequently aggregate one or more upstream fixes, and the remediation path (package update) is identical either way.

How the Vulnerability Works (Defender's Perspective)

Based on the advisory language — "Booth could allow unintended access to network services" — the defect sits in how the Booth daemon authenticates or authorizes peers/clients connecting to its network listener. Booth normally listens on TCP port 9929 (the IANA-registered booth port) and uses a shared authentication key file (authkey, configured in /etc/booth/booth.conf) to authenticate site-to-site communication.

The practical attack chain a defender should model:

1. Reconnaissance: Attacker scans for exposed TCP 9929 listeners. Booth ports are frequently left reachable beyond their intended cluster peers because HA networks are often flat management segments, and firewalls around them are lax.
2. Authentication bypass: The flaw allows the attacker to interact with the Booth service without presenting valid credentials — bypassing whatever access control the daemon enforces.
3. Impact: Unintended access to network services governed by or adjacent to Booth — potentially influencing ticket state, querying cluster information, or leveraging the daemon's trusted position to reach services that assume authenticated cluster traffic.

Exploitation requirements favor the defender: this is a network-facing flaw, so it requires network reachability to the Booth listener. There is no indication in the advisory of user interaction or local-only prerequisites. Any system where TCP 9929 is reachable from untrusted or broadly trusted segments should be treated as exposed.

Exploitation Status

• In-the-wild exploitation: Not confirmed in the advisory summary at time of writing.
• Public PoC: None confirmed in the source material.
• CISA KEV: Not listed at time of writing.

Treat the absence of confirmed exploitation as a patching window, not a comfort blanket. Authentication bypasses in network daemons historically get weaponized quickly once technical details circulate, and cluster management ports are high-value targets for ransomware operators who know that corrupting HA failover amplifies business impact.

Detection & Response

The observable surface for this threat is narrow and specific: the boothd daemon, its configuration under /etc/booth/, and its network listener on TCP 9929. That narrowness is good news — it means high-fidelity detection is achievable without flooding your queue.

Sigma Rules

---
title: Booth Daemon Spawning Unexpected Child Process
description: Detects the Booth cluster ticket daemon (boothd) spawning shells or command interpreters, consistent with post-exploitation activity following compromise of the Booth network service (USN-8832-1).
references:
  - https://linuxsecurity.com/advisories/ubuntu/ubuntu-8832-1-booth
  - https://attack.mitre.org/techniques/T1059/004/
author: Security Arsenal
date: 2026/01/01
logsource:
  category: process_creation
  product: linux
detection:
  selection_parent:
    ParentImage|endswith:
      - '/boothd'
  selection_child:
    Image|endswith:
      - '/sh'
      - '/bash'
      - '/dash'
      - '/python'
      - '/python3'
      - '/perl'
      - '/nc'
      - '/ncat'
      - '/socat'
  condition: selection_parent and selection_child
falsepositives:
  - Highly unlikely; boothd does not spawn shells in normal operation
level: high
---
title: Network Connection to Booth Cluster Port from Non-Cluster Host
description: Detects inbound connections to the Booth daemon listener (TCP 9929) from hosts outside the defined cluster peer set. Legitimate Booth traffic occurs only between configured site/arbitrator nodes.
references:
  - https://linuxsecurity.com/advisories/ubuntu/ubuntu-8832-1-booth
  - https://attack.mitre.org/techniques/T1190/
author: Security Arsenal
date: 2026/01/01
logsource:
  category: network_connection
  product: linux
detection:
  selection:
    DestinationPort: 9929
  filter_known_cluster_peers:
    SourceIp:
      - '10.0.10.0/24'
      - '10.0.20.0/24'
  condition: selection and not filter_known_cluster_peers
falsepositives:
  - Monitoring/health-check systems polling the Booth port; add them to the peer filter
level: high
---
title: Booth Configuration or Authkey Modification
description: Detects modification of Booth configuration files or the shared authentication key, which could indicate an attacker weakening or altering cluster authentication controls.
references:
  - https://linuxsecurity.com/advisories/ubuntu/ubuntu-8832-1-booth
  - https://attack.mitre.org/techniques/T1552/001/
author: Security Arsenal
date: 2026/01/01
logsource:
  category: file_event
  product: linux
detection:
  selection:
    TargetFilename|startswith: '/etc/booth/'
  filter_root_services:
    Image|endswith:
      - '/dpkg'
      - '/apt'
      - '/apt-get'
      - '/unattended-upgrade'
  condition: selection and not filter_root_services
falsepositives:
  - Configuration management (Ansible, Puppet, Chef) deploying booth.conf changes; filter by management host context
level: medium

KQL — Microsoft Sentinel / Defender

Booth events reach Sentinel through Syslog/CEF ingestion from Linux hosts, and process/network telemetry via the Defender for Endpoint Linux agent or Azure Monitor agent. These hunts target the same three observables: unexpected connections to TCP 9929, boothd process anomalies, and config tampering.

// Hunt 1: Inbound connections to Booth listener (TCP 9929) — via Syslog/CEF or firewall logs
// Replace the CIDR with your actual cluster peer networks
let ClusterPeers = dynamic(["10.0.10.", "10.0.20."]);
CommonSecurityLog
| where TimeGenerated > ago(7d)
| where DestinationPort == 9929
| extend IsPeer = tostring(ClusterPeers) contains substring(SourceIP, 0, 8)
| where SourceIP !has_any ("10.0.10.", "10.0.20.")
| summarize ConnectionCount = count(), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated)
    by SourceIP, DestinationIP, DestinationPort, DeviceAction
| order by ConnectionCount desc;

// Hunt 2: boothd spawning child processes — via Defender for Endpoint Linux telemetry
DeviceProcessEvents
| where TimeGenerated > ago(7d)
| where InitiatingProcessFileName =~ "boothd"
| where FileName in~ ("sh", "bash", "dash", "python", "python3", "perl", "nc", "ncat", "socat", "curl", "wget")
| project TimeGenerated, DeviceName, InitiatingProcessFileName, FileName,
          ProcessCommandLine, AccountName, InitiatingProcessCommandLine
| order by TimeGenerated desc;

// Hunt 3: Syslog anomalies from boothd — repeated auth/connection failures or unexpected client strings
Syslog
| where TimeGenerated > ago(7d)
| where ProcessName =~ "boothd"
| where SyslogMessage has_any ("auth", "denied", "invalid", "refused", "unknown", "fail")
| summarize EventCount = count(), SampleMessage = any(SyslogMessage)
    by Computer, Facility, SeverityLevel, bin(TimeGenerated, 1h)
| order by EventCount desc;

Velociraptor VQL

For triage on suspected hosts, this artifact enumerates the Booth listener state, the running daemon, and recent modification times on the Booth configuration tree — enough to establish whether the daemon is exposed and whether configs changed around a suspicious window.

-- Booth exposure and integrity triage (USN-8832-1)
-- Check listening state on TCP 9929, running boothd processes, and config file mtimes

SELECT Pid, Name, CommandLine, Username, CreateTime
FROM pslist()
WHERE Name =~ 'boothd'
   OR CommandLine =~ 'booth'

SELECT Pid, Name, Laddr, Raddr, Status
FROM netstat()
WHERE Laddr.IP =~ '0.0.0.0|::'
  AND Laddr.Port = 9929

SELECT FullPath, Size, Mtime, Ctime, Mode
FROM glob(globs='/etc/booth/*')
ORDER BY Mtime DESC

Remediation and Verification Script

#!/bin/bash
# USN-8832-1 remediation/verification for Ubuntu 24.04 Booth hosts
# Run on every cluster node and arbitrator running the booth package.
set -euo pipefail

echo "=== [1/5] Checking if booth is installed ==="
if ! dpkg -l booth 2>/dev/null | grep -q '^ii'; then
    echo "booth package not installed — host not affected. Exiting."
    exit 0
fi

echo "=== [2/5] Current booth version ==="
dpkg -l booth | awk '/^ii/ {print $2, $3}'

echo "=== [3/5] Applying USN-8832-1 update ==="
apt-get update -qq
apt-get install --only-upgrade -y booth

echo "=== [4/5] Post-patch version (verify against ubuntu.com/security/notices/USN-8832-1) ==="
apt-cache policy booth | grep -A1 'Installed'

echo "=== [5/5] Exposure checks ==="
echo "--- Listening sockets on 9929 ---"
ss -tlnp | grep ':9929' || echo "No listener on TCP 9929"

echo "--- Firewall rules referencing 9929 ---"
ufw status 2>/dev/null | grep -i '9929' || iptables -L -n 2>/dev/null | grep '9929' || echo "No explicit rules found — verify network ACLs restrict 9929 to cluster peers only"

echo "--- Recent config changes under /etc/booth ---"
find /etc/booth -type f -mtime -7 -exec ls -la {} \; 2>/dev/null || echo "/etc/booth not present"

echo "=== Remediation complete. Review output above and confirm version matches the USN fixed release. ==="

Remediation

1. Patch immediately. Apply the updated booth package per USN-8832-1. Confirm the installed version against the fixed release listed on Canonical's notice page (ubuntu.com/security/notices/USN-8832-1) — do not assume unattended-upgrades has already covered cluster nodes, which are frequently excluded from automatic updates.
2. Verify package provenance. Use apt-cache policy booth and apt changelog booth to confirm the update came from the official Ubuntu security repository.
3. Restrict network exposure — this is your compensating control regardless of patch status. TCP 9929 should be reachable only from the configured Booth site peers and arbitrators. Enforce this at host firewalls (ufw/nftables) and at network segmentation ACLs. If your Booth listener is bound to 0.0.0.0 and reachable from a general server VLAN, fix that today.
4. Audit authentication configuration. Confirm authkey is configured in /etc/booth/booth.conf and that the key file has restrictive permissions (0600, owned by the Booth service account). Rotate the shared key if you have any reason to suspect prior exposure of the listener.
5. Hunt before and after patching. Run the KQL and VQL hunts above across your cluster estate for at least the past 7–14 days. An authentication bypass means exploitation may leave no patch-gap artifact — look for behavioral anomalies instead.
6. Plan the service restart carefully. Updating boothd on a live geo-cluster requires coordinated rolling restarts to avoid ticket arbitration flaps. Schedule it, but do not defer beyond your standard critical-patch SLA (24–72 hours for network-facing auth bypasses is a defensible internal target).
7. Watch for the CVE mapping. Subscribe to the USN feed and update your vulnerability scanner correlation once Canonical publishes CVE linkage, so the finding closes out properly in your VM platform.

HA cluster infrastructure is the last place you can afford an authentication bypass. The attack surface is small, the fix is a package update plus firewall hygiene, and the detection surface is narrow enough to monitor with high fidelity. There is no good reason for this one to linger.

Related Resources

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub