Allt om MITM-attacker (Man-in-the-Middle)

En Man-in-the-Middle-attack (MITM) inträffar när en angripare i hemlighet positionerar sig mellan två kommunicerande parter och läser eller ändrar meddelanden som varje part tror skickas och tas emot privat. MITM-attacker kan påverka alla protokoll eller portar på interna eller externa nätverk. De är farliga eftersom kommunikationen verkar normal för båda parter under hela attacken. Rekommenderade åtgärder: tillämpa TLS 1.3 med ömsesidig autentisering för alla känsliga anslutningar, distribuera HSTS med förladdning för att förhindra SSL-stripping, övervaka certifikattransparensloggar för obehöriga certifikatutfärdanden och använd certifikatfästing för högsäkerhetsapplikationer.

Snabbt svar: Vad är en man-in-the-middle (MITM)-attack?

En MITM-attack är en cyberattack där en angripare i hemlighet avlyssnar kommunikationen mellan två parter, A och B, som båda tror att de kommunicerar direkt med den andra. Angriparen kan läsa alla meddelanden, ändra dem innan de vidarebefordras, injicera nya meddelanden eller utge sig för att vara en eller båda parter. Attacken är särskilt effektiv eftersom den är osynlig: om inte de kommunicerande parterna har kryptografiska mekanismer för att verifiera varandras identitet och meddelandenas integritet, kan de inte upptäcka avlyssningen. Kryptering ensamt är inte tillräckligt om angriparen kan avlyssna själva nyckelutbytet, vilket är anledningen till att autentiserade nyckelutbytesprotokoll och certifikatvalidering är de viktigaste försvaren.

Hur MITM-attacker fungerar: Mekanismen

En MITM-attack sker i två faser: avlyssning (att erövra en position mellan de två parterna) och exekvering (att utnyttja den positionen för att läsa, modifiera eller injicera data).

Tänk dig ett konkret scenario: användare A vill skicka ett känsligt meddelande till användare B. Angripare Z har positionerat sig på nätverksvägen mellan A och B.

1. A initierar kommunikation och tror att de är anslutna till B. Z har avlyssnat anslutningen och vidarebefordrar A:s trafik till B samtidigt som han framstår som B till A och som A till B.
2. A skickar ett meddelande avsett för B. Z tar emot det först, läser innehållet i klartext och ändrar det eventuellt innan det vidarebefordras till B.
3. B tar emot meddelandet (som eventuellt är modifierat) i tron ​​att det kommer direkt från A. B skickar ett svar till A. Z fångar upp svaret, läser det och modifierar det eventuellt innan det vidarebefordras till A.
4. Under hela utbytet är varken A eller B medvetna om att Z är i mitten. Om kommunikationen är okrypterad har Z fullständig åtkomst till all data. Om den är krypterad men Z har komprometterat nyckelutbytet kan Z fortfarande läsa och modifiera all trafik.

MITM-attacker är svåra att upptäcka eftersom de inte stör kommunikationsflödet. Ur A och B:s perspektiv fortskrider konversationen normalt. Det enda sättet att tillförlitligt upptäcka eller förhindra en MITM-attack är genom kryptografisk autentisering: att verifiera att den enhet du kommunicerar med är den de utger sig för att vara, med hjälp av en mekanism som en angripare inte kan förfalska.

Typer av MITM-attacker

Attack typ	Hur det fungerar	Primärt mål	Viktigt försvar
ARP-förfalskning (ARP-förgiftning)	Angriparen sänder ut förfalskade ARP-meddelanden som kopplar deras MAC-adress till en legitim IP-adress (som standardgatewayen), vilket gör att offrets maskiner skickar trafik till angriparen istället.	Lokala nätverk; delade nätverkssegment	Dynamisk ARP-inspektion (DAI) på hanterade switchar; nätverkssegmentering
DNS-förfalskning (DNS-cacheförgiftning)	Angripare korrumperar en DNS-resolvers cache med bedrägliga poster, vilket gör att offer som frågar resolvern får angriparkontrollerade IP-adresser för legitima domännamn.	DNS-infrastruktur; alla system som använder den förgiftade resolvern	DNSSEC; krypterad DNS (DoH/DoT); validerad resolverkonfiguration
SSL strippning	Angriparen avlyssnar en HTTP-till-HTTPS-omdirigering och upprätthåller en HTTP-anslutning till offret samtidigt som HTTPS till servern bibehålls, vilket möjliggör avlyssning av klartext	Webbsessioner där användare skriver URL:er utan HTTPS	HSTS med förladdning; omdirigerar all HTTP-trafik till HTTPS på servern
Wi-Fi-avlyssning / obehörig AP	Angriparen skapar en skadlig åtkomstpunkt med ett namn som liknar ett legitimt offentligt nätverk; enheter som ansluter automatiskt skickar all trafik via angriparens åtkomstpunkt.	Användare på offentliga Wi-Fi-nätverk	Undvik automatisk anslutning på otillförlitliga nätverk; använd VPN på alla offentliga Wi-Fi; 802.1X-autentisering för företags-Wi-Fi
Session kapning	Angriparen stjäl eller förutspår en giltig sessionstoken (cookie) och använder den för att utge sig för offret för servern, utan att behöva offrets inloggningsuppgifter.	Webbapplikationssessioner; webbläsarbaserade applikationer	Säkra och HttpOnly-cookieflaggor; korta livslängder för sessionstoken; tokenbindning; MFA för omautentisering vid känsliga åtgärder
HTTPS-förfalskning (homografattack)	Angriparen registrerar en domän med internationaliserade tecken som ser identiska ut med en legitim domän (t.ex. genom att använda kyrilliska tecken som visuellt ser identiska ut med latinska tecken); HTTPS-hänglåset verkar giltigt för angriparens domän.	Användare som verifierar HTTPS men inte inspekterar hela certifikatet	Övervakning av certifikattransparens; användarmedvetenhet; hantering av internationaliserade domännamn i webbläsare
BGP-kapning	Angripare meddelar mer specifika eller falska BGP-rutter, vilket får internetroutrar att omdirigera trafik som är avsedd för ett legitimt nätverk genom angriparkontrollerad infrastruktur.	Internettrafik; attacker på internetleverantörsnivå	BGP-ruttvalidering (RPKI); övervakning av oväntade ändringar i ruttens ursprung

Varningstecken på att du kan vara ett MITM-offer

• Oväntade certifikatvarningar: Din webbläsare visar ett certifikatfel, en varning om otillförlitlig certifikatutfärdare eller så har certifikatet för en bekant webbplats ändrats oväntat. Detta kan tyda på att en angripare presenterar sitt eget certifikat för anslutningen.
• URL-avvikelser: Domänen i adressfältet har subtila skillnader från den förväntade domänen, såsom teckenersättningar (https://spooFing.com istället för https://spoofing.com), ytterligare underdomäner eller internationaliserade tecken som liknar latinska bokstäver.
• Oväntade HTTP-anslutningar: Din webbläsare eller ditt program ansluter via HTTP där du förväntade dig HTTPS, vilket kan tyda på en SSL-stripping-attack.
• Upprepade frånkopplingar: du blir frånkopplad och ombedd att autentisera dig igen upprepade gånger, vilket kan vara ett tecken på att en angripare samlar in inloggningsuppgifter under ominloggning.
• Oväntad latens: Nätverkslatensen är betydligt högre än normalt för anslutningar till välbekanta tjänster, vilket kan indikera att trafik dirigeras genom ett ytterligare hopp.
• ARP-tabellavvikelser: I ett hanterat nätverk visar ARP-tabellen en enda MAC-adress som är associerad med flera IP-adresser, eller så har MAC-adressen för standardgatewayen ändrats, vilket indikerar möjlig ARP-förfalskning.

Hur TLS och kryptering förhindrar MITM-attacker

Det mest effektiva tekniska försvaret mot MITM-attacker är autentiserad kryptering, som kombinerar konfidentialitet (en angripare kan inte läsa informationen) med autentisering (båda parter kan verifiera identiteten på den enhet de kommunicerar med). TLS (Transport Layer Security) tillhandahåller båda egenskaperna för nätverkskommunikation.

TLS-handskakningen fungerar så här: servern presenterar ett digitalt certifikat som utfärdats och signerats av en betrodd certifikatutfärdare (CA). Klienten (webbläsare eller applikation) verifierar certifikatkedjan: certifikatet måste vara kedjat till en rot-CA i klientens betrodda arkiv, certifikatet måste vara giltigt för den domän som används och certifikatet får inte ha återkallats. Om valideringen godkänns är klienten kryptografiskt säker på att den kommunicerar med den enhet som innehar den privata nyckel som motsvarar certifikatet. En angripare som avlyssnar anslutningen kan inte presentera ett giltigt certifikat för den legitima domänen utan att ha komprometterat den privata nyckeln eller en betrodd certifikatutfärdare.

Efter autentisering använder TLS ett kortlivat nyckelutbyte (ECDHE i TLS 1.3; ECDHE eller DHE i TLS 1.2) för att etablera sessionsnycklar som inte har passerat nätverket, vilket ger framåtriktad sekretess. Även om en angripare registrerar krypterad trafik och senare komprometterar en långsiktig privat nyckel, kan de inte dekryptera tidigare sessioner eftersom sessionsnycklarna var kortlivade och aldrig lagrades.

Protokoll- och algoritmval för MITM-prevention

kontroll	Rekommenderad konfiguration	Vad som ska undvikas	Varför det är viktigt för MITM
TLS-version	TLS 1.3 (föredraget); TLS 1.2 minimum	TLS 1.0, TLS 1.1, SSL 3.0, SSL 2.0	Äldre versioner har kända svagheter som angripare utnyttjar för att nedgradera anslutningar eller dekryptera trafik
Nyckelutbyte	ECDHE (TLS 1.3 obligatoriskt); DHE med 2048+ bitgrupper för TLS 1.2	RSA-nyckelutbyte (ingen framåtriktad sekretess); statisk DH	Kortlivat nyckelutbyte ger framåtriktad sekretess; RSA-nyckelutbyte innebär att en privat nyckelkompromiss dekrypterar alla inspelade tidigare sessioner
Certifikatnyckeltyp	ECDSA P-256 eller RSA-3072+	RSA-1024-, DSA- och MD5-signerade certifikat	Svaga certifikatnycklar kan förfalskas, vilket gör det möjligt för en angripare att presentera ett giltigt certifikat för en MITM-position.
HTTP-säkerhetsrubriker	HSTS med maxålder 31536000 och inkluderar underdomäner; HSTS-förladdningslista för publika domäner	Ingen HSTS; kort HSTS-maxålder; ingen förspänning	Utan HSTS kan SSL-strippingattacker nedgradera HTTPS-anslutningar till HTTP
Certifikatvalidering	Fullständig kedjevalidering + OCSP-häftning + övervakning av certifikattransparens	Självsignerade certifikat utan att fästa; certifikatvalidering inaktiverad i appar	Inaktiverad eller svag validering är den främsta anledningen till att MITM-attacker lyckas mot krypterade anslutningar
DNS-säkerhet	DNSSEC för auktoritativa zoner; DNS-över-HTTPS (DoH) eller DNS-över-TLS (DoT) för resolvrar	Ogiltig DNS endast över UDP/53	DNS-förfalskning är en vanlig MITM-ingångspunkt; DNSSEC tillhandahåller integritetsvalidering av DNS-svar
Ömsesidig TLS (mTLS)	mTLS för tjänst-till-tjänst API-kommunikation och nollförtroendearkitekturer	Server-endast TLS för känsliga interna API:er	mTLS kräver att båda sidor presenterar och validerar certifikat, vilket gör det betydligt svårare för en angripare att ansluta sig till en anslutning.

SSL-stripping: En specifik MITM-teknik

SSL-stripping är en av de mest effektiva MITM-teknikerna mot webbanvändare eftersom den utnyttjar övergången mellan HTTP och HTTPS. När en användare skriver en URL utan att ange HTTPS (till exempel genom att skriva ett domännamn direkt i adressfältet) skapar webbläsaren vanligtvis en initial HTTP-anslutning som omdirigerar till HTTPS. En angripare som avlyssnar denna initiala HTTP-anslutning kan:

1. Avlyssna offrets initiala HTTP-begäran före HTTPS-omdirigeringen.
2. Vidarebefordra begäran till den legitima servern via HTTPS (vilket upprättar en giltig krypterad session med servern).
3. Ta emot serverns HTTPS-svar och radera HTTPS-omdirigeringen, så att innehållet levereras till offret via HTTP.
4. Offrets webbläsare visar HTTP (inget hänglås), och all data som offret skickar, inklusive inloggningsuppgifter och sessionstokens, är synlig i klartext för angriparen.

Försvaret är HTTP Strict Transport Security (HSTS) . HSTS instruerar webbläsare som tidigare har besökt en webbplats att endast ansluta via HTTPS under maxgränsperioden, även om användaren skriver in URL:en utan HTTPS. HSTS-förladdning går längre: domänen inkluderas i en lista som sammanställs i webbläsarversioner, så även förstagångsbesökare ansluter via HTTPS utan att behöva ett tidigare besök för att ta emot HSTS-headern.

Viktiga hanteringsberoenden för MITM-förebyggande

Effektiviteten av TLS-baserat MITM-skydd beror helt på integriteten hos certifikatet och den privata nyckelinfrastrukturen. Om en angripare kan få tag på eller förfalska ett giltigt certifikat för en måldomän kan de presentera det under en MITM-attack och klara standardcertifikatvalidering.

• Skydd av privat nyckel: Om en servers privata TLS-nyckel komprometteras kan en angripare utge sig för att vara servern för vilken klient som helst och därmed helt kringgå TLS-autentiseringen. Privata nycklar för TLS-certifikat måste lagras med samma noggrannhet som alla andra känsliga kryptografiska nycklar, inklusive att begränsa åtkomst till endast auktoriserade processer, med hjälp av HSM-lagring för certifikat av högt värde och roterande certifikat enligt ett definierat schema.
• Hantering av certifikatlivscykel: Utgångna, återkallade eller felkonfigurerade certifikat skapar varningstillstånd som användare kan stänga eller som program kan kringgå genom inaktiverad certifikatvalidering. CertSecure-hanterare automatiserar hanteringen av certifikatlivscykeln, vilket säkerställer att certifikat förnyas innan de löper ut och att återkallelse hanteras snabbt när en nyckel misstänks ha komprometterats.
• Certifikatutfärdarens förtroende: Säkerheten för TLS-autentisering beror på tillförlitligheten hos certifikatutfärdarna i klientens rotarkiv. Certifikattransparensloggar (CT) tillhandahåller en offentlig, endast tilläggsbaserad registrering av alla certifikat som utfärdats av certifikatutfärdare, vilket gör det möjligt för domänägare att övervaka obehöriga certifikatutfärdanden för sina domäner.

Organisatoriska kontroller för MITM-förebyggande

1. Tillämpa TLS överallt: Alla webbegenskaper, API:er och interna tjänster bör kommunicera över minst TLS 1.2, TLS 1.3 föredras. Intern kommunikation mellan tjänster lämnas särskilt ofta okrypterad, vilket gör den sårbar för laterala förflyttningsattacker som använder MITM-tekniker.
2. Distribuera HSTS med förladdning: Skicka in alla publika domäner till HSTS förladdningslista. Konfigurera maxåldern till minst ett år och inkludera alla underdomäner.
3. Använd ömsesidig TLS (mTLS) för API:er: Interna API:er och mikrotjänstkommunikation bör kräva att både klient och server presenterar giltiga certifikat, vilket eliminerar möjligheten för en angripare att infoga en obehörig tjänst i en kommunikationsväg.
4. Övervaka certifikattransparens: Prenumerera på CT-loggövervakningstjänster som varnar när nya certifikat utfärdas för dina domäner, vilket möjliggör snabb upptäckt av obehörig certifikatutfärdande som kan möjliggöra en MITM-attack.
5. Skydda nätverkslagret: Implementera dynamisk ARP-inspektion (DAI) på hanterade switchar för att förhindra ARP-förfalskning i lokala nätverk. Använd 802.1X-autentisering för företags-Wi-Fi för att förhindra attacker från oseriösa åtkomstpunkter. Segmentera nätverk för att begränsa sändningsdomänen där ARP-attacker kan operera.
6. Utbilda användarna om varningssignaler: Användare som känner igen certifikatfel, HTTP-anslutningar där HTTPS förväntas och misstänkta URL-avvikelser kan förhindra social engineering-komponenter i MITM-attacker som är beroende av användaracceptans av säkerhetsvarningar.

Begränsningar av tekniska MITM-försvar

• Företags-TLS-inspektion skapar en sanktionerad MITM: Många organisationer använder TLS-inspektionsproxyer som avslutar och omkrypterar TLS-anslutningar för att inspektera trafik för skadlig kod och dataförlust. Ur slutpunktens perspektiv utför proxyn en MITM-attack. Detta skapar en spänning mellan säkerhetsövervakning och end-to-end-kryptering och kräver att användare litar på organisationens proxycertifikat, vilket vanligtvis distribueras via grupprincip.
• Certifikatfästning skapar operativ sårbarhet: Certifikatfästning förhindrar MITM-attacker med bedrägligt utfärdade certifikat, men det bryter också mot legitim certifikatrotation om inte applikationen uppdateras för att inkludera det nya fästa värdet innan det gamla certifikatet löper ut. Dålig hantering av PIN-rotation har orsakat stora programavbrott.
• HSTS ger inget skydd vid första anslutningen utan förladdning: Utan förinläsning aktiveras HSTS endast efter att en användare tidigare har besökt en webbplats via HTTPS och mottagit HSTS-headern. Förstagångsbesökare är fortfarande sårbara för SSL-stripping.
• Krypterade kanaler skyddar transit men inte slutpunkter: TLS skyddar data som överförs mellan klient och server. Om antingen klient- eller serverslutpunkten komprometteras kan en angripare på den slutpunkten läsa klartextdata oavsett vilken kryptering som skyddar nätverksvägen mellan dem.

Hur krypteringskonsulting kan hjälpa

• CertSecure-chef: CertSecure-hanterare hanterar livscykeln för TLS-certifikat i din miljö, inklusive automatisk förnyelse för att förhindra utgång, hantering av återkallelser och insyn i alla certifikat som skyddar dina anslutningar. Utgångna eller felkonfigurerade certifikat är en primär möjliggörare för MITM-attacker.
• HSM som en tjänst: HSM som en tjänst skyddar de privata nycklarna bakom dina TLS-certifikat i FIPS 140-3-validerad hårdvara, vilket förhindrar nyckelutvinning även vid en serverkompromiss.
• Krypteringsrådgivningstjänster: vår Krypteringsrådgivningstjänster utvärdera TLS-konfigurationen över dina webbegenskaper och API:er, identifiera svaga krypteringssviter, saknade HSTS-rubriker, felaktiga certifikatkonfigurationer och okrypterad intern tjänstkommunikation som skapar MITM-exponering.
• PKI som en tjänst: vår PKI som en tjänst tillhandahåller infrastrukturen för att utfärda och hantera certifikat för interna mTLS-distributioner, vilket möjliggör nätverksarkitekturer med noll förtroende där varje tjänstanslutning autentiseras ömsesidigt.

Slutsats

MITM-attacker är fortfarande en av de farligaste attackkategorierna eftersom de fungerar osynligt: ​​båda parter tror att deras kommunikation är privat när den inte är det. De tekniska försvaren är väl etablerade och effektiva när de distribueras korrekt: TLS 1.3 med autentiserat nyckelutbyte, HSTS med förladdning, mTLS för tjänst-till-tjänst-kommunikation, dynamisk ARP-inspektion för lokala nätverk och övervakning av certifikattransparens. Det vanligaste felläget är inte att kontrollerna inte finns utan att de är felkonfigurerade, ofullständiga eller saknas i delar av nätverket eller applikationsstacken som antas vara säkra. En omfattande bedömning av din TLS-konfiguration, certifikathantering och interna nätverkskontroller ger den insyn som behövs för att täppa till dessa luckor.

Vanliga frågor om partihandel med mat och dryck

Vad är en Man-in-the-Middle (MITM)-attack?

En MITM-attack är en cyberattack där en angripare i hemlighet avlyssnar kommunikation mellan två parter, och läser eller modifierar meddelanden som varje part tror går direkt till den andra. Attacken är osynlig för båda parter om inte kryptografiska autentiseringsmekanismer finns på plats för att upptäcka eller förhindra avlyssningen.

Hur förhindrar TLS MITM-attacker?

TLS förhindrar MITM-attacker genom servercertifikatautentisering (servern måste bevisa att den innehar den privata nyckeln för ett certifikat utfärdat av en betrodd CA för rätt domän) och krypterat nyckelutbyte (sessionsnycklar upprättas via ECDHE, så en avlyssnare kan inte härleda sessionsnycklarna även om de fångar handskakningen). TLS 1.3 gör forward secretty obligatorisk för alla anslutningar.

Vad är SSL-stripping och hur fungerar det?

SSL-stripping avlyssnar ett offers initiala HTTP-anslutning innan den kan omdirigera till HTTPS, vilket upprätthåller en HTTP-anslutning till offret medan det ansluter till servern via HTTPS. Offret skickar klartextdata till angriparen utan att veta om det. HSTS med förladdning förhindrar detta genom att tvinga HTTPS redan före den första anslutningen.

Vad är ARP-spoofing och varför är det farligt?

ARP-förfalskning skickar förfalskade ARP-meddelanden som kopplar angriparens MAC-adress till en legitim IP-adress på det lokala nätverket och omdirigerar trafik genom angriparen. Det möjliggör MITM-attacker på nätverkslagret innan någon kryptering på applikationslagret är på plats. Dynamisk ARP-inspektion på hanterade switchar är det primära tekniska försvaret.

Vad är certifikatfästning och när bör organisationer använda det?

Certifikatfästing konfigurerar en applikation att endast acceptera specifika certifikat eller publika nycklar för en given server, och avvisar även legitimt utfärdade certifikat som inte matchar. Det är lämpligt för mobilapplikationer med hög säkerhet och företags-API:er där båda slutpunkterna är under organisatorisk kontroll. Det skapar driftskomplexitet kring certifikatrotation och rekommenderas inte för vanliga webbapplikationer.

Hur kan en organisation upptäcka en pågående MITM-attack?

Signalerna inkluderar oväntade certifikatändringar eller fel, ARP-tabellavvikelser (en MAC-adress för flera IP-adresser), oväntade HTTP-anslutningar där HTTPS förväntas, upprepade frånkopplingar som leder till omautentisering, ovanlig latens och DNS-upplösningsresultat som skiljer sig från förväntade värden. Övervakning av certifikattransparensloggen aviserar om obehöriga certifikatutfärdanden för dina domäner.