Op nu.nl is sprake van HTHS zonder enige verdere uitleg wat dit dan doet... kan iemand hier dat uitleggen?

Dit is toch oude koek volgens mij?

Ik vertel al jaren klanten dat ze bijzonder goed moeten weten of ze wel echt met de hotspot communiceren - bijvoorbeeld in een hotel - dat ze verwachten. De hacker in de kamer naast je kan immers een KPN hotspot gewoon nadoen en dan is een MITM attack toch altijd mogelijk?

Wat ook afgeraden wordt is om wifi te gebruiken voor bankzaken en IE te gebruiken voor bankzaken omdat IE nog geen volledige controle uitvoert.
Dat gebeurd pas in een volgende versie, en wanneer die uit komt, wilde Microsoft niet bekend maken.
De apps zijn niet vatbaar geweest voor deze aanval.

Werkelijk onvoorstelbaar dat dit nu in de media komt. SSL Strip dateert van 2009 https://www.security.nl/posting/24341/Hackertool+omzeilt+SSL-beveiliging+websites

Dit soort aanvallen zijn werkelijk niets nieuws. Vreemd dat organisaties als Kassa en het NCSC zich voor dit soort sensatieverhalen lenen...

De suggestie dat het hier om een nieuw lek gaat, is onjuist. Wat in de uitzending helaas ook niet duidelijk werd, is wat wel genoemd wordt in http://www.securelabs.nl/index.html%3Fp=1012.html: De manier waarop getoond wordt dat van https gebruik gemaakt wordt, verschilt (helaas) per webbrowser. Veel banken gebruiken overigens een EV certificaat waardoor de URL balk groen kleurt, dat verwijnt tijdens de aanval.

Het risico bij het gebruik van draadloze netwerken is inderdaad groot, maar gebruikmaken van een ethernetkabel is geen garantie dat deze aanval niet kan plaatsvinden. Brenno de Winter noemde in de uitzending het risico van een MitM bij internet service providers, de kans daarop vind ik lastig in te schatten. Ik zie echter het laatste jaar wel een verhoogd risico door het aantal thuis-routers dat zo lek blijkt als een mandje. Volgens (Duitstalig) http://www.heise.de/security/meldung/Das-Router-Desaster-Fritzbox-Update-geraet-ins-Stocken-2173043.html zijn in Duitsland nog veel Fritz!Box routers niet gepatched en daardoor kwetsbaar, ik vermoed dat dit in Nederland niet veel beter zal zijn. In veel merken en typen routers zijn de laatste tijd kwetsbaarheden gevonden en gepubliceerd. Een aanvaller die de DNS server instellingen in de router kan aanpassen hoeft er verder niet naar om te kijken, de "klanten" melden zich vanzelf.

HSTS kan helpen het vandaag gemelde probleem tegen te gaan, maar wat we feitelijk nodig hebben om netwerk-gebaseerde MitM aanvallen te voorkomen, is een webbrowser die uitsluitend https ondersteunt naar 1 enkele site tegelijk, en waarbij het toevoegen van (root) certificaten slechts op een betrouwbare manier kan plaatsvinden.

Hoewel ik geen fan ben van apps voor internetbankieren, voldoen zij wel aan wat ik hierboven beschrijf (mits foutloos geïmplementeerd). Een recent onderzoek van de UVA laat zien dat Windows Phone 8 apps voor Rabobank, ABN-AMRO en ING resistent zijn tegen dit soort MitM aanvallen, zie https://os3.nl/_media/2013-2014/courses/ssn/projects/ssn_report_v2_gieske_vanerkelens_vandenhaak.pdf (dat verslag en andere onderzoeksverslagen zijn te vinden in https://os3.nl/2013-2014/courses/ssn/start).

Vereenvoudigd, bij HSTS stuurt de server een header mee met een instructie voor de web browser: als je het komende jaar deze site nogmaals bezoekt mag dat uitsluitend via https.

Als je voor het eerst die site bezoekt en de aanval op dat moment plaatsvindt, kan de aanvaller natuurlijk die header verwijderen en de rest van de informatie wel naar jouw webbrowser doorspelen. Als er op dat moment geen aanval plaatsvindt ben je in elk geval voor het huidige en voor het volgende bezoek beschermd (indien het volgende bezoek plaatsvindt binnen de termijn genoemd in de header - een termijn die overigens instelbaar is). De webbrowser moet dit vervolgens "onthouden" per site die zo'n header stuurt. Conformeren aan HSTS betekent nog meer voor webbrowsers, zie daarvoor http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security.

Aanvulling: Ik weet hier nog niet zoveel van, maar wat ik ervan begrijp is dat de aanvaller ook het hotspot van het hotel kan nadoen, en als zijn signaal sterker is dan van het hotel, zal jouw computer met het rogue access point verbinden (als je al verbinding hebt kan hij je dwingen die te verbreken en deze opnieuw op te zetten). Als de aanvaller het WLAN wachtwoord kent is het voor een leek nauwelijks mogelijk om zo'n aanval te detecteren. Dit soort aanvallen staan bekend als "evil twin" attacks.

Als de aanvaller het gebruikte WLAN wachtwoord niet kent (bijv. in het geval van een bedrijfsnetwerk) en dit niet kan/wil kraken, kan hij een social engineering attack toepassen, bijv. door een webpagina van de bedrijfsrouter te tonen en melden dat er een firmware update geweest is en je daarom het WLAN wachtwoord opnieuw moet invoeren.

In elk geval IE11 laat rechts van de URL balk een slotje verschijnen bij een versleutelde verbinding. Bij Firefox 29 staat dit slotje op dezelfde plaats waar bijv. het "favicon" van http://www.nu.nl/ getoond wordt waardoor dit simpel te spoofen valt - ronduit stom van Mozilla.

Aanvulling/correctie 2014-05-25 16:54 m.b.t. het laatste stukje hierboven: Onder Windows 7 laat MSIE 11 het slotje rechts van de URL balk zien als je kiest voor het "Classic Windows" thema; bij het standaard Windows 7 thema is het slotje 1 van grijze icoontjes vaak op een gekleurde achtergrond (waar ook nog vage informatie uit onderliggende vensters in kan doorschemeren) en daardoor lastig te onderscheiden. Firefox 29 met standaard instellingen toont geen "http://" maar in plaats daarvan een vaag grijs wereldbolletje. Links daarvan (of van "https://" dat wel getoond wordt) staat een grijs icoontje dat zo te zien ofwel een soort legosteentje is (bij http), een slotje (bij vertrouwde https) of een driehoekje met een uitroepteken erin (bij https met problemen, zie bijv. https://tweakers.net/).

@Erik, uiteindelijk kan de aanval ALLEEN, maar dan ook ALLEEN, slagen als de eindgebruiker aan het slapen is. Eigenlijk is het gewoon een phishingaanval m.i.

Inderdaad een bekende methode. Ook iemand een nieuw certificaat aanbieden werkt ook in heel veel gevallen (mensen klikken toch op ok).

Grote bedrijven hebben soms dergelijke apparatuur:
http://www.bluecoat.com/products/ssl-visibility-appliance
Internetbankieren op het bedrijfsnetwerk zou ik dan ook niet doen.

Onzin omdat je bij deze aanval wel de door jouw ingevoerde gegevens ziet... achter de schermen is de aangepaste versie verzonden.
Doordat de eindgebruiker NIETS ziet, kan de eindgebruiker er niets aan doen.

Wanneer de browser geschiedenis wordt verwijderd (inclusief cookies, tijdelijke internet bestanden en enz.), wordt dit dan nog wel door de browser "onthouden" of wordt de header dan ook gewoon verwijderd?

JAWEL de eindgebruiker kan zien dat hij NIET op de echte banksite zit. Zo moeilijk is het niet... Als hij dan vervolgens toch zijn gegevens invult....

Lees eerst eens goed hoe deze aanval werkt voordat je zulke stellige uitspraken doet. Een gevolg van de werking van deze aanval is nml. dat de verbinding weer gewoon HTTP wordt. Dus de gebruiker kan wel degelijk zien dat er iets niet klopt met de verbinding.

Het wordt anders als de aanvaller de rootcertificaten zelf kan manipuleren, zoals met Diginotar gebeurd is. Maar dat is bij deze besproken aanval methode niet aan de orde.

• Wat is dan het verschil in de werking van een pc die besmet is met een geavanceerde banking trojan en een transactie aanpast na het moment dat deze goedgekeurd en wel naar de bank wordt verzonden door de klant?

Banking trojans met een dergelijke aanpak, het tussentijds aanpassen van de verzonden transactie, bestaan al lange tijd.
Dat probleem lijkt me altijd nog vele malen groter dan de kans op wifi misbruik. Niet alleen omdat wifi misbruik in deze variant relatief 'nieuw' is maar ook omdat inmiddels de meeste mensen met 'apps' bankieren die voor dit misbruik niet gevoelig zijn.

Hobbeltje voor malware is altijd nog dat je een pc eerst moet besmetten, de praktijk leert dat dat nog steeds in veel gevallen lukt.
Daarnaast heeft het gebruik van malware de nodige voordelen. Het bereik van malware is vele malen groter met het voordeel dat men zich veilig kan bevinden in een 'Safe H(e)aven' buiten Europese arm der wet.
Op een terras gaan zitten of op een andere Hot($hot)Spot een apparaat plaatsen is niet zonder 'kraag-vat-'risico.
Tel uit de winstvoordelen voor malwaremakers bij het gebruik van een banking trojan.

-> Tenzij?
Wordt de werking van banking trojans die tusentijds transacties aanpassen mogelijk ook geblokkeerd met het door banken instellen van de HSTS header?
Dan zou een belangrijk bestaand en veel voorkomend malware probleem daarmee eindelijk / voorlopig ook zijn opgelost.

-> Waarom hebben banken die HSTS Header niet al jaren geleden ingesteld vanaf het moment dat diverse browsers dat gingen ondersteunen?
Waren Internet Explorer of Safari implementatie uitstel en het bijbehorende 'grote' marktaandeel nog het probleem om HSTS te implementeren?

Dan had men op zijn minst dit al wel kunnen instellen voor Mozilla en Chrome browser varianten op basis van gedetecteerde browserheaders.
Detectie op browserheaders vindt namelijk al plaats door banken sites, experimenteer maar met wat verschillende useragent strings, oudere en nieuwere en je ziet welke door banken wel of niet worden geaccepteerd.
(Schade-schande-kennis, kom je achter als alleen de nieuwste van de nieuwste browserversies worden geaccepteerd met als gevolg geblokkeerde Long Term Support browser versies, of al te strak 'ingeregelde' browsermerkgerichtheid).


• Overigens, internationaal is al eerder geconstateerd dat ook grote internationale banken HSTS tot op dat moment nog niet hadden geïmplementeerd.
https://scotthelme.co.uk/hsts-the-missing-link-in-tls/


+ 8 screenshot voorbeelden van code


• Niet vergeten, de discussie gaat begrijpelijk heel terecht over banken, het overschaduwt wel de opmerking van 'de Winter' dat vele andere toepassingen ook kwetsbaar zijn voor misbruik.

Hopelijk wordt daar ook aandacht aan besteedt door betrokken partijen, alle https verbindingen voortaan standaard met HSTS header en een waarschuwing van je browser wanneer dat protocol niet wordt gebruikt?
Misschien kunnen browser makers op die manier gebruik van HSTS stimuleren, past de markt zich uiteindelijk aan omdat klanten over waarschuwingen bij services 'gaan zeuren'.

Als het geld dreigt te kosten zijn veranderingen verassend snel geïmplementeerd, dat is weer eens bewezen.

Nee, de aanval slaagt niet bij gebruikers die precies weten waar ze op moeten letten en die geen haast hebben, en die combinatie is schaars. Zie ook wat ik schreef onderaan de eerste bijdrage.

Goed geïmplementeerde apps voor internetbankieren tonen aan dat dit probleem technisch opgelost kan worden (dat niet alle apps goed geïmplementeerd worden blijkt bijv. uit http://www.theregister.co.uk/2014/01/13/banking_apps_insecure_and_badly_written_say_researchers).

Uit https://tools.ietf.org/html/rfc6797#section-12.5 zou je kunnen afleiden dat verwijderen niet de bedoeling is, maar een gebruiker die niet wil dat op zijn computer is terug te vinden welke sites hij wanneer heeft bezocht, zou daar anders over kunnen denken. Ik heb geen idee hoe browsers hiermee omgaan.

Het lijkt me handig als de browser dit wel bewaart wanneer de browsergeschiedenis verwijderd wordt. Ik kom er wel een keer achter als ik een website bezoek die van HSTS gebruik maakt. :-)

Parallelle ontdekking?

"Websites Must Use HSTS in Order to Be Secure"
April 4, 2014 | By Jeremy Gillula

Vervanging slotje / https methode met screenshots geïllustreerd
https://www.eff.org/deeplinks/2014/02/websites-hsts

Dat staat bekend als een MitB (Man in the Browser) aanval. Die malware grijpt in tussen de grafische interface van de browser (zowel invoer als uitvoer) en de SSL/TLS routines die informatie versleuteld (via https) uitwisselen met de bank. HSTS heeft hier geen enkele invloed op.

Inderdaad mooie plaatjes!

Overigens stellen https://www.veiligbankieren.nl/index.php?p=1189271 en http://www.betaalvereniging.nl/nieuws/internetbankieren-via-wifi-hotspots/ dat het slotje groen moet zijn, en dat is verwarrend: in IE 11 wordt het slotje nooit groen maar is altijd grijs!

De URL balk wordt wel groen als er sprake is van een EV certificaat (het slotje blijft grijs), iets dat de meeste NL banken wel zullen gebruiken (https://www.chase.com/ heeft nu ook een EV certificaat, kennelijk sinds 19 mei). Echter, bijv. https://www.digid.nl/ gebruikt geen EV certificaat, daar wordt helemaal niets groen. Dat wil echter niet zeggen dat er iets mis is met de https verbinding...

Het is een detail, maar juist wanneer gesteld wordt dat elk detail belangrijk is, vind ik dit jammer.

Inderdaad. Maar bij deze Proof of Concept hebben de researchers er voor gekozen om van de favicon een grijs slotje te maken. Echte aanvallers kunnen natuurlijk ook een groene gebruiken. Men kan beter roepen om te kijken of er HTTPS staat ipv HTTP dan kijken naar een groen slotje.

Kassa is een consumenten programma, voor de gemiddelde consument is dit wel degelijk iets nieuws.

Sterker nog, je kan de gemiddelde consument hier 50 keer over vertellen, en de 51e keer zal het voor hem nogsteeds iets nieuws zijn.

Aanvullende opmerkingen en vragen :

- In ieder geval voor Firefox (Mac) is in de Firefox app zelf al een lijst met ± 200 websites opgenomen die gebruikmaken van HSTS ("Xul" bestand).

- Eén daarvan (uit de standaardlijst gevist) is www.python.org , kan je het proberen te testen met deze site.

- Waar worden aanvullende HSTS headers opgeslagen?
Je mag toch hopen dat dat niet in de cookies is, die zijn te makkelijk te verwijderen, ook al doen vermoedelijk massa's mensen dat niet.

Ik heb het sterke vermoeden dat deze aanvullende HSTS headers in de speciale cache's zitten,
de verborgen caches', waarbij ik het het vermoeden heb dat bijvoorbeeld Firefox deze niet leegt in geval van een 'Safe' browser boot.

Echter, vinden kon ik het niet. Veel teveel bestanden in de verborgen cache directories, waarbij de files geopend in een editor weer enorm veel zelfstandige directories met vele bestanden bevatten.

* Interessante vraag is waar die HSTS headers dan bewaard worden door je (Firefox, ..)browser.

* Andere interessante vraag is hoe je eigenlijk bij een https site kan vaststellen of HSTS geïmplementeerd is.
Hoe lees je een eventueel aanwezige header uit? Die kan geloof ik ook nog op verschillende manieren zijn geïmplementeerd met mogelijk als gevolg een andere plaats in de pagina code?

Want als je geen HSTS site bezocht hebt, het niet kan zien of controleren, en die nog niet voorkomt in je standaard HSTS definities van de browser, is het ook slecht controleren op opslag locaties van nieuwe HSTS definities.
Ben benieuwd of iemand daar al achter is gekomen.


@ Erik van Straten, bedankt voor de uitleg van het verschil tussen MitM en MitB. Daar had ik niet bij stilgestaan.

Eveneens zeer relevante constateringen tussen browserweergave kleurverschillen.
Gaat IE inmiddels niet meer voor goud? ;-) :
https://www.security.nl/posting/18119/20%25+consumenten+onbekend+met+gouden+slotje

Denk dat het goed zou zijn als er een algemene browserstandaard zou komen voor certificaat (kleur)weergave (gerelateerd voorbeeld volgt in volgende reactie).

Nog wat bedenkingen, side effects en oplossingen (vervolg 15:31 door Anoniem)

Certificaat kleuren en Favicons verwarrend? / Internetbankieren met aleen "S" focus ook al geen goede garantie!


* Favicons verwarring voorkomen :

- Favicons weergave kan je ook deactiveren in Firefox,
als tegenwicht bij de (toch al brede) ontwerp verwarring in Firefox 29.
Te vinden onder Dubbelklik op de regel geeft
- Wat is nou helemaal de toegevoegde waarde van een Favicon?
Het leidt alleen maar af, van de s èn :// welteverstaan.
Kleurenlabels zijn voor klanten 'niet' meer uit te leggen en te onthouden, zeker niet als je IE en Firefox gebruikt, denk ik zo.


* Browserstandaard eenduidig Kleurcertificaat gewenst - focus op alleen de "s" niet veilig tegen social engineering:

- Nieuwe certificaat weergave standaard voor browser noodzakelijk?

Voordat social visual engineers met nieuwe (sub)domeinnaam slimmigheden komen als bijvoorbeeld :
geeft dan

En dat niet alleen, dan wordt tot overmaat door sommige browsers standaard het http gedeelte weggelaten en staat alleen nog https wel zichtbaar in beeld.
(met uitzondering van voor de doorsneecomputeraar; "een dubbel stippeltje en van die schuine streepjes, maar dat is voor computernerds, daar let 'ik' nooit op". Bij de kenners bekend als "://" ).

Dan wordt het uiteindelijk in social engineer variant zoiets, gaat helaas mogelijk wel werken denk ik :


Zeker in combinatie met een Favicon weergegeven als een slotje.


* Volledige urlweergave weer activeren :

- Voortaan dan toch maar weer een string standaard activeren in Firefox ?

Volledige url weergave activeren, Open zoek de string
staat standaard op , op zetten geeft ook volledig de http:// of https:// weer.

Hier mag men wel eens wat meer aandacht aan besteden. Een televisieprogramma is niet genoeg.

"Werkelijk onvoorstelbaar dat dit nu in de media komt. SSL Strip dateert van 2009 https://www.security.nl/posting/24341/Hackertool+omzeilt+SSL-beveiliging+websites"

Zolang de aanvallen nog plaatsvinden en effect hebben lijkt iedere aandacht mij goed. Het feit dat de techniek al jaren bestaat is verder irrelevant zolang het risico nog bestaat.

In de -Engelstalige- Firefox op mijn PC zie ik onder menu "Tools" een item "Web Developer" met daaronder een heel stel mogelijkheden. Ik weet alleen niet of dit standaard aanwezig is op alle Firefox installaties, het zou kunnen dat dit een optie was tijdens installatie (daar zou ik dan zo weer voor kiezen).

Interessant hier is Tools -> Web Developer -> Network (ook te activeren met Ctrl-Shift-Q). Start een nieuw browser venster en tik genoemde toetsencombinatie (of gebruik het menu); onderin Firefox verschijnt dan een debug venster.

Nu tik je bovenin als URL in: security.nl

Vervolgens klik je in het debug scherm op de eerste regel (of een andere, maar niet uit): dan verschijnt rechts een deelvenster met bovenin "Response headers" (en onderin Request headers - maar die interesseren ons nu niet). Dat zou er ongeveer als volgt uit moeten zien: https://developer.mozilla.org/en-US/docs/Tools/Network_Monitor#Network_request_details.

En wat zie ik bij security.nl? Deze stuurt netjes een HSTS header:
Mijn complimenten aan de beheerders van security.nl!

Hartelijk dank voor de uitleg!
Ja die functie zit ook op de 'MacFFox'.


Dat is inderdaad heel mooi van Security.nl!
Goed voorbeeld doet volgen?
Dan leest misschien de meerderheid van de bank'jongens' deze site waarschijnlijk niet.
Of ze krijgen hun zin niet, of wel maar geen snelle medewerking, of … ???

Hoe zou het ervoor staan met de implementatie van HSTS headers op de bankensites?

12 sites bekeken met internetbankieren functie, op zoek naar de "Strict-Transport-Security" header.
De drie bekendste banken hebben het geïmplementeerd, nog een andere groene online bank ook, plus een mij onbekende bank met een woordspeling in de naam.
Bij de laatste lijkt er ook nog speling in aanbod van mixed content te zitten. Tussen de verbazingwekkende hoeveelheid extra externe (o.a. tracking?/social) domeinen komen twee keer dubbele domeinen voor die zowel met http als https adres staan vermeld. Hopen maar dat je browser automatisch voor het https domein kiest, ik vraag het me af, zonder https everywhere?

Maar goed, de "Strict-Transport-Security: max-age= " headers zijn bij deze banken te vinden met wel wat variable lengtes. Een is er duidelijk het kortst. Voordeel of nu juist een nadeel?

Echter,
Bij de overige 7 bankierders, waaronder ook een verzekeraar/bankierder, zie ik deze header niet!
Verder geen namen noemend hier, 'kleinere' banken of niet, als de bankrekening van de individuele spaarder maar interessant is (denk het wel).
Check je eigen bank toch nog maar eens even, voor de zekerheid.

Kassa programma voorbij, probleem weer van tafel?
Webdevelopers op vakantie?
Toch het risico van de klant?
Ik vind het achterblijvende resultaat nogal opmerkelijk.

@anoniem 15:31 Bedankt voor je reactie en voor het zoeken naar een website met HSTS.

Overigens kan ik het nu ook testen door dat Erik van Straten opgemerkte dat security.nl ook een HSTS header stuurt. (Inderdaad conmplimenten aan de beheerders van security.nl).

Nu is inderdaad wel de vraag waar HSTS headers bewaart worden door (Firefox, ..).


Dit kan overigens ook via F12 is iets gemakkelijker ;-)