'Aanmaken van certificaat voor Fritzbox geeft hostnaam prijs via internet'

Een nieuwe bèta van firmware voor de Fritzbox-router laat gebruikers een Let's Encrypt-certificaat aanmaken om beheer via internet over een beveiligde verbinding mogelijk te maken. Daardoor wordt de hostnaam blootgesteld aan derden, schrijft een Duitse site.

Beveiligingsonderzoeker Hanno Böck schrijft op de site Golem dat de via de functie aangemaakte certificaten te vinden zijn met behulp van certificate transparency-systemen. Er zijn diensten die bijvoorbeeld een api aanbieden om aangemaakte certificaten te doorzoeken. Een aanvaller zou hiervan gebruik kunnen maken om de hostnamen van Fitzbox-routers te achterhalen, stelt hij. Als er dan een kwetsbaarheid in bijvoorbeeld de webinterface wordt gevonden, lopen de routers daardoor een risico.

Fabrikant AVM zegt tegen de site dat 'veiligheidsmodellen verder moeten gaan dan het verstoppen van apparaten'. Bovendien zouden de https-poorten willekeurig worden toegewezen, wat volgens Böck een aanval echter alleen maar met enkele minuten vertraagt. De onderzoeker stelt dat het desalniettemin een goed idee van de fabrikant is om het automatisch aanmaken van een certificaat mogelijk te maken. Hij suggereert dat wellicht een waarschuwing voor gebruikers op zijn plaats is dat gebruik van de functie de hostnaam prijsgeeft.

De functie voor het aanmaken van Let's Encrypt-certificaten is te vinden in de nieuwste bètafirmware voor de Fritzbox 7490, zo kondigde de fabrikant deze week aan. Gebruikers kunnen na het aanmaken van een certificaat hun router via de MyFritz-dienst over een beveiligde verbinding benaderen.

Reacties (62)

Een hostname is niet onveilig per sé.

Het probleem waarop gedoeld wordt is het volgende:

Zonder deze informatie moet een aanvaller scannen op ip-adressen. Dat loopt in de gaten. Een ISP kan dat detecteren en blokkeren. Als je dat wil vermijden, kost dat (veel) tijd en moeite. Als het scannen dan toch gelukt is, is een klein percentage nieuw, en daarvan weer een percentage is kwetsbaar: een groot percentage bij ISPs die Fritzboxen uitdelen, een klein percentage bij andere ISPs (als mensen zelf zo'n ding kopen) Veel moeite dus om een mogelijk doelwit te vinden.

Met deze Fritzbox feature maakt een nieuw-geïnstalleerde Fritzbox zichzelf bekend, en hoeft de aanvaller dus helemaal geen moeite te doen om een mogelijk doelwit te vinden. Hij weet precies welk IP adres zijn nieuwe doelwit heeft, én hij weet dat het een Fritzbox is (en dus welke beveiligingsproblemen er in zitten). En als er een nieuw beveiligingsprobleem van de Fritzbox opduikt, is door deze feature zeer kort daarna een massale gerichte aanval op alle Fritzboxen mogelijk.

Op beide manieren ben je kwetsbaar, en op beide manieren kun je aangevallen worden, echter we weten allemaal dat als de moeite voor een aanval afneemt, dat de kans op zo'n aanval toeneemt. En dat is hiermee het probleem.

Dank voor de uitleg, ik dacht dat eerst dat het ging om de interne hostname ( welke al default fritz.box is )

Maar nou jouw uitleg, even "certificate transparency-systemen" opzocht, wat het eigelijk is.
En openbaar te raad plege "database" van alle uitgegevens SSL certificaten van let's encrypt.

Opzich zou dit juist een beveiligings maatregel moeten zijn.

Maar dan is dit niet alleen een risico voor de Fritzbox, maar voor elk systeem wat o.a. let's encrypt gebruikt, maar eigelijk niet openbaar wilt verkondigen.

Security through obscurity dus, en dat is nu onderhand wel achterhaald.

Security through obscurity is een goede extra beveiliginslaag. Het is alleen nooit iets waar je op moet vertrouwen als enige beveiliging.

Wat niet achterhaald is, is dat als bepaalde informatie niet (makkelijk) beschikbaar is voor een aanvaller, en die dus meer moeite moet doen, de kans op een aanval afneemt, omdat die meer tijd kost, en ook omdat de aanvaller wellicht (eerst) een makkelijker doelwit kiest.

Je moet voor veiligheid niet afhankelijk zijn van obscurity (behalve als je kunt garanderen dat ze bepaalde informatie niet kúnnen krijgen, zoals een wachtwoord), maar je kunt de kans op een (succesvolle) aanval wel verminderen met zorgvuldig gekozen obscurity.

Aha, is dat de klacht... Dat maakt t een iets ander verhaal.
Dus als ze naam.myfritz.net laten resolven naar een eigen IP en dan hun machine als reverse-proxy laten fungeren naar het werkelijke IP waar het modem op te vinden is dan is de klacht hier opgelost?

Dan kan LetsEncrypt gewoon werken, het IP-adres wordt niet bekend gemaakt want je komt via myfritz.net louter uit bij een IP van het bedrijf ipv op het modem in huis.

[Reactie gewijzigd door WhatsappHack op 16 december 2017 00:36]

Hoe kan 'hij' weten dat de fritzbox een nieuw IP heeft? Hostnames op internet resolven toch niet.. Daar hebben we domain names voor.

Te weten komen dat iets een fritzbox is, is ook noet erg moeilijk he. Zo'n ding spuigt html uit om in te loggen. Ik gok dat wel ergens op die pagina (in titel, of image desnoods) fritzbox staat of zelf een modelnummer.

Hoe kan 'hij' weten dat de fritzbox een nieuw IP heeft

Het gaat niet om de IP, maar om het feit dat bekend is dat er een (nieuwe) host is, met host/domeinnaam naam.myfritz.net, en dat dat (dus) een Fritzbox is. Die kennis kan gebruikt worden om een aanval te vergemakklijken.

Anders moet de aanvaller die informatie op een andere, moeilijkere en tijdrovendere manier achterhalen.

Hostnames op internet resolven toch niet.. Daar hebben we domain names voor.

Een volledige domeinnaam die toegekend is aan een host, heet óók 'hostnaam'. Het is de naam (in DNS) van die host. Bijv. 'mijnpc.ik.nl'. In dit voorbeeld is 'ik.nl' een domeinnaam die (vermoedelijk) geen hostnaam is. 'mijnpc.ik.nl' is een hostnaam.

Te weten komen dat iets een fritzbox is, is ook noet erg moeilijk he. Zo'n ding spuigt html uit om in te loggen. Ik gok dat wel ergens op die pagina (in titel, of image desnoods) fritzbox staat of zelf een modelnummer

Ik hoop het niet. Een van de basisprincipes van beveiliging is om je aanvallers zo min mogelijk informatie te geven (*). Hoe minder informatie (zoals type apparaat, firmware versie, IP-adres (of DNS-naam, wat op hetzelfde neerkomt) etc.), hoe moeilijker of tijdrovender een aanval wordt, en hoe kleiner dus de kans dat het gebeurt en succesvol is.

(*) je moet er alleen niet van afhankelijk zijn dat ze die informatie niet hebben, tenzij je kunt garanderen dat ze die informatie niet kúnnen krijgen.

[Reactie gewijzigd door RJG-223 op 15 december 2017 20:48]

En als er een nieuw beveiligingsprobleem van de Fritzbox opduikt, is door deze feature zeer kort daarna een massale gerichte aanval op alle Fritzboxen mogelijk.

Daar is deze feature helemaal niet voor nodig, en je hoeft ook geen ranges te scannen, dat hebben anderen al voor je gedaan. https://www.shodan.io/search?query=fritz

Dit! Met shodan kun je wereldwijd zo’n beetje iedere poort opzoeken als je weet waar je naar moet zoeken. Open rdp sessies zie je er ook gewoon tussenstaan met screenshot en al.

Inderdaad, mijn fritz staat er gewoon tussen. Die is herkend via het SIP protocol.

Waarom scannen op IP-reeksen, als ik dit gewoon in Shodan op kan zoeken?

Wauw, a storm in a teacup... Security by obsecurity is geen security... Terechte reactie van AVM hier.

Waar slaat dat op?

Security by obscurity

Neen, want dat is geen security by obscurity. Security by obscurity zou zijn dat je niet de salted hash van mijn wachtwoord zou mogen weten of dat je niet zou mogen weten hoe het hashing algoritme werkt.

Toch vind ik het altijd een interessante opmerking. (Je komt hem wel vaker tegen ) Immers “obscure” je in principe wel degelijk het wachtwoord door deze niet bekend te maken aan iemand, net als dat je broncode niet openbaar maken “obscurity” is.

En het klopt eigenlijk ook, want als iemand je wachtwoord achterhaalt (obscurity failure) biedt het geen enkele beveiliging meer. Ook niet als het gehashed is. Hashing is dan ook een vorm van obscurity - althans: zo zou je het kunnen zien.

Security by obscurity correct toegepast kan wel degelijk van toegevoegde waarde zijn voor je beveiliging; voornamelijk door het complexer te maken om de werkbare variant te zien. (Plain-text password VS obscured via een salted hash) Die hash hou je ook zo goed mogelijk geheim voor nog betere beveiliging overigens, immers heb je zonder hash niets om mee te werken terwijl mét hash je een uitgangspunt hebt waaraan je kan controleren of je het goed geraden hebt.

Ik denk dat je als voorbeeld eigenlijk beter je public key kan noemen. Je bent dan niet afhankelijk van de beveiliging/obscurity van die key om je data privé te houden. Dan krijg je ook meer te maken met secrecy (private key geheimhouden) dan obscurity. Al lijkt het veel op elkaar en zou je het geheimhouden van je wachtwoord natuurlijk ook gewoon onder secrecy kunnen gooien... Waar het thuishoort.

Het probleem is dat als je er te lang over gaat denken haast alle beveiliging “obscurity” is, maar toch is het niet zo. Wel is het een logische verwarring die erg vaak voorkomt. Maar goed, "security by obscurity" slaat dan natuurlijk eigenlijk ook voornamelijk op het niet openbaren van het design/methode van beveiligen in de hoop dat men dan moeilijker of geen gaten weet te vinden (eg: je vertelt niet hoe je encryptie werkt in de hoop dat men dan geen gaten in je crypto of diens implementatie kan vinden) dan het geheimhouden van zaken omdat je die gewoon geheim behoort te houden (secrecy). Voor het inzetten van security by obscurity om het moeilijker te maken om een probleem te vinden valt heel veel te zeggen overigens afhankelijk van de situatie, ik denk niet dat iemand ooit heeft gezegd "security by obscurity is no security so you should never obscure anything" Althans, niet in een universeel toepasbare context.

[Reactie gewijzigd door WhatsappHack op 16 december 2017 01:00]

Ik snap niet dat je gedown-vote wordt, want letterlijk elke bit informatie die je prijsgeeft gaat ten koste van je veiligheid. Security bestaat (deels) door obscurity. Of gaat iedereen een hint naar zijn password geven omdat obscurity toch valse veiligheid is?

Alleen al weten aan welke regels een wachtwoord moet voldoen(een hele domme is geen 2 dezelfde opvolgende karakters) beperkt je lijst met mogelijke wachtwoorden enorm. Of weten of alle 4 karaktertypes(nummers/letters/uppercase letters/speciale tekens)vereist zijn maakt het voor en aanvaller veel makkelijker.

Obscurity vereist dat de aanvaller zijn hele toolbox gebruikt(inclusief gokken wat voor systeem hij aanvalt) in plaats van een zeer beperkte scope.

Er is een reden dat aangeven of username OF password niet correct is een basic security failure is. Dat is ook obscurity IMHO. Inloggen mislukt is meer dan genoeg info(en eigenlijk al teveel).

[Reactie gewijzigd door MN-Power op 16 december 2017 03:13]

Ik kan geen inlogprocedure bedenken die niet uiteindelijk is gebaseerd op obscurity. Of het nu een wachtwoord is, of een certificaat of een gecompliceerde key exchange procedure. Het is allemaal gebaseerd op het feit dat de data die je nodig hebt om je te authenticeren onbekend is.

Slaat nergens op.

Nee, alle karakters behalve de laatste

Oftewel, ik snap wel wat je bedoelt. Elk stukje informatie wat wel bekend is maakt het pakket aanvalstechnieken wat de aanvaller hoeft te proberen kleiner.

Elk stukje meer obscurity zorgt ervoor dat de aanvaller steeds meer van zijn hele pakket aan aanvals-taktieken moet gebruiken ipv. (bijv) de exploits voor Fritzbox versie X.Y.Z met certificaten van Letsencrypt(aangevraagd door Pietje in Alkmaar). Als je weet wie je aanvalt ben je al een heel stuk verder omn binnen te komen bijvoorbeeld.

Ik vind security by obscurity best een dooddoener dus inderdaad.

Als bedrijf wil je bijvoorbeeld liever niet dat je fysieke servernamen buiten de organisatie bekend zijn. Dat kan je obscurity noemen, ik noem het informatiebeveiliging.

[Reactie gewijzigd door MN-Power op 16 december 2017 02:04]

Je snapt het zelf niet door bewust het woord "enkel" te gebruiken. Security by obscurity is zeker van toegevoegde waarde als aanvullende security laag zoals velen hierboven al roepen.

Dit komt ook buiten de IT in grote schaal voor.

Oke, kun je dan rendabele voorbeelden noemen binnen IT ipv alleen mijn post zelf aan te vallen? Dit hele “je hebt geen gelijk omdat je het fout hebt” is schattig, maar zegt eigenlijk helemaal niets.

“Security through obscurity is no security” slaat op het *uitsluitend* leunen op obscurity om iets “veilig” te maken. En dat klopt, dat is ook niet handig en biedt je geen enkele garantie. Het KAN je wel veilig houden overigens, maar dat is dan mazzel hebben. Voor kritieke zaken kan je er dus niet uitsluitend op leunen dat het je veilig gaat houden.

Maar dat wil niet zeggen dat obscurity helemaal geen doel heeft. Een heel simpel voorbeeld is dat het bijvoorbeeld aangeraden wordt om de softwareversie te verhullen om het moeilijker te maken voor aanvallers om vulnerable machines/sites te vinden. Immers, als je enkel “Powered by Apache HTTPD” krijgt in plaats van “Powered by Apache HTTPD 2.0.1” (om maar iets te noemen) dan vind je tig servers die Apache draaien maar weet je niet welke van die servers vulnerable is omdat het een lekke versie draait. Dat moet je dan gaan testen per server en dat kost veel meer tijd en maakt t lastiger om op heel simpele wijze snel een lijst te compileren van alle kwetsbare servers en loop je meer risico gesnapt te worden als aanvaller en op een zwarte lijst te belanden. (Of omdat ze niet weten welke versie je hebt moeten ze meerdere exploits testen, wat je firewall meer kand geeft om er actie op te ondernemen of iemand die de logs bekijkt een alarmbelletje kan doen laten rinkelen voor het te laat is Al blijf t uitgangspunt: installeer patches snel!!) Plus door het op die wijze vertragen van aanvallers heb je meer kans als server administrator om een patch te installeren voordat je genaaid wordt. (Geen garantie trouwens he, maar het kán flink helpen Als je toevallig dé target bent of de eerste die getest wordt en je hebt niet gepatched ben je alsnog de sjaak.) Het geeft je dus vaak extra tijd, en tijd is cruciaal! Of als Wordpress 4.0.2 een lek heeft dat gepatched is in 4.0.3 maar je kan als aanvaller enkel “Powered by Wordpress” zien (of zelfs dat niet ), dan moet je dus nog eens al die sites gaan testen of ze werkelijk 4.0.2 draaien of niet. Dat biedt geen security, maar het helpt wel enorm om de boel te vertragen en het moeilijker te maken voor aanvallers om kwetsbare software te vinden puur door de versie uit te lezen... Je bent dus nog steeds kwetsbaar als je die oude versie draait, maar omdat het lastiger is om jou te vinden of te achterhalen welke versie je draait (en dus welke kwetsbaarheid/kwetsbaarheden er zijn op je server/site) draagt het wel bij aan je veiligheid - of kan het tenminste een positieve bijdrage leveren aan de periode dat je niet gehackt wordt.

En zo heeft obscurity wel degelijk een doel. Een betere verwoorden is dan ook “Obscurity on its own is no security”, want dat wil niet zeggen dat het helemaal geen bijdrage kan leveren aan je veiligheid; terwijl “security through obscurity is no security” vaak wél op die manier wordt geïnterpreteerd door mensen die die zin voorbij zien komen. Obscurity kan bijdragen aan je veiligheid/je meer tijd geven problemen op te lossen - maar geheel op zichzelf biedt het geen beveiliging en is t een tikkende tijdbom.
Overigens kan obscurity uiteraard ook averechts werken, omdat zonder obscurity een lek misschien wel (sneller) was gevonden en gepatched voor het misbruikt werd door een black hat; dat is dus afhankelijk van de context. En helemaal geen obscurity kan er juist ook weer voor zorgen dat een lek sneller misbruikt wordt door kwaadwillenden omdat ze het wat makkelijker konden vinden. Dat is ook het eindeloze debat dat je ziet in Opensource vs Closedsource discussies.

Beveiliging is nou eenmaal een erg complex onderwerp waar je afwegingen en compromissen moet sluiten - en obscurity kan derhalve zeker een positieve rol spelen in je veiligheidsmodel mits goed en op de juiste plek toegepast.

[Reactie gewijzigd door WhatsappHack op 16 december 2017 18:37]

Zoals het "LAN" netwerk van Ziggo.

En wat is er onveilig aan het weten van een hostname? Je moet het IP toch al weten om het SSL certificaat te kunnen zien? En hostnames resolven toch niet op het internet als ze nergens in een DNS staan. Of geeft de hostname meer vrij, zoals het type apparaat? Maar dat kan toch ook gefingered worden op andere manieren? Erg onduidelijk artikel dit vind ik.

Zou het niet zo zijn om LetsEncrypt fatsoenlijk te kunnen laten werken, dat de hostname ook daadwerkelijk moet resolven?

Maar dat kan toch nooit op internet? Dat zou betekenen dat niemand ter wereld dezelfde na aan z'n router mag geven? Een hostname moet uniek zijn in z'n subnet. Lijkt me lastig op internet.

Het gaat om de externe naam. Dus stel je provider geeft jou abc123.client.provider.com (FQDN) dan is dat je hostname en die resolved (DNS) naar je fritzbox. De naam die je er intern aan geeft of met dyndns of een eigen domein of wat dan ook ook naar je IP laat linken moet je verder lekker zelf weten en ook daar kan je als je wil uiteraard een SSL certificaat op aanvragen; maar dat kan al jaaaaren. En ook dat kan je met LetsEncrypt automatiseren, totaal geen probleem. Niets nieuws qua mogelijkheden.

Die hostnames van je provider behoren uiteraard uniek te zijn, maar dat lijkt me logisch...

[Reactie gewijzigd door WhatsappHack op 15 december 2017 20:20]

Jij krijgt een +2, maar een hostname is totaal niet hetzelfde als een FQDN. Een hostname is onderdeel van een FQDN. In dit artikel wordt consistent hostname gebruikt, terwijl het over een FQDN gaat.
De FQDN die je van jouw ISP krijgt is dus uniek. De hostname van jouw fritzbox hoeft dat dus zeker niet te zijn.

Ten eerste, als je goed leest zie je dat ik ook niet zeg dat het altijd hetzelfde is; in dit geval zijn ze dat echter wel.
Ten tweede hoeft de hostname geen onderdeel te zijn van een FQDN dat naar het modem wijst - je lijkt jezelf een beetje tegen te spreken omdat je eerst zegt dat het er onderdeel van moet zijn en vervolgens zegt dat het niet hoeft. (Dat laatste klopt.)
Ten derde is een hostname dus helemaal niet perse één woord (bijnaam), maar mag de hostname ook een FQDN zijn. Het mag dus zowel één woord zijn als bijnaam die wel of niet verwerkt wordt in een FQDN, maar je kan een FQDN ook als hostname instellen. Als jij "car.hartt.guy" instelt als hostname, dan is dat je hostname. Stel je enkel "car" in, dan is dat je hostname. Maar als je de hostname instelt als "car.hartt.guy" kan je niet zomaar zeggen dat de hostname dan "car" is binnen het domein "hartt.guy" - zo werkt dat niet perse.

Dus nee, de hostname als in de bijnaam die je (intern) geeft aan je Fritzbox hoeft niet perse uniek te zijn; maar hij moet wel een uniek adres naar zich hebben verwijzen én daar op luisteren met de webserver om LetsEncrypt (of andere CA's, boeie) aan te kunnen - en over het algemeen zal dat z'n hostname zijn; ongeacht dat je er intern ook een labeltje aan kan plakken.
"abc123.client.provider.com" uit mijn voorbeeld HOEFT trouwens dus niet verplicht ook de hostname te zijn he! Dat heb ik nooit gezegd. Het kan overigens ook prima zijn dat Fritzbox geen hol geeft om wat de ISP instelt als (R)DNS maar dat ze op eigen servers (eg: myfritz.net) een A-entry aanmaken en de Fritzbox daarop gaat luisteren en zo LetsEncrypt laat functioneren. Dat klinkt echter ook niet helemaal failsafe, dus ik hoop dat ze gewoon met de ISP's samenwerken. Dat maakt het ook makkelijker te verhullen om welk merk/type apparaat het gaat - mochten daar toch nog zorgen om zijn.

[Reactie gewijzigd door WhatsappHack op 15 december 2017 22:57]

1. Een hostname is samen met de domainname de FQDN. Naar mijn weten heeft elke computer een hostname; de domain name kan onder andere worden meegeven d.m.v. een scope option in DHCP.
2. Carharrtguy heeft het daar naar mijn interpretatie over het feit dat de hostname niet uniek hoeft te zijn. Dat klopt want die mag je zelf bedenken.
3. Een hostname mag niet bestaan uit punten. In Windows kan je dat niet eens zo instellen. Wanneer je het wel doet, wordt je FQDN niet goed worden opgebouwd en dat levert mogelijke problemen op met DNS lookups.

Please correct me if i'm wrong, keep learning. :-)

1) Zoals gezegd kan de hostname ook een FQDN zijn. Dat dit wellicht in Windows niet mogelijk is of anders moet worden ingesteld is weer een ander verhaal; kijk eens naar hoe het op Linux werkt, dat biedt misschien een beter perspectief waar ik op doel. Ik heb dan ook gezegd dat een hostname zowel enkel een (bij)naam kan zijn alsmede een FQDN kan zijn Beide is mogelijk.

2) Maar ik heb ook niet gezegd dat die uniek MOET zijn. Ik heb gezegd dat er tenminste een uniek *adres* naar de Fritzbox moet pointen om DV uit te kunnen voeren - en dat kán de hostname (sprekend over FQDN variant) zijn. Maar ik merkte er ook bij op dat het ook elk willekeurig adres kan zijn zolang het maar resolved naar het IP van het modem én de Fritzbox weet dat ie daarnaar moet luisteren op de webserver. (In mijn voorbeeld was het een *.myfritz.net record) Dat kan los staan van de hostname uiteraard, FQDN-variant of niet. Immers kan een webserver luisteren naar wat ie wil, zolang t maar op enige wijze resolved. Trouwens, als ze het via *.myfritz.net reverse proxy’en naar het werkelijke IP van het modem ben je ook meteen van het discovery probleem af wat hier werd aangedragen.

3) Op Linux kan je een FQDN instellen als hostname, dan bevat het gewoon punten. Ook zonder kan het trouwens, als jij je bak Gideon.98 (geen FQDN, wel een punt) wil meegeven als hostname dan is dat in principe mogelijk. Dat zie je soms overigens voor interne namen ook gebeuren. (Eg: modem.lan)

[Reactie gewijzigd door WhatsappHack op 16 december 2017 00:33]

Check even de hostnames (FQDN) in het artikel/screenshot.

Ik zit op m'n mobiel en zie geen screenshot, ik kan geen Duits maar ik veronderstel ddoor jouw reactie dat fritzbox een soort van dynamische DNS hostname aan maakt? Dat is natuurlijk wel kwalijk. Raar dat Tweakers dit niet vermeld. Is cruciale info.

Het gaat om de bestaande dyn-dns dienst myfritz.net.

Die hostname wordt ook geresolved door de DNS proxy in de fritsbox. Als je dus een DNS A record hebt voor je WAN hostname dat moet dat werken.

Ik weet niet precies wat je bedoeld, maar voor de buitenwereld resolvet de DNS via myfritz.net.

Ik bedoel als je via je LAN je eigen domainname resolved dan kom je op je router LAN adres uit zodat het certificaat dan gewoon geldig is.

Ik ben het met je eens, je hebt uiteindelijk een hostname nodig om de host te bereiken.
Ping je op het WANadres, zal je imho ook dezelfde data verkrijgen, zo ook bij Ziggo.
Ik gebruik LetsEncrypt op verschillende apparaten, en allemaal hebben ze OF een domeinnaam, OF een ipadres in het certificaat zitten ( al dan niet dynamisch )

* ipadres inderdaad niet, maar een ping op het domein geeft deze wel weer terug

Een groot voorstander van privacy en bewust zijn van de data die je deelt, maar men kan het ook overdrijven.

[Reactie gewijzigd door FreshMaker op 15 december 2017 20:55]

Het probleem zit in dat je bij LetsEncrypt kunt zien welke hostnamen aan nieuwe certificaten hangen. Als er dus een lek bekend is in de de software van een router hoef je dus niet het hele internet af te zoeken maar kun je een lijst afwerken met hostnamen waarachter dus een fritzbox zit.

Ondanks dat je dan dus nog moet scannen op welke poort HTTP zit bij die hostnamen weet je wel relatief zeker dat er een fritzbox achter zit. Je kunt daarom een gerichte aanval doen op mensen met een fritzbox.

Dus is het des te belangrijker dat die Fritz figuur heel snel mogelijke problemen fixt. Dat de domeinnamen bekend zijn is dan een mooie stok achter de deur om dat ook gedaan te krijgen. Al met al is er niet zo heel veel aan de hand als Fritz zijn software op orde heeft.

De houding van AVM lijkt dan ook best wel goed te zijn hierin. Obscurity is geen oplossing. Aanpakken bij de wortel die hap.

Ik gebruik LetsEncrypt op verschillende apparaten, en allemaal hebben ze OF een domeinnaam, OF een ipadres in het certificaat zitten ( al dan niet dynamisch )

Een ip adres in een certificaat?
Zover ik weet kan dat niet.

Kan prima hoor, hoezo dacht je van niet: https://stackoverflow.com/a/1119269/1266242 . Geen flauw idee of Letsencrypt of andere certificaat autoriteiten ze uitgeven, maar heb ze wel eens lokaal aangemaakt.

Het is gewoon een kwestie van de optie Internet access to the FRITZ!Box via HTTPS enabled' uitzetten. In dit geval lijkt het me echt een een non-issue.

Wel zou het webinterface kunnen adviseren om de bovenstaande optie uit ze zetten als je certificaat installeerd.

Maar dan is de FRITZbox wel via HTTP te bereiken? Ergo jouw login op straat? Ik zie het voordeel daar echt niet van in.

nee, want dat zet de gehele webaccess uit

Nee de fritsbox luistert niet op poort 80. Je kan er alleen met https op.

Als je die https optie expliciet aanzet dan kan je wel vanaf je wan bij de fritsbox webinterface komen.

Als je echt optimistisch bent kan je ook nog de fritsbox ftp/ftps service openstellen via het WAN.

Is dit niet het artikel waar jullie op doelen?

Klopt, geen idee hoe die andere link daar kwam! Dank.

Op wat voor manier voegt het weten van een hostname extra onveiligheden toe? Een hostname is alleen maar een omzetting naar een IP adres en IP adressen zijn oplopend en voorspelbaar. Als je weet dat een ISP Fritzboxen aan z'n gebruikers geeft, kun je de hele range van zo'n ISP gewoon aflopen met een scanner.
Gedoe om niks dus.

Als dit een veiligheidslek zou zijn dan had ik de afgelopen jaren tienduizenden euro’s aan security bounties kunnen ophalen voor exact hetzelfde “probleem” in allerlei softwarepakketten.

Je kunt toch gewoon voor de fritzbox met open ssl een eigen certificaat voor je fritzbox aanmaken.
En dan ook nog je https poort wijzigen.
Dan is het toch ok, volgens mij?
Kun je gewoon een domein aanmaken die niet bestaat alleen die jij kent. via je ip kun je er dan wel komen.
Heb lang moeten zoeken hoe maar, zelfs bij fritzbox zelf gaven ze hierover geen antwoord.

[Reactie gewijzigd door wowi op 15 december 2017 20:44]

Waarom moeilijk doen en ze opzoeken in een certificaat database, en dus afhankelijk zijn van het feit of er een certificaat aangemaakt is, je kunt de Fritzboxen gewoon opzoeken in Shodan

Wat een ranzige FUD. Het maakt echt geen donder uit wat je hostnaam of WAN-IP is, dat spul hoort sowieso publiek te zijn. Of het daarnaast te relateren is met een adres is een ander verhaal wat hier ook buiten staat.

SSL zonder transparency is sowieso geen goed idee, dus dit niet-bestaande 'probleem' heb je altijd.

Weer een onzinnige 'onderzoeker' die met dit flutverhaal zijn 15-minutes of fame heeft gehaald, het weten van een hostnaam maakt werkelijk helemaal niets uit.