#PacketHunters – MITM isn’t a network problem, it’s a code hygiene problem (face it!)

There’s a comforting lie we keep telling ourselves in cybersecurity: that Man-in-the-Middle attacks are mostly a thing of the past, solved by TLS everywhere, modern browsers, and encrypted protocols. That lie survives because it’s convenient. It allows us to treat MITM as a network problem, something to be solved by infrastructure, certificates, or perimeter controls.
In reality, MITM keeps working because of code, not cables.

I’ve seen MITM attacks succeed in environments with “perfect” network security, simply because the application layer trusted things it never bothered to verify. Recovery Month is the right moment to say this clearly: if your systems aren’t carefully curated at the code level, recovery becomes guesswork the moment trust is broken.

Where MITM actually lives today (not a question, tho)

MITM rarely looks like someone sitting between you and the internet with a rogue access point: more often, it lives quietly inside application logic, SDKs, libraries, and configuration defaults that nobody revisited after the first release.

The attack surface is boring and familiar: certificate validation shortcuts, disabled hostname checks, custom trust stores, hardcoded secrets, “temporary” debug flags, legacy crypto code kept alive for compatibility.
MITM thrives wherever code assumes that trust is static.

The most common MITM bug I still see

Let’s start with the classic one, because it refuses to die.

import ssl
import urllib.request

context = ssl.create_default_context()
context.check_hostname = False
context.verify_mode = ssl.CERT_NONE

response = urllib.request.urlopen("https://api.internal.example", context=context)

This code still ships, sometimes in production.
Often “temporarily”, better: always forgotten.

At this point, encryption is cosmetic, any attacker who can position themselves on the path (proxy, compromised Wi-Fi, malicious gateway, poisoned DNS, ..) owns the session.
TLS is present.
Trust is not – read it once again: TRUST. IS. NOT.

MITM in mobile apps: the evergreeeeeeeeen gift

Mobile apps are especially generous to attackers.

TrustManager[] trustAllCerts = new TrustManager[]{
  new X509TrustManager() {
    public void checkClientTrusted(X509Certificate[] chain, String authType) {}
    public void checkServerTrusted(X509Certificate[] chain, String authType) {}
    public X509Certificate[] getAcceptedIssuers() { return new X509Certificate[]{}; }
  }
};

This pattern exists because developers needed to “just test something”, it stays because nobody audits networking code once the app works.

From an attacker’s perspective, this is not a vulnerability: it’s an invitation!
Any MITM proxy can decrypt, modify, replay, and inject traffic. Tokens, credentials, session cookies, API keys – everything flows in the clear after decryption.
It happened 3/4 years ago now, company was pretty sure about security: one CLI to rule them all. Except the system: not patched – aka vulnerable.

Recovery from this kind of compromise is painful because you don’t know what was observed, modified, or replayed.

MITM is an identity problem in disguise

Here’s the part that usually gets missed: MITM isn’t just about data interception, it’s about identity confusion.
So, once the traffic can be intercepted or altered, authentication flows become malleable, tokens can be swapped, redirects can be rewritten and session fixation becomes trivial.

I’ve watched OAuth flows quietly altered mid-flight because code trusted redirects without validating origins.
Oh, and I’ve seen JWTs replayed because transport security was assumed, not enforced. Once MITM exists, identity stops being a guarantee and becomes a suggestion.

Recovery collapses when trust was implicit

The real damage of MITM shows up after detection.

When systems were designed assuming transport trust, recovery teams can’t answer basic questions:

• which sessions were intercepted?
• which credentials were replayed?
• which responses were modified?
• which decisions were influenced silently?

Logs won’t help, but encryption was “enabled” and, from the system’s point of view, everything looked le-gi-ti-ma-te.
This is why MITM is devastating in recovery scenarios: it erases confidence in historical truth.

Why this keeps happening more and more and more

..because code is rarely curated once it works.

Dependencies are updated, but assumptions are not (change my mind).
Certificates are renewed, but validation logic is untouched (change my mind).
Security reviews focus on new features, not old trust paths (change my mind).

Organizations underestimate how long trust decisions live inside code.

Here’s a quick recovery-aware engineering MITM look-a-like:

• strict certificate and hostname validation, no exceptions
• certificate pinning where feasible, with rotation strategies
• explicit trust boundaries documented in code
• killing “temporary” debug paths before release
• auditing SDKs and third-party clients, not just your own code
• treating transport failures as security incidents, not errors

Paranoia?
Well, more about curating trust instead of inheriting it blindly.

If your system’s security depends on “nobody being in the middle”, your recovery plan is already compromised. Trust must be verified explicitly, continuously, and defensively, or it will be borrowed by someone else.

A friend of mine once said: “MITM iz nat a nezwork felure. Iz a sofzware guvernance felure.“

And recovery starts by admitting that.
Prove me wrong.