Insecure Deserialization with Mutual Tls
How Insecure Deserialization Manifests in Mutual Tls
Insecure deserialization in Mutual Tls environments creates unique attack vectors that exploit the trust established between authenticated parties. When Mutual Tls certificates authenticate both client and server, serialized objects often bypass traditional security controls, assuming the Mutual Tls layer provides sufficient protection.
The most common pattern involves serialized session objects or API tokens transmitted over Mutual Tls connections. Consider a typical Mutual Tls authentication flow where a client presents a certificate, receives a serialized session token, and then includes this token in subsequent requests:
// Vulnerable Mutual Tls session handling
class SessionManager {
public byte[] createSession(ClientCert cert) {
Session session = new Session(cert.getSubjectDN(), System.currentTimeMillis());
return serialize(session); // Unsafe deserialization
}
public Session validateSession(byte[] data) {
return (Session) deserialize(data); // No validation
}
}The critical vulnerability occurs because Mutual Tls provides authentication but not integrity verification of the serialized payload. An attacker who compromises a Mutual Tls endpoint can inject malicious serialized objects that execute arbitrary code during deserialization.
Another Mutual Tls-specific scenario involves certificate revocation lists (CRLs) or Online Certificate Status Protocol (OCSP) responses transmitted as serialized objects. These responses are often trusted implicitly due to the Mutual Tls context:
// Vulnerable OCSP response handling
public class OCSPValidator {
public void validate(byte[] ocspResponse) {
OCSPResponse response = (OCSPResponse) deserialize(ocspResponse);
}
}API endpoints secured with Mutual Tls frequently deserialize configuration objects or policy definitions. The Mutual Tls layer leads developers to assume these objects are safe:
# Vulnerable policy deserialization in Mutual Tls API
class PolicyAPI:
def update_policy(self, cert, policy_data):
The combination of Mutual Tls authentication and insecure deserialization creates a false sense of security. Attackers who obtain a valid client certificate through various means can exploit these deserialization vulnerabilities without triggering Mutual Tls authentication failures.
Mutual Tls-Specific Detection
Detecting insecure deserialization in Mutual Tls environments requires examining both the Mutual Tls handshake and the serialized payload handling. The detection process focuses on identifying where Mutual Tls authentication creates blind spots for deserialization vulnerabilities.
During Mutual Tls handshake analysis, look for endpoints that accept serialized objects immediately after certificate authentication. The vulnerability pattern typically shows:
| Detection Phase | What to Look For | Red Flags |
|---|---|---|
| Handshake Analysis | Certificate authentication followed by binary data exchange | No payload validation after Mutual Tls auth |
| Payload Inspection | Serialized object formats (Java serialization, Python pickle, etc.) | Direct deserialization without integrity checks |
| Trust Boundary Analysis | Mutual Tls context used as sole security control | Missing signature verification on serialized data |
middleBrick's scanner specifically tests Mutual Tls endpoints for deserialization vulnerabilities by:
- Establishing Mutual Tls connections with test certificates
- Submitting serialized payloads that trigger known deserialization gadgets
- Analyzing response patterns for deserialization success indicators
- Checking for unsafe deserialization in OpenAPI specifications referenced by Mutual Tls endpoints
The scanner examines Mutual Tls endpoints for common deserialization patterns:
// middleBrick detection report snippet
{
"endpoint": "https://api.example.com/mtls/data",
"mutual_tls": true,
"deserialization_vulnerabilities": [
{
"type": "java_deserialization",
"severity": "high",
"description": "Unsafe ObjectInputStream usage after Mutual Tls auth",
"remediation": "Implement validation and use safe deserialization libraries"
}
}Static analysis of Mutual Tls-enabled codebases should flag:
- Deserialization calls immediately following certificate validation
- Serialized objects transmitted over Mutual Tls channels
- Missing cryptographic integrity checks on deserialized data
- Unsafe deserialization libraries (Python pickle, Java native serialization)
Runtime detection involves monitoring for deserialization exceptions and unusual object graph constructions that indicate exploitation attempts against Mutual Tls endpoints.
Mutual Tls-Specific Remediation
Remediating insecure deserialization in Mutual Tls environments requires architectural changes that maintain Mutual Tls benefits while adding critical integrity verification. The key principle: never trust serialized data based solely on Mutual Tls authentication.
The most effective approach uses digital signatures on serialized payloads. Even with Mutual Tls, each serialized object should include cryptographic integrity verification:
// Secure Mutual Tls deserialization with signatures
class SecureSessionManager {
private Signature signer = Signature.getInstance("SHA256withRSA");
public byte[] createSession(ClientCert cert) throws Exception {
Session session = new Session(cert.getSubjectDN(), System.currentTimeMillis());
.put(serialized)
.put(signature)
.array();
}
public Session validateSession(byte[] data) throws Exception {
ByteBuffer buffer = ByteBuffer.wrap(data);
buffer.get(serialized);
buffer.get(signature);
if (!signer.verify(serialized, signature)) {
throw new SecurityException("Invalid session signature");
}
return (Session) deserialize(serialized);
}
}For Mutual Tls APIs using JSON Web Tokens (JWT), implement proper token validation with cryptographic signatures:
# Secure JWT handling in Mutual Tls API
from jwt import PyJWT
import json
class SecureMTLSAPI:
def __init__(self):
def handle_request(self, cert, auth_header):
# Validate JWT signature regardless of MTLS auth
Alternative safe deserialization approaches for Mutual Tls environments:
- Data Transformation: Convert serialized objects to safe formats (JSON, XML) before processing
- Allowlist Deserialization: Only deserialize to specific, safe classes using filters
- Versioned Serialization: Include version numbers and validate against schema
middleBrick's remediation guidance for Mutual Tls deserialization issues includes:
| Issue Type | Recommended Fix | Implementation Complexity |
|---|---|---|
| Java deserialization | Switch to JSON + digital signatures | Medium |
| Python pickle | Use JSON + JWT tokens | Low |
| XML deserialization | XML with schema validation + signatures | High |
Testing the remediation involves:
# Test secure deserialization with middleBrick
middlebrick scan https://api.example.com/mtls/secure-endpoint \
--test-deserialization \
--mtls-cert client.crt \
--mtls-key client.keyThe key insight: Mutual Tls provides authentication and encryption, but deserialization security requires separate integrity controls. Never combine authentication with deserialization without cryptographic verification.
Frequently Asked Questions
Why doesn't Mutual Tls authentication alone protect against deserialization attacks?
Mutual Tls authenticates the parties involved and encrypts the communication channel, but it doesn't verify the integrity or safety of the serialized data itself. An attacker with a valid client certificate can still send malicious serialized objects that exploit deserialization vulnerabilities. Authentication and data integrity are separate security concerns that require different controls.
How does middleBrick detect deserialization vulnerabilities in Mutual Tls APIs?
middleBrick establishes Mutual Tls connections using test certificates, then submits payloads designed to trigger deserialization gadget chains. The scanner analyzes response patterns, error messages, and timing to identify vulnerable deserialization code paths. It also examines OpenAPI specifications for endpoints that accept binary data immediately after Mutual Tls authentication, flagging potential deserialization risks.