Aanval laat kwaadwillenden ondanks https volledige url's inzien

Onderzoekers Itzik Kotler en Amit Klein hebben een aanval ontwikkeld waarmee volledige url's zijn in te zien die door het slachtoffer worden bezocht. Deze aanval kan bijvoorbeeld via een wifi-netwerk uitgevoerd worden en werkt ondanks gebruik van een beveiligde https-verbinding.

Ars Technica heeft een e-mail van de onderzoekers ontvangen waarin zij details over de aanval bekendmaken, voor hun geplande presentatie op de BlackHat-conferentie. Daaruit blijkt dat de basis voor deze methode wordt gevormd door het Web Proxy Autodiscovery-protocol, oftewel wpad. Als deze functie is ingeschakeld, kan een aanvaller via een kwaadaardig dhcp-antwoord, bijvoorbeeld via een wifi-netwerk, ervoor zorgen dat de browser van het slachtoffer een pac-bestand verkrijgt. Dit bestand geeft aan welke url-types van een bepaalde proxy gebruik moeten maken, aldus Ars Technica.

Het verzoek om een bepaalde url te bezoeken wordt eerst verwerkt door deze pac-code, voordat er een beveiligde https-verbinding tot stand kan komen. Daardoor kan de aanvaller de bezochte url van het slachtoffer inzien. Dit is problematisch, omdat veel url's een toegangstoken bevatten, bijvoorbeeld voor het opnieuw instellen van een wachtwoord of voor het verkrijgen van toegang tot een bestand op een server. Een andere manier om deze aanval uit te voeren is door via malware een geïnfecteerd systeem een bepaalde proxy te laten gebruiken.

De aanval met de naam 'Unholy PAC' werkt op vrijwel alle besturingssystemen en browsers, zo stellen de onderzoekers. Een manier om deze tegen te gaan is door het uitschakelen van wpad, al kan dit in sommige gevallen problemen met zich meebrengen. De Microsoft-browsers Edge en IE11 zijn minder kwetsbaar, omdat deze alleen de hostnaam in plaats van volledige url's blootstellen. Naar aanleiding van de BlackHat-presentatie zullen er meer details over de aanval naar buiten komen.

Update, 13:55 Tweaker Kinine heeft een proof-of-concept van een dergelijke aanval op GitHub gepubliceerd, inclusief een videodemonstratie.

Afbeeldingen via Ars Technica

Reacties (106)

[Kinine]

Ik krijg bijna zin overal op te reageren, voor de mensen die willen weten hoe het wel werkt:
hier de Proof-of-concept

[mxcreep]

Ik zie in het artikel dat de Microsoft browsers het beter doen omdat ze alleen de hostnaam blootgeven, de hostnaam is sinds SNI echter altijd al zichtbaar in de headers, die info is plain text nodig om de webserver de juiste virtualhost te laten selecteren om daarna pas het encrypted deel van de data te verwerken. Dus om een hostnaam te verkrijgen is deze hack niet nodig.

Mijn conclusie is dan ook dat de Microsoft browsers met deze hack niet meer informatie prijsgeven dan al beschikbaar was en dat de hack hier dus niet werkt.

[Reactie gewijzigd door mxcreep op 22 juli 2024 20:34]

[Kinine]

Ja en nee. Dit is de behavior in de nieuwere versie's van Internet Explorer en Edge. Het is overigens niet zo dat IE nooit het pad van HTTPS url's stuurt door de FindProxyForURL, maar alleen voor de eerste hit van elk domain. Niet secure by design, maar de security impact is daardoor wel (bijna) nullified.

"Eerste" van die specifieke browser sessie. Dus stel je opent je browser, gaat naar outlook.com en klikt daar op een link in een email die je ook automagish one-time inlogt (wat minder zeldzaam is dan je zou denken), dan kan die sessie alsnog gekaapt worden.

Het probleem is dan ook niet dat je iemands GET parameters kan lezen, die zijn 99% van de tijd niet interessant. Het probleem zit hem in het feit dat een aanvaller de andere 1% je sessie/account kan overnemen en dan kan rondneuzen wat 'ie wil. Of denk aan mobile apps, bijvoorbeeld eavesdrop'n op je WhatsApp messages via GET requests.

[sourcecode]

mag ik vragen als jij zo,n proof of concept kan maken, wat jou jij functie is in het dagelijks leven ?

[Kinine]

Ik werk gedetacheerd bij een nederlandse bank. Overigens heeft mijn werk vrij weinig te maken met het zoeken naar dit soort lekken. Leren dit soort vulnerabilities te vinden is vooral goed te doen in je vrije tijd naast it-security related werk. En zoals SamD mischien al hintte, heb ik hiervoor al een en ander browser lek gevonden.

Overigens heb ik die poc niet 'even' gemaakt vanochtend o.i.d. Ik had dit lek begin mei gerapporteerd.

[Reactie gewijzigd door Kinine op 22 juli 2024 20:34]

[SamD]

Bekijk even zijn YouTube waar zijn echte naam is en vervolgens simpele search op google naar zijn LinkedIn. offtopic: indrukwekkend CV Bas.

[FreezeXJ]

Best triest eigenlijk dat dit nog kan, aangezien de wiki van wpad al vermeldt dat "While greatly simplifying configuration of one organisation's web browsers, the WPAD protocol has to be used with care: simple mistakes can open doors for attackers to change what appears on a user's browser", met daaronder een hele lijst van blunders.

Het kan uitgezet worden blijkbaar (StackOverflow vertelt hoe), maar misschien wordt het tijd om het opt-in te maken?

[NonTweaker]

Vraagje:

Ik draai geen server, ben er ook niet in thuis maar moet ik me als huis, tuin en keuken gebruiker van Win 7, 8.1 en Win 10 daar " zorgen " over maken en dit event. via jou link in de registry aanpassen? of is dit specifiek iets voor servers die wellicht eerder een target zijn voor dit soort misbruik ?

[FreezeXJ]

Dit is voor als je via openbare netwerken privacy-gevoelige sites bezoekt, iets dat wat mij betreft sowieso al een slecht idee. (Internet)bankieren doe je via een betrouwbare keten, en anders niet.

Mocht je het toch willen instellen, dan is dit wellicht wel een goed idee, totdat de browser-developers het automagisch uitzetten.

[NonTweaker]

Ahh ok, bedankt voor je duidelijke antwoordt

Ik doe dat soort zaken gewoon thuis en nog "ouderwets " via een kabel ipv WiFi

Verder denk ik dat ik met Avast Internet Security, Malwarebytes Anti-Exploit en de FF plug-in "trafficLight " naast Ublock Origin en Ghostery 't zaakje "redelijk "dicht heb.

[Anoniem: 668730]

Het is inderdaad raar dat dit per default aanstaat. Volgens mij is het eigenlijk alleen nuttig in netwerken van bedrijven en andere organisaties die deze instelling prima via een profiel kunnen aanzetten. Voor iemand die thuis, bij vrienden of bij publieke hotspots verbinding maakt heeft dit geen enkel nut.

[Terrestrial]

ik denk dat ik nog een keer moet lezen want ik snap hem niet helemaal. URL's zijn toch altijd inzichtelijk alleen de inhoud niet. Dat het een HTTPS verbinding betreft veranderd daar niks aan. Initieel zal de URL toch naar de DNS server moeten worden gestuurd. Enige oplossing is DNSsec

[Reactie gewijzigd door Terrestrial op 22 juli 2024 20:34]

[The Zep Man]

ik denk dat ik nog een keer moet lezen want ik snap hem niet helemaal. URL's zijn toch altijd inzichtelijk alleen de inhoud niet. Dat het een HTTPS verbinding betreft veranderd daar niks aan. Initieel zal de URL toch naar de DNS server moeten worden gestuurd.

Nee. Bij een HTTPS verbinding zijn alleen de hostnaam (m.b.v. een DNS verzoek), een IP adres en de server TCP poort gebruikt om mee te verbinden bekend (en dat het SSL/TLS protocol gebruikt wordt, middels deep packet inspection). Het documentdeel van de URL wordt alleen gestuurd over de beveiligde verbinding.

Neem een voorbeeld URL:
https://eenwebsite.voorbe...tensie?parameter1=waarde1

Het enige dat je via passief luisteren kan reconstrueren is:
https://eenwebsite.voorbeeld:444

Dit is in de aanname dat voor eenwebsite.voorbeeld een DNS verzoek wordt gedaan. Die hostnaam kan natuurlijk ook in het DNS cache zitten of handmatig aan een hosts bestand toegevoegd worden, maar dat is onwaarschijnlijk.

[Reactie gewijzigd door The Zep Man op 22 juli 2024 20:34]

[Maurits van Baerle]

Inderdaad. En het probleem is dat er soms (semi-)vertrouwelijke informatie in een URL wordt gestopt omdat developers er vanuit gaan dat met een HTTPS verbinding dat deel van de URL niet zichtbaar is voor buitenstaanders.

[The Zep Man]

Inderdaad. En het probleem is dat er soms (semi-)vertrouwelijke informatie in een URL wordt gestopt omdat developers er vanuit gaan dat met een HTTPS verbinding dat deel van de URL niet zichtbaar is voor buitenstaanders.

Als developers zulke vertrouwelijke informatie in de URL (GET) stoppen, dan twijfel ik of ze überhaupt over beveiliging nadachten. POST is flexibeler en veiliger. Zie ook deze vergelijking.

[Crazy D]

POST is niet flexibeler. Stuur jij maar eens een wachtwoord-reset link per mail die als je erop klikt een POST doet. Als je het hebt over data versturen via een formulier op de website heb je wel gelijk.

[The Zep Man]

Stuur jij maar eens een wachtwoord-reset link per mail die als je erop klikt een POST doet.

Het is een slechte gewoonte om klikbare links in mails te sturen wegens phishing aanvallen. De oplossing is om een 'wachtwoord verloren pagina' te hebben en de gebruiker een code over te laten nemen vanuit de email. En zie daar: geen GET nodig.

[Anoniem: 291692]

Heel leuk allemaal, maar het moet ook nog bruikbaar zijn voor de rest van de wereld. En wat dacht je van RESTful web services die werken voor ophalen van data met GET requests. Anyhow je moet in ieder geval geen wachtwoorden in een GET request zetten dat is inderdaad niet handig.

[supersnathan94]

RESTful services kan je ook gewoon tegenaan posten hoor. Het zit em maar net in wat je wil doen.

Het heet niet voor niks GET. Het idee daarachter is juist dat je data ophaalt vanaf de server. Het idee van passwords versturen via de POST method is dan ook het logische gevolg van het feit dat je geen data op haalt van de server, maar juist data wil doorgeven/plaatsen op de server. Het enige wat je terug verwacht is een HTTP 200 OK. Het wijzigen van een pw moet derhalve dan ook via UPDATE moeten gaan (hoewel POST eigenlijk exact hetzelfde is).

[Anoniem: 291692]

RESTful services kan je ook gewoon tegenaan posten hoor. Het zit em maar net in wat je wil doen.

Het heet niet voor niks GET. Het idee daarachter is juist dat je data ophaalt vanaf de server. Het idee van passwords versturen via de POST method is dan ook het logische gevolg van het feit dat je geen data op haalt van de server, maar juist data wil doorgeven/plaatsen op de server. Het enige wat je terug verwacht is een HTTP 200 OK. Het wijzigen van een pw moet derhalve dan ook via UPDATE moeten gaan (hoewel POST eigenlijk exact hetzelfde is).

Klopt opslaan gaat met POST, uitlezen met GET en vaak worden er in een url om die data op te halen allerlei gegevens geplaatst. Die je eigenlijk ook liever niet ziet dat die erin staan..

[Ed Vertijsment]

AFAIK heeft de QUERY 0 met GET te maken nog met POST. Het is bruikbaar in de URL voor alle METHOD's.

[code] scheme:[//[user:password@]host[:port]][/]path[?query][#fragment][/code]


HTTP is slechts een invulling van het scheme.

Zie ook: https://tools.ietf.org/html/rfc3986#section-3.4.

Nu betekend dat natuurlijk niet dat het gebruik ervan altijd handig is. Queries blijven vrij makkelijk ergens achter hangen inderdaad.

[Reactie gewijzigd door Ed Vertijsment op 22 juli 2024 20:34]

[supersnathan94]

Zeker waar, maar in de praktijk wordt de query vrijwel nooit gebruikt icm met post om variabelen door te geven. Bij GET echter wel. Schrijf maar eens een microservice in java mbv DropWizard. Een get wordt aangeroepen door je Path en de parameters zijn dan gewoen (optionele) queryparams

[Crazy D]

Klopt maar wordt nog dusdanig veel gebruikt omdat het wel de meest gebruiksvriendelijke manier is, dat je er toch rekening mee moet houden.

[Overv]

Waarom maakt het uit of de echte e-mails klikbare links sturen of niet? De criminelen die vervalste e-mails zullen sturen, zullen toch altijd gebruik maken van klikbare links.

De gemiddelde gebruiker zal er verder niet bij stilstaan dat de originele e-mails niet van links gebruik maakten. Daarbij moet ook nog aangenomen worden dat ze uberhaupt al een keer een originele wachtwoord reset e-mail hebben gezien.

[TheGhostInc]

Als developers zulke vertrouwelijke informatie in de URL (GET) stoppen, dan twijfel ik of ze überhaupt over beveiliging nadachten.

Je wilt ook gewoon enigszins REST blijven volgen, anders ben je opnieuw het wiel aan het uitvinden, wat ook risico met zich meebrengt.

Daarnaast moet je ook opletten dat je niet informatie aan het verbergen bent die heel eenvoudig op een andere manier is af te lezen:
Stel ik zit bij de dokter en hij doet eerst een search op "TheGhostInc", daarna opent hij mijn patiëntkaart en 2 minuten later print hij toevallig een pagina over alcoholisme. Dan zit ik daar niet voor mijn ontstoken teen.

[supersnathan94]

Het openen van een digitaal medisch dossier zou derhalve ook niet via aflessbare constructies moeten gaan. Sws moet daar een ssl certificaat aan hangen. Daardoor is het ook alleen met bovenstaande wpad mitm attack uit te lezen

[Anoniem: 412052]

het ligt aan de situatie, get parameters kun je via ieder link meegeven ook als er geen formulier aanhangt. Dit is soms noodzakelijk, maar als je als developer post kan gebruiken zou je het ook moeten gebruiken, in ieder geval voor gevoelig informatie.

[Armin]

Als developers zulke vertrouwelijke informatie in de URL (GET) stoppen, dan twijfel ik of ze überhaupt over beveiliging nadachten

Enerzijds waar, maar niet alle URL's gaan via webpagina's.

Denk aan de URL's die OneDrive, Google Drive en DropBox stuurt als makkelijke share. Daar zit in de URL een token, die lees-toegang geeft. Omdat de URL normaal via een (relatief) veilig kanaal verstuurt wordt en niet te gokken is, is dat een goed compromis tussen veiligheid en gemak.

Maar ook password reset URL's werken zo.

[sdktr]

Los van name resolving (wat evt gecached kan zijn) is de hostnaam van een HTTPS aanvraag ook zichtbaar in de TLS onderhandeling. Voorwaarde is dat er gebruik wordt gemaakt van Server Name Indicator (SNI) wat op het moderne web gemeengoed is.

[djwice]

Als je server SNI aan heeft staan (bijvoorbeeld omdat je op 1 certificaat meerdere sub-domeinen draait op 1 IP) is de hostname (sub-domeinnaam) ook leesbaar.

SNI is er om verkeer naar de juiste virtual host te geleiden.

[Macshack]

Bij HTTPS hoort alleen het domein (en subdomein) inzichtelijk te zijn ivm DNS.

[dvz89]

Volgens mij wordt bij HTTPS eerst het kanaal veilig gemaakt (TLS) en zijn alle GET/POST's etc dus versleuteld.

[Terrestrial]

ok duidelijk, maar dns leakage houd je toch altijd. En verder is het een kwestie van autodiscovery in IE of een andere browser uitzetten hoewel ze nog steeds een MiTM aanval kunnen doen.

[bjv]

Als HTTPS wordt gebruikt, dan kan (normaal gesproken) alleen het IP adres (en TCP poort) waar naartoe je connect door een derde afgekeken worden.

TLS/SSL werkt als laag onder HTTP. Er wordt dus eerst een TLS sessie opgezet, welke encrypted is. Daar over heen loopt de HTTP verbinding. Dus is normaal gesproken niet de URL te achterhalen als je HTTPS gebruikt.

[djwice]

Als je server SNI aan heeft staan is de hostname (sub-domeinnaam) ook leesbaar onder HTTPS.

[frankkie12345]

Nee, bij een HTTPS verbinding wordt de URL ook encrypted verstuurd, de volledige request wordt wordt namelijk encrypted verstuurd. Alleen de server zal de URL dan weten.

Er wordt een SSL sessie opgezet, en daarover wordt het normale HTTP-request verstuurd.
Hier een voorbeeldje van een HTTP-request:
GET /wiki/Hoofdpagina HTTP/1.1
Host: nl.wikipedia.org
User-Agent: Mozilla/5.0

Bron: https://nl.wikipedia.org/..._Transfer_Protocol_Secure

[deadinspace]

ik denk dat ik nog een keer moet lezen want ik snap hem niet helemaal. URL's zijn toch altijd inzichtelijk alleen de inhoud niet. Dat het een HTTPS verbinding betreft veranderd daar niks aan. Initieel zal de URL toch naar de DNS server moeten worden gestuurd. Enige oplossing is DNSsec

Aanvullend op The Zep Man's post:

Alleen de hostname is zichtbaar in een DNS-request. DNSSEC is daar ook geen oplossing voor (DNSSEC is eigenlijk nergens een oplossing voor, maar dat terzijde), want het enige wat DNSSEC doet is een digitale handtekening toevoegen op de DNS response. Zowel de request als de response blijven onversleuteld en dus af te luisteren.

De inleidende zin van het Wikipedia-artikel vat het goed samen:

It is a set of extensions to DNS which provide to DNS clients (resolvers) origin authentication of DNS data, authenticated denial of existence, and data integrity, but not availability or confidentiality.

Dus DNSSEC biedt geen vertrouwelijkheid!

[wica]

dhcp... Dus dit is mogelijk op elke (openbaar) WiFi punt?

[DLGandalf]

Ik mag hopen dat de accesspoint/router in een openbaar wifipunt dhcp-server packets onderschept. Uiteraard zal dit niet het geval zijn in een doorsnee winkeltje met gratis wifi
.

[Reactie gewijzigd door DLGandalf op 22 juli 2024 20:34]

[Rinzwind]

Dhcp server packets zijn per definite multicast aangezien er nog geen ip adres verkregen is dus daar valt niks aan te blokkeren in het segment.

[musiman]

Uhh.... multicast? Nee, broadcast!!! Althans, bij IPv4. Bij IPv6 is het namelijk wel multicast verkeer, omdat ieder device dan al een Site Local Unicast adres heeft en daarmee op basis van multicast een verzoek kan sturen naar het multicast ipv6 adres waar alle DHCPv6 servers naar luisteren.

Verder is WPAD altijd al gevaarlijk, niet voor niets dat wpad op de DNS server van nieuwere Microsoft servers op de global query blocklist staat. Eigenlijk is dit een "muah"-hack. Iedere gek die zijn laptop "WPAD" noemt en probeert zijn naam te registreren in de DNS server, kan zich als man-in-the-middle opstellen.

[cdwave]

Alleen de REQUEST is broadcast.

Een IPv6 unicast voor DHCP gaat ook naar het broadcast MAC adres op de physical layer, want op dat punt weet de aanvrager nog niet welk MAC adres daarbij hoort. Een attacker kan gewoon "mee" luisteren op dat unicast adres (tenzij je een managed netwerk hebt met daarin verschillende segmenten).

De RESPONSE van de DHCP server wordt naar het MAC adres van de aanvrager verstuurd. Hoeft niet perse, een broadcast werkt ook, maar doorgaans gebeurt dat wel zo.
De aanvrager heeft dan ook meteen de MAC en IP adressen van de DHCP server, dus van daaruit is ook geen broadcast meer nodig.

[musiman]

Dit heb je volledig verkeerd.
DHCP Discover = broadcast
DHCP Offer = unicast tenzij door de client aangegeven dat deze zonder voorafgaand adres geen unicast kan ontvangen of wanneer de DHCP server de offer wil broadcasten over het subnet van de aanvrager
DHCP Request = broadcast
DHCP Ack = meen ik unicast, maar dat weet ik dus niet zeker.

Lees de RFC er maar op na: RFC 1531.

DHCPv6 werkt met multicast. DHCPv6 servers luisteren naar het adres ff02::1:2 waar alle DHCPv6 servers en relay agents naar luisteren. Daar worden volgens mij gewoon de multicast MAC adressen voor gebruikt:

==
With 112 bits in the Group ID, it is possible to have 2112 group IDs. However, because of the way in which IPv6 multicast addresses are mapped to Ethernet multicast MAC addresses, RFC 2373 recommends assigning the Group ID from the low order 32 bits of the IPv6 multicast address and setting the remaining original group ID bits to 0. By using only the low-order 32 bits in the group ID, each group ID maps to a unique Ethernet multicast MAC address.
==

Forgive me if I'm wrong.

[cdwave]

Multicast en unicast op een gewone huis- tuin- en keukenswitch worden als broadcast behandeld, de switch doet er niks mee. Het hele netwerk krijgt ze binnen.

Dat bedoelde ik met mijn "tenzij..."

Security wise maakt het niet uit, ook de hacker kan zich abonneren op de unicast en multicast adressen.

[musiman]

Uhm... ik denk dat jij echt nog een keer de CCNA opnieuw moet volgen.

Een switch die unicast verkeer als broadcast verkeer behandelt? .....

[Glashelder]

Jazeker wel. Een Access Point kan prima DHCPOFFER pakketen droppen. Nergens voor nodig om die door te laten en dan heb je effectief deze aanval al geblokkeerd.

[MSalters]

Sterker nog, dat hoort. Broadcasts mogen niet het Internet op, die zijn altijd lokaal.

[Glashelder]

Uhm, maar het is wel duidelijk dat het hier om lokaal WiFi verkeer gaat toch?

[blorf]

Ik heb op mijn router de toegang beperkt tot een set mac-adressen. Zal toch ook wel voldoende zijn?

Verder kan ik op de router webinterface niks vinden over wpad, laat staan een http service die daarvoor draait. Hoe detecteer je zoiets?

[rotterdams]

MAC adressen zijn zeer eenvoudig te spoofen. White- of blacklisten op basis van MAC adressen is dus een drempel, maar absoluut geen deur/slot.

[wica]

Waarom zou dit dit moeten filter? Elke AccessPoint moet een IP kunnen uitdelen, via dhcp

Als ik een openwrt WiFi AccesPoint opzet, heb ik totale contrale over de DHCP server en kan deze laten versturen wat ik wil.

The most likely way the attack might be carried out is for a network operator to send a malicious response when a computer uses the dynamic host configuration protocol to connect to a network. Besides issuing addresses, DHCP can be used to help set up a proxy server that browsers will use when trying to access certain URLs.

Dus het probleem zit hem niet zozeer in HTTPS, maar in het stukje vertrouwen dat wij hebben in elke random AccessPoint en hun beheerder.

[DLGandalf]

Mijn punt was dat een andere gebruiker van het openbare wifi netwerk dit niet zou moeten kunnen doen. Als het wifi netwerk is opgezet is door een kwaadwillende, dan kan het inderdaad.

[Reactie gewijzigd door DLGandalf op 22 juli 2024 20:34]

[wica]

Sorry, verkeerd begrepen. Maar idd andere gebruikers van een AP zouden dit niet mogen / kunnen doen.

[Armin]

Ja, mits WPAC aan staat - hetgee nstandaard het geval is.

[Macshack]

Maar als je toegang hebt tot het verkeer (of het verkeer naar je toe kan trekken) wat over een wifi gaat kun je dan ook niet gewoon een MIM aanval uitvoeren? Dan kun je alles zien, niet alleen de URL. Je moet zozo, ook bij HTTPS geen beveiligingkritische data in de URL stoppen. Bij publieke WiFi kunnen de individuele gebruikers doorgaans niet bij elkaars verkeer. Je kan wel een dummy WiFi opzetten met dezelfde SSID om vervolgens een MIM aanval uit te voeren.

[chielsen]

Ja, en precies daarom is HTTPS ontwikkeld. Voor een intern netwerk (waar je de hele keten vertrouwt heeft het weinig toegevoegde waarde).
Deze aanval verslaat dus de beveiliging en privacy die je denkt te hebben door https te gebruiken.

[Macshack]

Ik bedoel meer aan te geven dat deze hack dan niet heel veel meer blootlegt. Als je al tussen de twee partijen kan zitten dan biedt HTTPS zo zo geen beveiliging. Dus wat is dan zo speciaal aan deze hack?

Een beetje het idee van. Als ik je pinpas vind en je pincode kan reverse engineren dan kan ik je saldo bekijken. I.p.v. een meer voor de hand liggend probleem, namelijk; Ik kan geld van je rekening afhalen.

Of zie ik iets over het hoofd?

[Cbr]

Als je HTTPS gebruikt moet je ervanuit kunnen gaan dat voor iemand die meekijkt op de router (je baas) alleen maar zichtbaar is welke website je bezoekt (facebook.com). Niet welke pagina van die website (facebook.com/groups/job-haters).

Omdat dat de standaard is zijn er web-applicaties die niet meer zo veilig zijn als bedoelt wanneer een 'meekijker' alle volle URLs kan zien.

Een voorbeeld in het geval van facebook:
- Foto's die je bekijkt hebben een unieke URL. Deze krijg jij alleen vanuit facebook opgestuurd als je de foto mag bekijken (omdat je iemands vriend bent bijvoorbeeld). Nu zou je baas ook al deze foto's kunnen zien, omdat deze de URLs kan 'afvangen'.

[Macshack]

Dat snap ik. Maar als mijn baas dit zou willen dan zou hij toch ook gewoon een MIM aanval kunnen uitvoeren? Waardoor hij niet alleen mijn URL kan zien, maar ook wat ik daadwerkelijk zie? Deze hack is misschien wat eenvoudiger dan een MIM aanval, dus toegankelijker. Maar het biedt niet meer toegang tot mijn data. Mijn baas kan ook de systeembeheerder vragen om mijn browsegeschiedenis bij te houden. Ik bedoel dus te zeggen/vragen, dat iemand met zoveel toegang zo zo deze dingen kan doen. Terwijl ik er zo over nadenk. Begrijp ik wel dat, omdat het makkelijker is, het voor gratis wifi aanbieders het een stuk eenvoudiger is om je browse gedrag op te nemen.

[Cbr]

Ik begrijp je punten, ik kwam met een voorbeeldje waarbij iemand met toch al belachelijk veel toegang meer over je te weten wilt komen. Mocht ik alles goed hebben gelezen zijn op deze manier ook subtielere aanvallen mogelijk door personen met veel minder wijde toegang.

Terugkomend op jouw vraag: Als jouw baas een 'traditionele' MITM-attack uitvoert dan kun jij zien dat HTTPS niet aanstaat. (En sommige websites met HSTS weigeren dan gewoon.) Dit verslaat wel degelijk HTTPS een heel klein beetje zonder dat je dit ziet/opmerkt.

[Reactie gewijzigd door Cbr op 22 juli 2024 20:34]

[supersnathan94]

Ligt er aan of er een custom cert op de PC's staat waardoor het verkeer opnieuw versleuteld kan worden. Beetje zoals het superfish debacle bij lenovo en het gezeik wat Dell laatst ook had. Protip: Met werk PC's moet je geen privé dingen doen

[Cbr]

Ik gebruikte wellicht het verkeerde voorbeeld (en omdat ik mijn eigen laptop naar het werk meeneem ligt dat bij ons ietsjes anders).

[supersnathan94]

Je bent niet de enige. Ik heb ook m'n eigen MBP mee. De ubuntu C2D op het werk is niet echt fijn mee developpen (Java, Javascript en AngularJS). Alles wat niet bedoelt is voor het normaal gebruiken van het internet wordt passief geblocked via m'n hosts file.

[SeatRider]

Eh, nee dus. De volledige URL wordt gelogd. De inhoud van die pagina is niet zonder meer opvraagbaar. Je baas kan die foto's niet zien, omdat FB als het goed is wel controleert of jij rechten hebt op die URLs.

[Cbr]

Dat is het curieuze aan Facebook: heb je eenmaal de URL van een foto te pakken dan controleert Facebook niets meer. Nada. Dat is een van de relatief onschadelijke dingen die buit gemaakt kunnen wordenbij het gebruik van deze aanval.

Met andere woorden: zodra je de URL van een foto op Facebook in handen hebt kun je hem overal openen. Ingelogd of niet, vriend of niet.
Probeer het maar eens: kopieer de URL van een foto op facebook en log uit van Facebook dan is die foto nog gewoon te bekijken... (en door te mailen etc.)

[Reactie gewijzigd door Cbr op 22 juli 2024 20:34]

[SeatRider]

Deze inhoud is momenteel niet beschikbaar
De door jou gevolgde link kan zijn verlopen of de pagina is wellicht alleen zichtbaar voor een doelgroep waarin jij niet bent opgenomen.

[Cbr]

De URL van de afbeelding zelf. Niet die van de pagina die de afbeelding laat zien...

[Armin]

Of zie ik iets over het hoofd?

Slechts ten dele. Een MITM aanval uitvoeren is nog best heel erg lastig. Dezelfde aanval via WPAC uitvoeren vereist veel minder moeite en omzeilt bovendien enkele beschermingen die HTTPS expliciet heeft tegen MITM aanvallen.

Maar je hebt verder gewoon gelijk dat als een aanvaller de DHCP server kan beinvloeden/vervangen, dat netwerk zelf al gecomprimeerd is, en je al veel andere gevaarlijke dingen kunt overkomen anders dan deze WPAC aanval.

[Macshack]

Dank voor de opheldering. Wat ik dus al een beetje dacht, zie mijn reactie.

[MSalters]

Nee, HTTPS voorkomt dat een man-in-the-middle mee kan kijken. HTTPS is een encrypted verbinding (tegenwoordig via TLS, Transport Layer Security). De MIM kan wel zien wie er communiceert. Microsoft heeft dus helemaal gelijk dat ze alleen het host-deel van de URL naar WPAD versturen, dat was met HTTPS toch al niet geheim. (Om dat te verbergen heb je Tor nodig in plaats van HTTPS).

[cdwave]

Nee.

HTTPS versleutelt ALLES, en je baas kan er niks van inzien. Ook niet als hij naast je komt zitten, de netwerkstekker in zijn machine prikt en dan pas naar het netwerk door routeert. HTTPS is ontworpen om via een onbetrouwbare verbinding (je baas dus, of je provider, of de open wifi van de kroeg) toch veilig data te kunnen uitwisselen.

Deze hack maakt het mogelijk voor je baas om ongemerkt de URI te bekijken, maar de rest van het bericht blijft onleesbaar.

Als je baas een proxy heeft die https verkeer uitpakt en weer inpakt (deep packet inspection werd dat genoemd dacht ik) dan merk je dat, omdat je browser op je werk PC - als je baas dat via het domain heeft geregeld - het certificaat van je baas zal laten zien en niet dat van de bank. Je eigen apparatuur (laptop, tablet) zal gaan klagen dat het certificaat niet correct is, en expliciet om toestemming gaan vragen, die je uiteraard absoluut niet mag verlenen. (Ik heb nooit begrepen waarom een browser deze optie biedt.)

[base_]

Dit is toch de "Automatically detect settings" van Internet Properties -> Automatic configuration? Laat ik die nou altijd uitzetten. Als ik iets al 10 jaar niet vertrouw is het wel automatisch detecteren van internet settings, ik stel toch niet voor niets zelf dhcp/gateway/dns in...

[Armin]

Nee helaas, dat zet WPAC niet uit op Internet Explorer.

Maar op IE ben je toch al veilig, want die stuurt de URL geheel niet door.

Mocht je WPAC nietemin willen uitzetten moet je of Group Policy gebruiken (Windows 7 en ouder) of registry (alle Windows). Zie ook deze Tweakers post.

[base_]

Idd, nu je het zegt zie ik dat meerdere browsers hun eigen implementatie hebben. Heel idioot eigenlijk dat je wel vanuit internet opties in IE en Chrome bij deze configuratieoptie uitkomt. Ik moet wel zeggen dat ik zowiezo ook in Chrome al veel uitschakel. Ik ga toch eens wat group policies opzoeken.

[MSalters]

Je weet dat DHCP ook een vorm van automatische configuratie is? "Dynamic Host Configuration Protocol".

[The Zep Man]

Een manier om deze tegen de gaan is door het uitschakelen van wpad, al kan dit in sommige gevallen problemen met zich meebrengen.

Het probleem is dan dat je niet weet welk proxy adres gebruikt moet worden, als zoiets al nodig is. Maar hoeveel verbindingen maken hier vandaag de dag nog gebruik van?

[hackerhater]

Bedrijven doorsnee, maar dan loop je even naar de IT-afdeling.

[Armin]

Alleen is het op mobiele apparatuur vaak niet/moeilijk uit te zetten.

[Mr_Light]

Grappig dat het wiki artikel van pac onder het kopje security naar een pagina met de zelfde strekking (uit 2013!) verwijst. http://www.darkreading.co.../d/d-id/1139313?print=yes Dit artikel gaat dan over de combi met wpad waar ook al voor gewaarschuwd word dat je er allemaal vervelende kunstjes mee uit kunt halen.

Hopelijk word met de aandacht die het nu krijgt er echt wat aan gedaan.

//edit damn in 2011! was er ook al iemand die waarschuwde wpad hyjacking
http://www.linuxjournal.c...y-protocol#comment-368560

WPAD is a security risk!..
...If the user of that computer sets up a hack proxy, he can monitor all web access (even https), without users noticing anything... Man-in-the-middle-attack!

[Reactie gewijzigd door Mr_Light op 22 juli 2024 20:34]

[musiman]

Klopt. Dit is al jaaaaaren bekend en ik adviseer ook al jaren iedereen om dat vinkje in IE uit te zetten om automatisch de proxy server te vinden.
Het gekke is, dat ik nog steeds al mijn cursisten weet te verbazen hoe eenvoudig deze "hack" is. En let wel... mijn cursisten zijn IT'ers...

Beste Microsoft, zet alsjeblieft standaard dat vinkje uit!!!

[Armin]

Microsoft is echter nu al jaren niet kwetsbaar voor deze aanval

Bij bedrijven echter krijg je anders weer support-calls om dit aan te zetten.

En als je DHCP server compromised is (voorwaarde voor deze aanval) is WPAC bovendien niet het eerste waar ik bang voor ben ...

[MadEgg]

Ik weet niet genoeg van proxies, maar betekent dit nou dat encrypted verkeer over een proxy helemaal niet mogelijk is? Een proxy zou toch moeten fungeren als soort van remote gateway, waarbij je een al dan niet encrypted verbinding opzet met de proxy-server en daarna via die proxy server een al-dan-niet encrypted verbinding opzet met de doelserver?

Dat zou betekenen dat een HTTPS-verbinding via een proxy net zo goed encrypted is inclusief de volledige URL. DNS blijft af te luisteren maar dan heb je alleen de hostname. Hoe komt de proxy-server dan bij de volledige URL zonder certificaatwaarschuwingen te genereren?

[update]
Heb de bronnen doorgelezen. Het genoemde PAC-bestand bevat een stukje Javacript met een FindProxyForURL functie die aangeroepen wordt met het volledige URL, welke vervolgens de juiste proxy-server teruggeeft. Deze functie kan deze URL dus ook gewoon doorgeven aan een de inbreker. Enorme faal in het protocol dus; sowieso zou de domeinnaam voldoende moeten zijn (en dat doet IE dus ook), maar de mogelijkheid om per URL een andere proxy op te geven vind ik ook wel gevaarlijk.

[Reactie gewijzigd door MadEgg op 22 juli 2024 20:34]

[borft]

Nee, als je een https request over een proxy doet, zal je browser een CONNECT sturen, waarna de proxy op tcp niveau gaat proxien. De proxy ziet dus alleen de versleutelde pakketjes langkomen.

[sliekens]

Lijkt me dat een aanvaller via dat PAC script ook meteen al je HTTP(S) verkeer kan omleiden langs een eigen proxy server. Dus ook al geven IE/Edge de volledige URL niet mee aan het PAC script, ze geven hem wel mee aan die proxy server als onderdeel van de HTTP request.

[Reactie gewijzigd door sliekens op 22 juli 2024 20:34]

[borft]

Niet bij HTTPS. Bij https stuure je browser een connect, waarna ie een ssl tunnel door de proxy opzet. Pas daarna gaat je browser door de tunnel het HTTP request doen. De proxy weet dan dus alleen de eindbestemming (ip adres), maar niet wat de exacte url is. Nog sterker, de proxy weet niet eens wat de hostname is.

Waar het hier over gaat, is dat je in de client side configuratie een stukje javascript kunt draaien, wat proxy settings aanpast op basis van de URL. En, dat het mogelijk is via DHCP een stukje javascript daarvoor naar de browser te pushen (middels een PAC file). Hierdoor kan de aanvaller dus de volledige URL achterhalen.