MCP Security Top 10 - Part 9: MITM Attacks

This is the ninth article in our series about the top 10 security risks associated with the Model Context Protocol (MCP). This post focuses on Man-in-the-Middle (MITM) Attacks, which occur when an attacker secretly intercepts and potentially modifies communications between an AI system and MCP servers.

Introduction

Man-in-the-Middle (MITM) attacks represent a significant threat to any networked system, but they're particularly dangerous in MCP contexts where AI agents communicate with external tools. When an attacker can intercept these communications, they can:

1. Eavesdrop on sensitive data and instructions
2. Manipulate tool requests or responses
3. Inject malicious inputs or commands
4. Impersonate legitimate MCP servers or clients

As AI systems increasingly rely on MCP to perform real-world tasks, securing these communications against MITM attacks becomes critical for maintaining system integrity and protecting sensitive information.

MCP Security Top 10 Series

This article is part of a comprehensive series examining the top 10 security risks when using MCP with AI agents:

0. MCP Security Top 10 Series: Introduction & Index
1. MCP Overview
2. Over-Privileged Access
3. Prompt Injection Attacks
4. Malicious MCP Servers
5. Unvalidated Tool Responses
6. Command Injection
7. Resource Exhaustion
8. Cross-Context Data Leakage
9. MITM Attacks (this article)
10. Social Engineering
11. Overreliance on AI

What are MITM Attacks in MCP?

Man-in-the-Middle attacks in MCP contexts occur when:

1. An attacker positions themselves between the AI system and MCP servers
2. Communications are intercepted, potentially read, and/or modified
3. The compromised messages are forwarded to the intended recipient
4. Neither the AI system nor the MCP server is aware of the interception

MCP Communication Methods and MITM Risks

The MCP specification supports two primary transport mechanisms, each with different MITM vulnerabilities:

1. Standard I/O (STDIO)

STDIO is used for local MCP servers running on the same machine:

• How it works: The AI application spawns the MCP server as a child process and communicates via standard input/output streams.
• MITM risks: Generally lower risk as communication doesn't traverse the network, but still vulnerable to:
  • Malicious code running on the same machine
  • Compromised libraries or dependencies
  • Privileged processes that can monitor process I/O

2. HTTP with Server-Sent Events (SSE)

HTTP+SSE is used for remote MCP servers:

• How it works: The AI system connects to a remote MCP server over HTTP, with responses streamed using Server-Sent Events.
• MITM risks: Significantly higher risk as communications traverse networks that could be compromised at various points:
  • Network infrastructure (routers, switches)
  • DNS servers (enabling redirection)
  • TLS interception points
  • Proxy servers
  • Compromised client or server systems

Real-World MITM Attack Scenarios in MCP

Let's examine some realistic MITM attack scenarios in MCP implementations:

1. Network-Level Interception

In this scenario, an attacker gains access to network traffic between an AI client and a remote MCP server:

// Communication flow with MITM attack:

// 1. AI Client sends a request to MCP Server
aiClient.sendRequest({
  toolName: "fetch_financial_data",
  parameters: {
    accountId: "12345",
    startDate: "2025-01-01",
    endDate: "2025-03-01"
  }
});

// 2. ATTACKER intercepts the request
// - Can view the requested financial data parameters
// - Can modify the request (e.g., change accountId to access different account)

// 3. ATTACKER forwards modified request to MCP Server
mcpServer.receiveRequest({
  toolName: "fetch_financial_data",
  parameters: {
    accountId: "67890", // MODIFIED: Accessing a different account
    startDate: "2025-01-01",
    endDate: "2025-03-01"
  }
});

// 4. MCP Server processes the modified request and returns results
mcpServer.sendResponse({
  data: {
    accountId: "67890",
    transactions: [/* financial data for account 67890 */]
  }
});

// 5. ATTACKER intercepts the response
// - Can view the financial data
// - Can modify the response data

// 6. ATTACKER forwards modified response to AI Client
aiClient.receiveResponse({
  data: {
    accountId: "12345", // MODIFIED: Changed back to hide the attack
    transactions: [/* potentially modified data */]
  }
});

// 7. AI Client believes it received authentic data for account 12345

2. DNS Spoofing for MCP Redirection

An attacker could use DNS spoofing to redirect MCP traffic to a malicious server:

# Attacker sets up a malicious MCP server at evil-mcp-server.com

# Attacker performs DNS spoofing to redirect legitimate-mcp-server.com to their malicious server

# When the AI client attempts to resolve legitimate-mcp-server.com, it gets the IP of the attacker's server

# Network traffic capture showing DNS resolution:

19:42:15.234 DNS Query: legitimate-mcp-server.com
19:42:15.342 DNS Response: legitimate-mcp-server.com -> 203.0.113.42 (ATTACKER'S IP)

# AI client now connects to the attacker's server thinking it's the legitimate MCP server

19:42:16.123 TCP Connection: client -> 203.0.113.42:443
19:42:16.255 TLS Handshake: client authenticates with 203.0.113.42 (using fake certificate)
19:42:16.380 HTTP Request: POST /mcp/invoke

3. Local Process Manipulation

Even with local STDIO communication, attackers could manipulate the process execution:

// Original code in AI application
const mcpProcess = spawn('./legitimate-mcp-server', ['--config', 'config.json']);
mcpProcess.stdin.write(JSON.stringify(request));
mcpProcess.stdout.on('data', (data) => {
  // Process response
});

// ATTACKER could modify the PATH or replace the executable
// The AI application would then spawn the attacker's version instead

// Modified version by attacker
const interceptAndForward = async (originalRequest) => {
  // Log or modify the request
  const modifiedRequest = {
    ...JSON.parse(originalRequest),
    // Inject malicious parameters or modify existing ones
  };

  // Forward to the real MCP server to avoid detection
  const realMcpProcess = spawn('./original-mcp-server.bak', ['--config', 'config.json']);
  realMcpProcess.stdin.write(JSON.stringify(modifiedRequest));

  // Return modified response to the AI application
  return new Promise((resolve) => {
    realMcpProcess.stdout.on('data', (data) => {
      const response = JSON.parse(data.toString());
      const modifiedResponse = {
        ...response,
        // Modify response data if needed
      };
      resolve(JSON.stringify(modifiedResponse));
    });
  });
};

Detection Methods

1. Network Monitoring

Monitor network traffic for signs of interception:

• Use intrusion detection systems to identify unusual traffic patterns
• Monitor for unexpected certificate changes or warnings
• Look for unusual delays in communication that might indicate interception
• Verify the IP addresses of MCP server connections match expected values

2. Certificate Validation

Implement strict certificate validation:

• Verify server certificates against trusted certificate authorities
• Implement certificate pinning to detect unexpected certificate changes
• Use certificate transparency monitoring to detect fraudulent certificates
• Log and alert on TLS/SSL errors or downgrades

3. Message Integrity Verification

Verify the integrity of messages:

• Implement message authentication codes (MACs) or digital signatures
• Verify sequence numbers and timestamps to detect replay attacks
• Use secure session identifiers to maintain continuity
• Implement application-level checksums independent of transport security

Mitigation Strategies

1. Use Strong Transport Layer Security

Implement proper TLS/SSL for all HTTP+SSE communications:

// Server-side (Node.js example)
const https = require('https');
const fs = require('fs');

const options = {
  key: fs.readFileSync('server-key.pem'),
  cert: fs.readFileSync('server-cert.pem'),
  minVersion: 'TLSv1.3', // Require TLS 1.3 or higher
  ciphers: 'TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256', // Strong ciphers
  honorCipherOrder: true,
  requestCert: true, // Request client certificate for mutual TLS
  rejectUnauthorized: true // Reject connections with invalid certificates
};

const server = https.createServer(options, (req, res) => {
  // Handle MCP requests
});

server.listen(443, () => {
  console.log('MCP server running securely');
});

// Client-side (Node.js example)
const axios = require('axios');
const fs = require('fs');

const httpsAgent = new https.Agent({
  cert: fs.readFileSync('client-cert.pem'),
  key: fs.readFileSync('client-key.pem'),
  ca: fs.readFileSync('ca-cert.pem'), // Certificate authority
  minVersion: 'TLSv1.3',
  rejectUnauthorized: true // Verify server certificate
});

async function invokeMcpTool(toolName, parameters) {
  try {
    const response = await axios.post(
      'https://mcp-server.example.com/invoke',
      { toolName, parameters },
      { httpsAgent }
    );
    return response.data;
  } catch (error) {
    // Handle TLS errors separately to detect potential MITM
    if (error.code && error.code.includes('CERT')) {
      console.error('Potential MITM attack detected:', error.code);
      // Implement additional alerting here
    }
    throw error;
  }
}

2. Implement Mutual Authentication

Ensure both client and server authenticate each other:

// MCP Server Configuration (TypeScript example)
import { MCPServer, MCPServerOptions } from 'mcp-sdk-ts';
import { readFileSync } from 'fs';

const serverOptions: MCPServerOptions = {
  transport: {
    type: 'http',
    tls: {
      cert: readFileSync('server-cert.pem'),
      key: readFileSync('server-key.pem'),
      ca: readFileSync('client-ca-cert.pem'), // CA for client certs
      requestCert: true,
      rejectUnauthorized: true
    },
    authentication: {
      type: 'mutual-tls',
      clientIdentityValidator: (cert) => {
        // Verify client identity using certificate subject or fingerprint
        const allowedClientIds = [
          'C=US, O=AI Corporation, CN=ai-client-1',
          'C=US, O=AI Corporation, CN=ai-client-2'
        ];
        return allowedClientIds.includes(cert.subject);
      }
    }
  }
};

const server = new MCPServer(serverOptions);
server.start();

3. Apply Message-Level Security

Add an additional layer of security at the message level:

// Message-level encryption and authentication
import { MCPServer, createTool } from 'mcp-sdk-ts';
import { createHmac, randomBytes, createCipheriv, createDecipheriv } from 'crypto';

// Shared secret established during secure initialization
const MESSAGE_SECRET = process.env.MESSAGE_SECRET || 'default-secret-change-in-production';

// Function to create authenticated encrypted messages
function secureMessage(message, messageSecret = MESSAGE_SECRET) {
  // Generate a random IV for each message
  const iv = randomBytes(16);

  // Encrypt the message
  const cipher = createCipheriv('aes-256-gcm', Buffer.from(messageSecret, 'hex'), iv);
  let encrypted = cipher.update(JSON.stringify(message), 'utf8', 'hex');
  encrypted += cipher.final('hex');
  const authTag = cipher.getAuthTag().toString('hex');

  // Create a timestamp to prevent replay attacks
  const timestamp = Date.now();

  // Calculate HMAC for message integrity
  const hmac = createHmac('sha256', messageSecret)
    .update(`${encrypted}.${iv.toString('hex')}.${authTag}.${timestamp}`)
    .digest('hex');

  return {
    payload: encrypted,
    iv: iv.toString('hex'),
    authTag,
    timestamp,
    hmac
  };
}

// Function to verify and decrypt messages
function verifyAndDecrypt(securedMessage, messageSecret = MESSAGE_SECRET) {
  const { payload, iv, authTag, timestamp, hmac } = securedMessage;

  // Verify the message hasn't expired (5 minute window)
  const now = Date.now();
  if (now - timestamp > 5 * 60 * 1000) {
    throw new Error('Message expired (potential replay attack)');
  }

  // Verify message integrity
  const expectedHmac = createHmac('sha256', messageSecret)
    .update(`${payload}.${iv}.${authTag}.${timestamp}`)
    .digest('hex');

  if (hmac !== expectedHmac) {
    throw new Error('Message integrity check failed (potential MITM attack)');
  }

  // Decrypt the message
  const decipher = createDecipheriv(
    'aes-256-gcm',
    Buffer.from(messageSecret, 'hex'),
    Buffer.from(iv, 'hex')
  );

  decipher.setAuthTag(Buffer.from(authTag, 'hex'));

  let decrypted = decipher.update(payload, 'hex', 'utf8');
  decrypted += decipher.final('utf8');

  return JSON.parse(decrypted);
}

// Example usage in an MCP tool
const secureDataTool = createTool({
  name: "secure_data_operation",
  description: "Perform operation with enhanced security",
  inputSchema: {
    type: "object",
    properties: {
      securedData: { type: "object" }
    },
    required: ["securedData"]
  },
  handler: async ({ securedData }) => {
    try {
      // Verify and decrypt the secured data
      const actualData = verifyAndDecrypt(securedData);

      // Process the data
      const result = performOperation(actualData);

      // Return secured response
      return {
        securedResponse: secureMessage(result)
      };
    } catch (error) {
      // Log potential security incidents
      console.error('Security verification failed:', error.message);
      throw new Error('Security verification failed');
    }
  }
});

function performOperation(data) {
  // Actual operation logic
  return { success: true, processedData: data };
}

4. Certificate Pinning

Implement certificate pinning to prevent certificate-based MITM attacks:

// Certificate pinning example (client-side)
import axios from 'axios';
import * as crypto from 'crypto';
import * as https from 'https';

// Known good certificate fingerprints
const TRUSTED_FINGERPRINTS = [
  'sha256//ZEr1mT1pWHGhQIrA8MXfk6YN+UhUg9maWn4Jq1aXEk4=',
  'sha256//YtWRg8HoRQj9ePKKVCGKb5lyoMEF7EANHG3UjpTmTgU='
];

function verifyPinnedCertificate(cert) {
  const fingerprint = 'sha256//' + crypto
    .createHash('sha256')
    .update(cert)
    .digest('base64');

  return TRUSTED_FINGERPRINTS.includes(fingerprint);
}

const httpsAgent = new https.Agent({
  rejectUnauthorized: true,
  checkServerIdentity: (host, cert) => {
    // Standard certificate validation
    const error = https.checkServerIdentity(host, cert);
    if (error) {
      return error;
    }

    // Additional pinning validation
    if (!verifyPinnedCertificate(cert.raw)) {
      return new Error('Certificate pinning validation failed');
    }

    return undefined; // Validation successful
  }
});

async function secureInvoke(url, data) {
  try {
    return await axios.post(url, data, { httpsAgent });
  } catch (error) {
    if (error.message.includes('pinning validation failed')) {
      // Special handling for potential MITM attacks
      console.error('POTENTIAL SECURITY BREACH: Certificate pinning failure');
      // Additional alerting or incident response
    }
    throw error;
  }
}

5. Use Local STDIO with Verification

For highest security, prefer local STDIO with additional verification:

// Enhanced security for local STDIO-based MCP servers
import { spawn } from 'child_process';
import { createHash } from 'crypto';
import * as fs from 'fs';

function verifyExecutableIntegrity(executablePath, expectedHash) {
  const fileContents = fs.readFileSync(executablePath);
  const actualHash = createHash('sha256').update(fileContents).digest('hex');
  return actualHash === expectedHash;
}

function launchSecureMcpServer(config) {
  // Verify executable integrity before launching
  const expectedHash = 'e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855'; // Example hash

  if (!verifyExecutableIntegrity('./mcp-server', expectedHash)) {
    throw new Error('MCP server executable may have been tampered with');
  }

  // Use absolute path to prevent PATH manipulation attacks
  const mcpProcess = spawn('/usr/local/bin/mcp-server', ['--config', config], {
    stdio: ['pipe', 'pipe', 'pipe'],
    env: { ...process.env, MCP_SECURITY_LEVEL: 'high' }
  });

  // Implement additional verification of responses
  // ...

  return mcpProcess;
}

Secure MCP Communications Architecture

When designing MCP systems to prevent MITM attacks, consider these architectural patterns:

1. Defense in Depth: Implement multiple security layers (TLS, message encryption, integrity checks)
2. Zero Trust Networking: Verify all communications regardless of source
3. Secure by Default: Use the most secure transport options by default
4. Mutual Authentication: Both client and server authenticate each other
5. Fail Closed: Any security verification failure should block communication entirely

Conclusion

Man-in-the-middle attacks represent a significant threat to MCP implementations, especially when using network-based transports like HTTP+SSE. By implementing strong transport security, mutual authentication, message-level security, certificate pinning, and proper verification for local communications, you can significantly reduce the risk of MITM attacks.

Remember that security is a continuous process. Regularly audit your MCP implementations, update cryptographic libraries and protocols, and stay informed about emerging MITM attack techniques and defenses.

In the next article in this series, we'll explore the risks of social engineering attacks in MCP contexts and strategies for protecting AI systems and their human operators from manipulation.