Chaining 6 Vulnerabilities in LogPoint SIEM/SOAR: A PreāAuthenticated Remote Code Execution Exploit
During an internal security assessment of LogPointās SIEM/SOAR stack, the author uncovered a chain of six small bugs that, when combined, led to a preāauthenticated remote code execution (RCE) on the appliance. The paper walks through the systematic discovery of each flawāfrom Nginx routing misconfigurations to hardācoded JWT secrets, a ServerāSide Request Forgery (SSRF), a codeāevaluation sink, and a static AES keyāand demonstrates how they interlock to facilitate an attackerās full compromise of the platform.
## 1. Introduction
In MayāÆ2024 I began a formal review of LogPointās SIEM/SOAR core as a part of a broader dueādiligence exercise. With the typical 24āhour āstressātestā timeline, I immediately identified three critical vulnerabilities that could allow an attacker to bypass authentication entirely. After responsible disclosure, I returned months later to map the full attack surface, discovering that six seemingly harmless bugs could be chained into a preāauthenticated RCE.
The following article details that journey, focusing on technical accuracy, attacker reasoning, and the logical progression that turns isolated bugs into a single destructive vector.
## 2. Architecture Overview
LogPointās platform is split between legacy hostābased services (Python/Flask, MongoDB, OSālevel utilities) and new SOAR microāservices (Java, Docker). Two Nginx layers form the outer perimeter:
1. **Edge Nginx** ā Listens on ports 80/443 and proxies `https://localhost:9443/` for any path beginning with `/soar/`.
2. **Inner Nginx (in the Docker network)** ā Distributes traffic to several containers: `api-service`, `scheduler`, `notifications`, `userāmanagement`, and an internal Elasticsearch instance.
The lack of hardening between the host and the containers allows any internal request to reach a fullāblown container network from an externally authenticated user.
## 3. The Vulnerability Chain
Below is a concise mapping of each identified bug and how one feeds into the next.
| Step | Bug | Impact | How It Exposes the Next Step |
|------|-----|--------|------------------------------|
| 1 | **Nginx Path Reārouting** | Unprotected internal endpoints become reachable via URL manipulation. | Provides a direct path from the external network to a REST API that should be internal.
| 2 | **Hardācoded JWT Secret** | Ability to forge `secbi_auth_token` for any user. | Grants access to Java microāservicesā privileged API, yielding an admin API key.
| 3 | **SOAR User Escalation** | Leverages the API key to query `/user/apikey`, revealing the internal `secbi` account. | Enables authenticated communication with the legacy Python backend.
| 4 | **SSRF to Python API** | The `private/user_access_key` endpoint returns the adminās secret key. | Allows the attacker to stage an admin session in the Python layer.
| 5 | **Python CodeāEval Sink** | `_Condition.evaluate()` blindly executes `eval()` on a userāsupplied value in a rule engine. | Provides the only execution point that can be controlled via rule data.
| 6 | **Static AES Key & Rule Import** | Imported alert rules are decrypted with a fixed key; no validation after decryption. | Lets an attacker inject arbitrary `eval()` payloads into an otherwise validated rule field. |
### 3.1 Bug 1 ā Nginx Path Misconfiguration
The first Nginx on the host exposed any `/soar/*` path to the internal Docker cluster without authentication checks. A simple `GET /soar/sso/v1/login` request reached an endpoint that should only be called by container services, exposing credentials that would normally be hidden.
### 3.2 Bug 2 ā Hardācoded JWT Secret
In the Java microāservices, the class `JWTLoginAuthorizationManager` contains
```java
private static final String JWT_ENCODED_SECRET = "WW4wWVRGQVdid0ZsTDhXWFNUQXJDQ0JWVEdzPQ==";
```
The Base64 string decodes to a constant key used by all JWT verification logic. An attacker can forge a valid token with any `username` and `role`, bypassing every service that relies on `secbi_auth_token`.
### 3.3 Bug 3 ā Elevating to the Internal `secbi` Account
Using a forged JWT, the attacker authenticates to the `/sso/v1/user/auth/apikey` endpoint and retrieves an API key belonging to the privileged `secbi` account. This key is accepted by all subsequent SOAR APIs, allowing crossāservice calls that were originally scoped to the user context.
### 3.4 Bug 4 ā SSRF Exploit in the Python Backend
From the container, an SSRF path was discovered: `/private/user_access_key`. It returns the admin's database `secret_key`, something that **must not** be exposed. The attacker used this key to call the legacy Python endpoint `/initapp`, which accepts a JSON payload with `user: 'admin'` and `secret: `. Successful authentication yields a session cookie for the admin user.
### 3.5 Bug 5 ā CodeāEvaluation Sink in the Alert Engine
The Python rule engine contains the class `_Condition`:
```python
class _Condition:
@classmethod
def evaluate(cls, left, right, operator):
if operator in ('<', '>', '<=', '>=', '==', '!='):
return eval(str(left) + str(operator) + str(right))
```
The `right` operand comes directly from a ruleās `trigger_value` field, which is **never validated** before use. As a result, an attacker can inject an arbitrary `eval()` expression into this field.
### 3.6 Bug 6 ā Static AES Key in Rule Import
When a user imports an alert PAK file, the platform decrypts it using a secret key derived from a hardācoded string (`FLASK_APP_ENCRYPTION_KEY = 'ImmUnEsEcUrIty'`). The decrypted rule data is stored without reāvalidation. By creating a custom PAK file that contains the same `eval()` payload used in BugāÆ5, a rule can be imported and later executed by the engine.
### 3.7 Final Exploit Flow
1. **Route to internal** ā external request to `/soar/sso/v1/login` exposed by BugāÆ1.
2. **Forge token** ā produce a JWT using the hardācoded secret from BugāÆ2.
3. **Elevate to admin** ā fetch API keys via `/sso/v1/user/auth/apikey` (BugāÆ3).
4. **SSRF for admin key** ā obtain the admin secret via `/private/user_access_key` (BugāÆ4).
5. **Create admin session** ā POST to `/initapp` with the secret (BugāÆ4, continued).
6. **Import malicious rule** ā craft and upload a PAK file that contains an `eval()` expression, using the static AES key to decrypt (BugāÆ6).
7. **Trigger rule** ā cause the engine to evaluate the rule; the `eval()` payload is executed, delivering a reverse shell.
## 4. Disclosure Timeline
| Date | Event |
|------|-------|
| 30ā05ā2024 11:00 BST | Initial notification to LogPoint support (no ticket creation possible). |
| 30ā05ā2024 15:01 BST | LinkedIn InMail outreach to LogPoint executives. |
| 30ā05ā2024 17:28 BST | Executive reply; start of correspondence. |
| 30ā05ā2024 22:18 BST | Confirmation that LogPoint has started remediation. |
| 10ā06ā2024 12:03 BST | Vendor confirms active work on a fix. |
| 22ā07ā2024 13:03 BST | Additional eight critical vulnerabilities published. |
| 3ā10ā2024 | Vendor releases patches (v7.5.0). |
| 14ā01ā2025 | Public blog post announcing patch release. |
| 02ā01ā2026 | Decision to delay full technical writeāup due to vendor communication gaps. |
The CVE assignments reflect a range of severity levels, with the principal RCE bugs rated **High**.
## 5. Lessons Learned
1. **Never rely on pathābased access controls** ā HTTP proxies that ignore user authentication can expose entire internal services.
2. **Hardācoded encryption keys are a single point of failure** ā they can be reverseāengineered from a binary or decompiled code.
3. **Crossāservice authentication should be explicit** ā shared secrets or JWTs must be validated against a secure, rotateāable key store, not a static string.
4. **SSRF is a powerful pivot point** ā internal services that communicate over HTTP should enforce strict whitelisting of target hosts.
5. **Every deserialization or decryption operation should be followed by validation** ā ātrust after decryptā is a recipe for remote code execution.
## 6. Conclusion
The LogPoint SIEM/SOAR case demonstrates how a chain of small, overlooked bugs can combine into a complete preāauthenticated remote code execution vector. The experience underscores the importance of holistic threat modelling that spans legacy infrastructure, container boundaries, and interāservice authentication mechanisms. For platform developers, the key takeaway is to apply defenseāinādepth principles consistently across all layers ā from HTTP proxies to cryptographic primitives.
---
This article synthesizes the authorās original investigation, providing a concise yet comprehensive look at the attack surface, the discovered bugs, and the strategic measures needed to mitigate such complex exploit chains.