TLS decrypten een eitje

[GarBaGe]

Vandaag woonde ik een Cybersecurity sessie bij van mijn werk.
Die lieten in een live demo zien hoe je makkelijk en snel een TLSv1.3 verbinding kan decrypten.
Je zet immers een user environment variabele (op Mac, Windows of Linux) met de naam "sslkeylogfile" en de locatie waar je graag je onbeschermde prive sessie sleutels van je TLS verbinding wilt hebben.
Klaar.
Vrijwel alle browsers supporten dit standaard out-of-the-box.
Al jaren lang.
Handig voor debuggen, maar toch niet als standaard setting voor praktisch alle normale gebruikers?
Dit heeft maar heel weinig om makkelijk en snel misbruikt te kunnen worden en het gehele nut van TLS uit het raam te gooien.
Wat vinden jullie?

[Umbrah]

Klopt, en met een lokaal geïnstalleerde proxy (á la fiddler) is het ook erg eenvoudig, en zelfs op layer 4 niveau met zaken als wireshark valt een hoop te vinden.

Je moet echter toegang hebben tot de machine, wat al vaak een hindernis is, en zeker publieke certificaten zijn nogal... publiek. Op het moment dat je op een publiek wifi zit (geen WPA3 encryptie), en HTTPS websites bezoekt ben je over het algemeen inderdaad niet veilig: zeker omdat domeinnamen sowieso niet encrypted zijn, TLS is immers tussen TCP en HTTP. Wil je de rest kunnen decrypten zul je inderdaad op een user machine logs moeten onderscheppen. Iets wat niet alleen toegang tot de machine nodig heeft, maar (tenminste op Windows) zelfs elevation, én daarna ook toegang tot die log files. Veel on-machine stappen dus, waardoor je met een ander soort rootkit eigenlijk als kwaadwillende beter uit bent.


Ik vindt het dus niet zo'n groot probleem, zeker omdat het daarnaast óók het andere effect (iets waar een fiddler bijvoorbeeld wel last van heeft), namelijk het 'herkennende' van TLS/SSL, niet ongedaan maakt.

Bovendien zijn keys maar kort geldig, wat je in de ssllog uiteraard terug ziet. Sluit je een sessie (denk wederom aan layer4), zal de handshake opnieuw plaatsvinden, en heb je een nieuwe regel in sslkey.log.

Voor info over de sessies:

netstat -an | findstr :443

Vandaar dat je ook moet verwijzen naar een "levende" sslkey.log in wireshark.

Geloof me -- dit is, als je weet hoe de handshake werkt (https://commandlinefanati...rticle.cgi?article=art080) niet zo'n groot risico

[kodak]

Een variable instellen is niet het enige wat nodig is. Om dat te kunnen doen moet de crimineel eerst toegang krijgen tot de nodige rechten. Bijvoorbeeld door directe toegang tot het account of via een ernstige exploit. En de crimineel heeft ook nog toegang nodig tijdens of nadat de gebruiker iets belangrijks verwerkt. Maar als een crimineel dat kan dan is er meestal veel meer mogelijk om je zorgen over te maken.

Natuurlijk kun je dan alsnog stellen dat dit misbruik beter voorkomen kan worden door die functionaliteit niet standaard beschikbaar te hebben. Maar dat voorkomt niet dat een crimineel met zoveel rechten alsnog toegang kan krijgen. Omdat er nog veel andere manieren zijn.

Als een crimineel dit kan misbruiken dan heb je te weinig controle over het account, de software, de gegevens, de (ver)werking enz. Dan kun je nmm beter moeite doen om daar in het algemeen controle over te krijgen en behouden.

[lordgandalf]

Als een misbruiker toegang heeft tot een account met verhoogde privileges dan is het systeem al aangetast en dat hij dingen mee kan lezen is dan denk ik het minste probleem

[GarBaGe]

lordgandalf schreef op maandag 7 april 2025 @ 13:10:
Als een misbruiker toegang heeft tot een account met verhoogde privileges dan is het systeem al aangetast en dat hij dingen mee kan lezen is dan denk ik het minste probleem

Voor de hack heb je geen verhoogde privileges nodig.
Deze privileges als de gebruiker is al genoeg.
En door een user environment variabele te zetten, heb je toegang over de locatie waar alle TLS sessie sleutels worden bewaard.
Terwijl TLS sessie sleutels niet opgeslagen zouden moeten worden.
Die dingen hoor alleen in het geheugen van de applicatie te staan tijdens de sessie en daarna moeten ze verdwijnen.
Met een beetje social engineering / phising kan je makkelijk een scriptje uitvoeren namens de gebruiker en deze variabele zetten.
Bijvoorbeeld via een link in een email of het bezoek van een website.
Prive sleutels.... daar dien je heel voorzichtig mee om te gaan.
Ik vind dit wel een hele onvoorzichtige manier en vraagt er haast om misbruikt te worden....

[Jazzy]

Het kunnen exporteren van je eigen private keys is geen 'hack' en als je het wel zo wilt noemen dan moet je toch eens uitleggen hoe een derde dit zou kunnen misbruiken.

[BytePhantomX]

@GarBaGe als het zo makkelijk was, waarom hebben we dan niet super veel aanvallen via deze techniek? Als je het zo beschrijft kunnen criminelen super simpel geld verdienen door het verkeer naar banken te hacken en toch gebeurd het niet. Dat zou al een hint moeten zijn dat het risico niet zo groot is als je misschien denkt.

Ten tweede, voor deze 'hack' moet je toegang hebben tot een machine. Als je die toegang toch al hebt, dan hoef je helemaal geen verkeer meer te ontsleutelen, je zit namelijk al aan de ontsleutelde kant op de machine.

Als laatste, dit is hoe (TLS) encryptie werkt. Hoog over zet je eerst met assymetrische encryptie een verbinding op, op basis van de publieke sleutel van de ander en de private sleutel van jezelf, waarna er een symmetrische sleutel wordt opgebouwd en verstuurd over deze versleuteld verbinding om de rest van het verkeer te versleutelen. Aan beide kanten zijn dus de sleutels bekend van de symmetrische encryptie. Linksom of rechtsom moet die op jouw pc worden opgeslagen en kan die dus 'gehackt' worden. En als het bij jou niet kan, dan wel aan de andere kant. TLS is dan ook bedoeld om de vertrouwelijkheid en integriteit te beschermen wanneer data over onveilige verbindingen gaat. Niet om data op een systeem zelf te beschermen.

Het is ook een beetje in dezelfde categorie als je toegang tot een systeem hebt, kun je super simpel een keylogger installeren en heb je toegang tot alle wachtwoorden die iemand gebruikt.

Ik weet niet wie je werk heeft ingehuurd voor deze demo (of dat het eigen collega's waren), maar het verpreiden van FUD (fear, uncertainty and doubt) is heel eenvoudig in cybersecurity. En ik ben bang dat dit hier gebeurd is.

[lordgandalf]

GarBaGe schreef op maandag 7 april 2025 @ 13:20:
[...]

Voor de hack heb je geen verhoogde privileges nodig.
Deze privileges als de gebruiker is al genoeg.
En door een user environment variabele te zetten, heb je toegang over de locatie waar alle TLS sessie sleutels worden bewaard.
Terwijl TLS sessie sleutels niet opgeslagen zouden moeten worden.
Die dingen hoor alleen in het geheugen van de applicatie te staan tijdens de sessie en daarna moeten ze verdwijnen.
Met een beetje social engineering / phising kan je makkelijk een scriptje uitvoeren namens de gebruiker en deze variabele zetten.
Bijvoorbeeld via een link in een email of het bezoek van een website.
Prive sleutels.... daar dien je heel voorzichtig mee om te gaan.
Ik vind dit wel een hele onvoorzichtige manier en vraagt er haast om misbruikt te worden....

Hmmz vraag me af waar dit vandaan komt want de plaats /etc/ssl/certs bijv is altijd al readable maar /etc/ssl/private niet dus vind het knap als je die kan lezen met een env variable.
Is er ook ergens waar we hier over kunnen lezen of is het word of mouth en verders niet bewezen ?

[ Voor 4% gewijzigd door lordgandalf op 07-04-2025 13:48 ]

[GarBaGe]

Jazzy schreef op maandag 7 april 2025 @ 13:35:
Het kunnen exporteren van je eigen private keys is geen 'hack' en als je het wel zo wilt noemen dan moet je toch eens uitleggen hoe een derde dit zou kunnen misbruiken.

Het gaat niet om 1 sleutel die handmatig door de gebruiker eenmalig wordt ge-export.
Het is een globale settings waarmee ALLE browsers ALLE sleutels wegschrijven naar een gemeenschappelijke locatie voor altijd.
En dat terwijl de gebruiker wellicht niet eens weet dat die optie aanstaat.
Het zou veel veiliger zijn, als dit per browser via een "developer"' sectie apart moet worden aangezet en dat dit slechts voor bepaalde tijd werkt.
De functionaliteit staat standaard aan in alle browsers voor alle gebruikers, terwijl >99,999% van de gebruikers deze feature nooit zal gebruiken.
Hiermee is de attack surface wel enorm groot "out-of-the-box" terwijl dit helemaal niet nodig is.

[Jazzy]

Mijn vraag was eigenlijk meer hoe dit dan door een hacker misbruikt kan worden.

[P_de_B]

GarBaGe schreef op maandag 7 april 2025 @ 13:48:
[...]
.
Hiermee is de attack surface wel enorm groot "out-of-the-box"

Als je toegang tot de machine hebt. En dan heb je toch veel grotere problemen?

[Tsurany]

TLS is bedoeld om dataverkeer tussen verschillende systemen te beschermen, die beveiliging is nog steeds intact. Waar jij het over hebt is dat, wanneer iemand toegang heeft tot het systeem van een van de partijen, de encryptiesleutels uit te lezen zijn.
Ik zie dat niet als een issue aangezien de data toch al unencrypted op de lokale systemen terug te vinden is.

[lordgandalf]

Ik vermoed dat het mogelijk dit is of een soort gelijke aanval:

https://my.f5.com/manage/s/article/K50557518

Maar dan nog als gebruiker mag ik zelf al mijn keys exporteren wat wil je er mee bereiken ?
En dit is puur en alleen op de browser dus niet alle ssl keys enz.

[Drardollan]

Dit is echt van het niveau: "als iemand mijn huissleutel afpakt dan kan hij zo mijn huis in".

[GarBaGe]

lordgandalf schreef op maandag 7 april 2025 @ 13:47:
[...]


Hmmz vraag me af waar dit vandaan komt want de plaats /etc/ssl/certs bijv is altijd al readable maar /etc/ssl/private niet dus vind het knap als je die kan lezen met een env variable.
Is er ook ergens waar we hier over kunnen lezen of is het word of mouth en verders niet bewezen ?

Nee, je zet de environment variable SSLKEYLOGFILE
en kan vervolgens alle private keys terug vinden in de locatie van die variabele.
Bijvoorbeeld in /home/user/privatekey

Het staat ook in de documentatie van Wireshark:

The key log file is a text file generated by applications such as Firefox, Chrome and curl when the SSLKEYLOGFILE environment variable is set. To be precise, their underlying library (NSS, OpenSSL or boringssl) writes the required per-session secrets to a file.

https://wiki.wireshark.org/TLS

Je kan bijvoorbeeld die commando gebruiken:

code:

export SSLKEYLOGFILE=$HOME/Desktop/keylogfile.txt
firefox

[lordgandalf]

Dus het is wat ik post dat is een artikel die dat schrijft maar goed je moet wireshark op de machine hebben om uberhaupt dit te kunnen doen en dit is iets wat al sinds 2018 bekend is dus .... En het zijn alleen je public en private keys in je browser dus zeldzaam kun je een private key van de een of andere dienst pakken.

[DataGhost]

Ja, dit blijf je herhalen, maar daarvoor heeft de aanvaller dus eerst toegang nodig tot de machine en op dat moment zijn er duizenden andere manieren om data af te tappen uit alle programma's die onder dezelfde user draaien. Om dan TLS-verkeer te gaan ontsleutelen is echt heel vergezocht. Wat er normaliter gebeurt is dat alle opgeslagen cookies worden doorgestuurd naar de aanvaller waarna deze zelf onbeperkt toegang krijgt tot de accounts/"verbindingen" waar je nu precies bang voor lijkt te zijn, met als bonus dat hij niet hoeft te wachten tot jij er zelf gebruik van maakt, maar gewoon zelf aan de slag kan. Dit gebeurt al, en is ontzettend veel minder omslachtig dan TLS-verkeer decrypten en analyseren.

[ Voor 7% gewijzigd door DataGhost op 07-04-2025 14:00 ]

[laurens0619]

You have been fudded

Een belangrijke stap voor deze "aanval" is toegang tot de machine om variabelen te zetten en data te exporteren.
Als die toegang er al is dan is zeer veel mogelijk voor een aanvaller. Op deze manier de TLS key dumpen kan handig zijn maar er zijn genoeg andere manier om vanuit die toegang data te zien/manipuleren.

[Qwerty-273]

Nog betere hack, als je al toegang hebt tot het systeem met gebruikersrechten, kan je zelf alle data hacken op het systeem zonder dat het verstuurd hoeft te worden over het netwerk. Hoef je zelfs niet meer aan de slag om TLS te decrypten.

Maar met iedereen hier boven, dit is natuurlijk logisch. TLS is voor de bescherming onderweg van punt A naar B, niet voor de bescherming op punt A of op punt B. De processen op punt A en punt B moeten natuurlijk wel toegang hebben tot de sleutels/certificaten om überhaupt die beveiligde verbinding op te kunnen zetten, ook de processen die onder gebruikersrechten draaien.

[GarBaGe]

Storm in een glas water, dus?
Okee.
Ook leuk om eens het andere perspectief te zien.
Bedankt voor jullie reacties

[BytePhantomX]

GarBaGe schreef op maandag 7 april 2025 @ 14:16:
Storm in een glas water, dus?
Okee.
Ook leuk om eens het andere perspectief te zien.
Bedankt voor jullie reacties

Als je nog een keer zo'n demonstratie krijgt, gewoon vragen of ze een voorbeeld hebben wanneer dit in de praktijk misbruikt is. Kun je meteen bepalen of het een relevante 'hack' is of niet.

[Jazzy]

lordgandalf schreef op maandag 7 april 2025 @ 13:52:
Ik vermoed dat het mogelijk dit is of een soort gelijke aanval:

https://my.f5.com/manage/s/article/K50557518

Toch even voor de beeldvorming, dit is dus geen 'aanval'.

[lordgandalf]

Jazzy schreef op maandag 7 april 2025 @ 14:39:
[...]

Toch even voor de beeldvorming, dit is dus geen 'aanval'.

Klopt het is geen aanval maar goed ik noemde het zo even.