CVE-2024-43180

4.3 MEDIUM

📋 TL;DR

IBM Concert 1.0 fails to set the secure attribute on authorization tokens and session cookies, allowing attackers to intercept these cookies when users access HTTP links. This vulnerability enables session hijacking and unauthorized access to user accounts. All users of IBM Concert 1.0 are affected.

💻 Affected Systems

Products:
  • IBM Concert
Versions: 1.0
Operating Systems: All platforms running IBM Concert
Default Config Vulnerable: ⚠️ Yes
Notes: All deployments of IBM Concert 1.0 are vulnerable regardless of configuration.

📦 What is this software?

⚠️ Risk & Real-World Impact

🔴

Worst Case

Attackers gain full administrative access to the IBM Concert system, compromising all user sessions and sensitive data.

🟠

Likely Case

Attackers hijack user sessions to access unauthorized information or perform actions as the compromised user.

🟢

If Mitigated

With HTTPS enforcement and proper network segmentation, risk is limited to internal attackers with network access.

🌐 Internet-Facing: HIGH - Any internet-facing deployment is vulnerable to cookie interception via HTTP links.
🏢 Internal Only: MEDIUM - Internal attackers with network access could intercept cookies on unencrypted internal traffic.

🎯 Exploit Status

Public PoC: ✅ No
Weaponized: LIKELY
Unauthenticated Exploit: ⚠️ Yes
Complexity: LOW

Exploitation requires tricking users into clicking HTTP links or planting malicious links on websites they visit.

🛠️ Fix & Mitigation

✅ Official Fix

Patch Version: Apply fix as per IBM advisory

Vendor Advisory: https://www.ibm.com/support/pages/node/7168234

Restart Required: Yes

Instructions:

1. Review IBM advisory at provided URL
2. Apply the recommended fix from IBM
3. Restart IBM Concert services
4. Verify secure attribute is set on all cookies

🔧 Temporary Workarounds

Enforce HTTPS Only

all

Configure web server to redirect all HTTP traffic to HTTPS and set HSTS headers

# Apache: Redirect HTTP to HTTPS in .htaccess or config
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
# Add HSTS header
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"

Web Application Firewall Rules

all

Configure WAF to block or flag HTTP requests containing session cookies

# Example ModSecurity rule
SecRule REQUEST_URI "@rx ^http://" \
"id:1001,phase:1,deny,status:403,msg:'HTTP request with session cookie detected'"

🧯 If You Can't Patch

  • Deploy network monitoring to detect HTTP traffic containing session cookies
  • Implement strict network segmentation to limit attack surface

🔍 How to Verify

Check if Vulnerable:

Use browser developer tools to inspect cookies - check if session/authorization cookies lack 'Secure' attribute when accessed via HTTP

Check Version:

Check IBM Concert version via administrative interface or configuration files

Verify Fix Applied:

Verify cookies have 'Secure' attribute set and cannot be transmitted over HTTP connections

📡 Detection & Monitoring

Log Indicators:

  • HTTP requests containing session cookie values
  • Multiple failed authentication attempts from new IP addresses

Network Indicators:

  • Unencrypted HTTP traffic containing Set-Cookie headers
  • HTTP requests to sensitive endpoints

SIEM Query:

source="web_logs" AND (uri="http://*" AND cookie="*session*" OR cookie="*auth*")

🔗 References

📤 Share & Export