'Fouten in upnp-standaard maken netwerkapparatuur kwetsbaar'
Verschillende fouten in de upnp-standaard hebben tot gevolg dat 'tientallen miljoenen' computers kwetsbaar zijn voor aanvallen van buitenaf. Dat beweert de gerenommeerde beveiligingsonderzoeker HD Moore. Details ontbreken vooralsnog.
Later op dinsdag zal het beveiligingsbedrijf van Moore, Rapid7, een rapport vrijgeven van het onderzoek naar beveiligingsproblemen in de upnp-standaard. Reuters kreeg het rapport echter al voor publicatie te zien. Upnp, voluit universal plug and play, maakt het mogelijk om over udp automatisch andere upnp-apparaten op een netwerk te ontdekken.
Er zouden drie verschillende soorten problemen in de upnp-standaard zitten, die tot gevolg hebben dat wereldwijd '40 miljoen tot 50 miljoen apparaten' kwetsbaar zijn. Het gaat om netwerkapparatuur van een groot aantal fabrikanten, waaronder Belkin, D-Link, Linksys en Netgear. De kwetsbaarheden zouden hackers in staat stellen om toegang te krijgen tot pc's, webcams en printers. Ook het stelen van wachtwoorden zou tot de mogelijkheden behoren.
Details van de beveiligingsproblemen ontbreken nog. Moore, die ook achter het penetratietestingframework Metasploit zit, verwacht dat de ict-beveiligingsorganisatie van de Amerikaanse overheid dinsdag met een waarschuwing voor het beveiligingsprobleem komt. Hij vreest dat fabrikanten de beveiligingsproblemen niet snel zullen dichten, terwijl kwaadwillenden volgens hem snel op de beveiligingsproblemen zullen duiken. Dat weerhoudt hem er niet van om de problemen naar buiten te brengen, naar eigen zeggen om fabrikanten te dwingen meer aandacht voor beveiliging te hebben.
"Je kunt hier niet stil over blijven", aldus Moore tegenover Reuters. "De beveiliging van deze apparaten is in de kern al decennia dezelfde. Niemand geeft er echt om." Zijn beveiligingsbedrijf komt met een gratis tool om kwetsbare apparatuur in kaart te brengen; vervolgens kan upnp op die apparaten worden uitgeschakeld als er geen update beschikbaar is.
Reacties (68)
Dit is toch al sinds 2001 bekend? Of tenminste bij de Microsoft-implementatie van UPnP. Bruce Schneier heeft er nog een mooie samenvatting over geschreven. Er waren niet voor niets tools zoals 'Unplug and Pray'.
Zonder UPnP werken ladingen essentiele netwerk services niet meer, dus dat lijkt me het kind met het badwater weggooien. Als er iets mis is met het protocol, zal je het moeten fixen.
[Reactie gewijzigd door Dreamvoid op dinsdag 29 januari 2013 13:52]
Wat een onzin. Sinds ik van het bestaan van uPnP weet, zet ik het altijd uit. En alles werkt gewoon bij mij.
Veel plezier dan om DNLA werkend te krijgen.
DLNA (correct geschreven) is een erg brak protocol, onder andere vanuit een veiligheidsperspectief. De gebruiksvriendelijkheid is ook ver te zoeken, aangezien veel apparatuur het net even anders implementeert.Veel plezier dan om DNLA werkend te krijgen.
Nee, dank je. Het heeft misschien iets zwaardere eisen aan de hardware, maar een ouderwetse SMB/CIFS share werkt gewoon veel beter. Alles speelt af alsof het lokaal wordt ingeladen en je hoeft je geen zorgen te maken over bepaalde formaten die wel of niet over DLNA gedeeld kunnen worden.
[edit]
Voor de *NIX-achtige helden onder ons: ja, NFS is ook bruikbaar en neemt wat van de overhead van SMB/CIFS weg.
[Reactie gewijzigd door The Zep Man op dinsdag 29 januari 2013 14:09]
Onzin, DLNA is RTSP-based en daarom zeer veel efficienter dan SMB/CIFS. Ook voorziet DLNA in het uitwisselen van ondersteunde formaten zodat content servers automatisch kunnen transcoderen naar een formaat dat de client begrijpt. Dit in tegenstelling met SMB/NFS waarbij de client het bestand kunnen afspelen anders werkt het gewoon niet.
Daarbij komt dat via DLNA het mogelijk maakt je media apparatuur op afstand te bedienen.
Als protocol is DLNA gewoon zeer goed. De implementatie van DLNA in de PS3 en Windows Media Player zijn gewoon slecht want die ondersteunen de gangbare formaten niet, maar dat ligt dus niet aan het protocol.
Daarbij komt dat via DLNA het mogelijk maakt je media apparatuur op afstand te bedienen.
Als protocol is DLNA gewoon zeer goed. De implementatie van DLNA in de PS3 en Windows Media Player zijn gewoon slecht want die ondersteunen de gangbare formaten niet, maar dat ligt dus niet aan het protocol.
Mijn media apparatuur heeft als doel media afspelen. Daar hoeft mijn server/storage niets mee te doen. Gescheiden taken maakt het geheel flexibeler en kost minder CPU cycles.Onzin, DLNA is RTSP-based en daarom zeer veel efficienter dan SMB/CIFS. Ook voorziet DLNA in het uitwisselen van ondersteunde formaten zodat content servers automatisch kunnen transcoderen naar een formaat dat de client begrijpt. Dit in tegenstelling met SMB/NFS waarbij de client het bestand kunnen afspelen anders werkt het gewoon niet.
Daarvoor heb ik een afstandsbediening. Of plugins dat je een smartphone/tablet kan gebruiken zonder DLNA met beter werkende integratieDaarbij komt dat via DLNA het mogelijk maakt je media apparatuur op afstand te bedienen.
Als implementaties brak zijn, dan is het protocol in zijn huidige bestaansvorm ook brak.Als protocol is DLNA gewoon zeer goed. De implementatie van DLNA in de PS3 en Windows is gewoon slecht want die ondersteunen de gangbare formaten niet, maar dat ligt dus niet aan het protocol.
Dat je een PS3 gebruikt om media te spelen is leuk, maar investeer ietsje meer en je hebt gewoon een apparaat dat alles afspeelt en minder vraagt van je storage. Afspelen van mediameuk behoort aan een client toe en transcoden is nutteloos (en verspilling).
Ook zorgt SMB ervoor dat de client zelf kan bepalen welke bestanden wel en niet nodig zijn om af te spelen. Altijd handig, met extra ondertiteling, artwork of andere zaken die men er soms bij wilt hebben, maar niet wilt laten transcoden door de server om de missende functionaliteit van een brakke media player te omzeilen.
[Reactie gewijzigd door The Zep Man op dinsdag 29 januari 2013 14:30]
Dat kan je wel volhouden, maar in de praktijk zijn DLNA, Xboxen, PS3's en AirPlay razend populair, terwijl bijna niemand complexe en dure 'fat client' HTPC's via SMB wil werken.
Je hebt geen HTPC nodig om via SMB shares af te spelen? Heb hier een WDTV Live uit 2009 (toendertijd +\- 80 euro) die gewoon prima alles afspeelt vanaf SMB shares. Vervolgens boven een oude laptop die in de weg lag met XBMC erop bedienen via mijn mobiel en gaan. Ik snap echt niet waarom mensen zitten te prutsen met DLNA.
In theorie een goed verhaal. De praktijk is helaas gewoon huilen met de pet op. KISS -> CIFS/NFS
huh, de imlementatie van dlna heeft niets te maken met welke formaten de platformen ondersteunen, als je denkt van wel dan moet je misschien toch maar even beter verdiepen in het protocol (als je uberhaupt de specs kunt vinden).
Om DLNA werkend te krijgen tussen bijvoorbeeld je telefoon, TV en PC heb je geen UPnP in je router nodig.
Nee want Microsoft brengt echt nooit, maar dan ook nooit security fixes naar buiten! Verder bestaat deze website niet http://technet.microsoft.com/en-us/security/bulletin is er niet zoiets als Windows Update en is MS gewoon het gemeenste software bedrijf dat er is!
@Jeoh : Precies mijn mening. Er wordt al jaren geroepen dat je UPNP het beste kunt uitschakelen in je router indien je dit niet persé nodig hebt.
Dit zijn waarschijnlijk nieuwe bugs in het genoemde artikel staat dat het al gepatched was in 2 maanden. Echter wat hierbij nooit vermeld word is dat kwaadwillende gebruikers of programma's al binnen het interne netwerk toegang moeten hebben. UPnP gaat niet over internet en is daar ook niet voor ontworpen. Het is puur voor lokale netwerken.
Het gaat hier met name om routers/gateways waarschijnlijk. zo'n beetje de eerste toepassing voor upnp voor autmatische port forwarding. initieel was hier geen authenticatie bij dat is later toegevoegd en vermoedelijk zit daar het lek in of mogelijk staat netwerkapparatuur ook de oude methode nog altijd toe vanwege compatibiliteit, waardoor de hele authenticatie zinloos is.
Het gaat hier met name om routers/gateways waarschijnlijk. zo'n beetje de eerste toepassing voor upnp voor autmatische port forwarding. initieel was hier geen authenticatie bij dat is later toegevoegd en vermoedelijk zit daar het lek in of mogelijk staat netwerkapparatuur ook de oude methode nog altijd toe vanwege compatibiliteit, waardoor de hele authenticatie zinloos is.
Nou ja, het zou best kunnen dat je dmv wat IP spoofing ook vanaf het internet UPnP pakketjes kan sturen.
Nee want het zijn fysiek gescheiden interfaces. Een router/modem/gateway/acces point hebben altijd een WAN en een LAN interface welke fysiek andere connectors hebben. Een modem gebruikt ook geen ethernet als wan connector. Ik heb nog nooit dergeleijke apparaten gezien waar dit gekoppeld is en dat zou ook voor een fabrikant geen voordeel bieden. Deze apparaten zijn juist de hele scheidslijn van de 2 werelden en zijn ervoor gemaakt om hier een stricte en gestructureerde brug tussen te maken.
Met IP spoofing komt het pakketje nog altijd op de wan interface binnen. Overigens heb je niks aan IP spoofing want na het ontdekken moet je een complete tcp verbinding maken waarover http en soap word gebruikt. udp kan wel maar daarmee kun je alleen ontdekken dat er een upnp apparaat is. AUthenticatie gaat middels SOAP. En zoals ik al zei Upnp zal nooit op de internet kant aangezet worden en zelfs als een gestoorde fabrikant dit toch doet is het simpelweg niet bruikbaar omdat multicast daar niet werkt en omdat de pakketjes een TTL van 2 hebben dus niet eens buiten de provider komen.
Update:
Het gevaar zit eerder misschien in websites met client code (javascript?) die van binnenuit een connectie maken naar een gateway en hier vervolgens poorten openzetten om van alles binnen te halen. Maar ik heb geen idee of je netwerkverkeer kan opzetten middels client side website code. Dat lijkt me namelijk sowieso al erg gevaarlijk. Er is vast iemand die dit kan toelichten.
Met IP spoofing komt het pakketje nog altijd op de wan interface binnen. Overigens heb je niks aan IP spoofing want na het ontdekken moet je een complete tcp verbinding maken waarover http en soap word gebruikt. udp kan wel maar daarmee kun je alleen ontdekken dat er een upnp apparaat is. AUthenticatie gaat middels SOAP. En zoals ik al zei Upnp zal nooit op de internet kant aangezet worden en zelfs als een gestoorde fabrikant dit toch doet is het simpelweg niet bruikbaar omdat multicast daar niet werkt en omdat de pakketjes een TTL van 2 hebben dus niet eens buiten de provider komen.
Update:
Het gevaar zit eerder misschien in websites met client code (javascript?) die van binnenuit een connectie maken naar een gateway en hier vervolgens poorten openzetten om van alles binnen te halen. Maar ik heb geen idee of je netwerkverkeer kan opzetten middels client side website code. Dat lijkt me namelijk sowieso al erg gevaarlijk. Er is vast iemand die dit kan toelichten.
[Reactie gewijzigd door Vastloper op dinsdag 29 januari 2013 14:14]
Met een beetje googlen had ik direct de eerste hit te pakken: "hoe de status inside/outside van je interfaces te veranderen". Bij een of andere (home-)router vendor.
Ik wed dat er wel veel meer vendors zijn die of uPnP op hun outside interfaces toelaten. Of toelaten de status van het interface te veranderen. "Handig !". Het veranderen van de status is nog veel gevaarlijker, omdat dan uPnP een side-effect is waar je je misschien niet direct bewust van bent.
Ik heb een Fritzbox thuis. Die doet uPnP-NAT. Als ik het aanzet, vraagt de router niet om een password. Met andere woorden: non-authenticated uPnP-NAT. Op een router van een respectabele vendor.
WLAN is ook "inside". Een foutje met je WLAN security, en opeens kunnen al je buren je devices configureren. Fijn. Geef mijn maar dubbele security. Of driedubbele.
Pakketjes hebben een TTL van 2 ?
Hahahaha. Wat een blunder in protocol design.
Als ik 10 hops ver weg zit, dan stuur ik een pakketje met TTL=12. Als het aankomt bij de router, heeft het precies een TTL van 2. Lekkere security.
Als je TTLs wilt gebruiken in security, dan moet je het precies andersom doen. Verplicht alle zenders de TTL op 255 te zetten. En dan check dat de TTL ook inderdaad 255 is bij aankomst.
Ik wed dat er wel veel meer vendors zijn die of uPnP op hun outside interfaces toelaten. Of toelaten de status van het interface te veranderen. "Handig !". Het veranderen van de status is nog veel gevaarlijker, omdat dan uPnP een side-effect is waar je je misschien niet direct bewust van bent.
Ik heb een Fritzbox thuis. Die doet uPnP-NAT. Als ik het aanzet, vraagt de router niet om een password. Met andere woorden: non-authenticated uPnP-NAT. Op een router van een respectabele vendor.
WLAN is ook "inside". Een foutje met je WLAN security, en opeens kunnen al je buren je devices configureren. Fijn. Geef mijn maar dubbele security. Of driedubbele.
Pakketjes hebben een TTL van 2 ?
Hahahaha. Wat een blunder in protocol design.
Als ik 10 hops ver weg zit, dan stuur ik een pakketje met TTL=12. Als het aankomt bij de router, heeft het precies een TTL van 2. Lekkere security.
Als je TTLs wilt gebruiken in security, dan moet je het precies andersom doen. Verplicht alle zenders de TTL op 255 te zetten. En dan check dat de TTL ook inderdaad 255 is bij aankomst.
Ik mag aannemen dat status veranderen van wan en lan interfaces alleen via de eigen configuratie interface kan die standaard normaal alleen op het lan beschikbaar is of op zijn minst met een instelbaar wachtwoord is beveiligd.
De TTL van 2 word ingesteld bij versturen vanaf het device, dus geen check bij aankomst. Dat houd dus in dat de pakketjes nooit iemand bereiken op internet. DIt zijn uitgaande pakketjes dus voor de duidelijkheid. Dat is wat je nodig hebt om te achterhalen hoe je het device kan benaderen. Zelfs als je het device weet enhet ip heb je alsnog een uuid nodig die je vanaf internet dus niet zomaar kan achterhalen. Het ip spoofen kan je alleen enigszins met udp, udp word alleen gebruikt om de apparaten te vinden en te achterhalen hoe ze benadert kunnen worden. Ofterwijl zelfs voor het ssdp(discovery) deel heb je niks aan ip spoofen vanwege de TTL. Dit is geen feature bedoelt als security, maar maakt het misbruik wel moelijker net als het aangegeven multicast probleem
De TTL van 2 word ingesteld bij versturen vanaf het device, dus geen check bij aankomst. Dat houd dus in dat de pakketjes nooit iemand bereiken op internet. DIt zijn uitgaande pakketjes dus voor de duidelijkheid. Dat is wat je nodig hebt om te achterhalen hoe je het device kan benaderen. Zelfs als je het device weet enhet ip heb je alsnog een uuid nodig die je vanaf internet dus niet zomaar kan achterhalen. Het ip spoofen kan je alleen enigszins met udp, udp word alleen gebruikt om de apparaten te vinden en te achterhalen hoe ze benadert kunnen worden. Ofterwijl zelfs voor het ssdp(discovery) deel heb je niks aan ip spoofen vanwege de TTL. Dit is geen feature bedoelt als security, maar maakt het misbruik wel moelijker net als het aangegeven multicast probleem
Ik zou hier heel graag een goed uitgewerkte case van willen zien door Tweakers. (Zodra de informatie beschikbaar is).
Inderdaad! UPNP zit in zo goed als elke router en staat bijna altijd aan (het is ook wel verrekte handig), ik zou hier ook wel meer over willen weten. Wie loopt er gevaar? Consumenten? Bedrijfsleven? Beide? Wat voor risico's hebben we het over? Etc.
Iedereen met een CPE van z'n provider loopt risico, behalve de mensen die een Fritz!Box hebben dacht ik, om dat die een andere upnp daemon gebruiken.
Het eerste wat ik doe als ik een nieuwe router krijg, nieuwe firmware installeer, of de config reset: uPnP uitzetten.
Wie ooit heeft verzonnen dat het ok is om de configuratie van network- en security devices te laten veranderen, van buiten-af, geautomatiseerd, zonder authenticatie, daar is een speciaal plekje voor gereserveerd in de hel.
Wie ooit heeft verzonnen dat het ok is om de configuratie van network- en security devices te laten veranderen, van buiten-af, geautomatiseerd, zonder authenticatie, daar is een speciaal plekje voor gereserveerd in de hel.
Of een speciale plekje bij de NSA/CIA/FBI/etc 
Het is niet iets wat je wil op een gedeeld netwerk, maar wanneer je de enige gebruiker bent van je privénetwerk, waarom dan moeilijk doen met forwardregels e.d.? Vind er zelf weinig aan om iedere keer de ports voor bittorrent, remote desktop, etc. opnieuw te moeten instellen.
Beetje jammer alleen dat het nu een veiligheidsrisico vormt.
Beetje jammer alleen dat het nu een veiligheidsrisico vormt.
Omdat wanneer je een intrusion hebt gehad, en je denkt dat het herinstalleren van software op je PCs je een nieuwe veilige situatie geeft, je niet wilt dat je router/NAT/firewall open staat voor nieuwe aanvallen via andere ports/services.waarom dan moeilijk doen met forwardregels e.d.?
[Reactie gewijzigd door gryz op dinsdag 29 januari 2013 16:00]
True, het zou alleen fijn zijn als software een melding geeft als poorten dicht staan die ze nodig hebben om bijvoorbeeld te updaten
*kijkt met een oog naar blizzard*
*kijkt met een oog naar blizzard*
Blizzard heeft wel de meest foute adviezen wat dat betreft.
Als je problemen had met je download tool gingen ze doodleuk verkondingen: Zet je firewall en virusscanner uit.
Ja.. Lekker
Als je problemen had met je download tool gingen ze doodleuk verkondingen: Zet je firewall en virusscanner uit.
Ja.. Lekker
Gelukkig heeft niemand dat dan ook verzonnen. De UPNP standaard is niet ontworpen om van buitenaf configuraties te laten veranderen. Dat kan alleen van binnen.Wie ooit heeft verzonnen dat het ok is om de configuratie van network- en security devices te laten veranderen, van buiten-af, geautomatiseerd, zonder authenticatie, daar is een speciaal plekje voor gereserveerd in de hel.
Als malware eenmaal op je interne netwerk zit maakt het wel of niet gebruiken van UPNP niet uit. Mensen hebben meestal een firewall die alleen verkeer van buiten tegen houdt of, nog erger, alleen NAT. NAT staat sowieso altijd wagenwijd open van binnen naar buiten.
Kortom, er is geen enkele reden voor malware om UPNP te gebruiken, als de UPNP implementatie netjes volgens de standaard werk levert het uitschakelen dus ook geen extra veiligheid op.
Dit nieuws, waarvan we de details dus nog moeten horen, gaat niet over een probleem met de UPNP standaard, het gaat over brakke implementaties. Brakke/onveilige implementaties komen ook voor in Firewalls, Routers, NAT etc. Zouden we die dan ook maar niet moeten gebruiken?
[Reactie gewijzigd door Maurits van Baerle op dinsdag 29 januari 2013 14:13]
Dat kan dan ook niet in UPnP.Wie ooit heeft verzonnen dat het ok is om de configuratie van network- en security devices te laten veranderen, van buiten-af, geautomatiseerd, zonder authenticatie, daar is een speciaal plekje voor gereserveerd in de hel.
Met "van buitenaf" bedoelde ik: niet op het apparaat zelf, maar (zonder authenticatie) vanaf een ander apparaat.
Bovendien lijkt het er op dat de meeste uPnP-implementaties er geen moeite mee hebben om dingen zonder authenticatie te doen.
En het is maar afwachten wat de vendor van je router nu precies heeft geimplementeerd. Je zou verwachten dat een router geen uPnP pakketjes op het outside-interface zal accepteren. Maar is dat zo ? Ik ga dat niet testen. En met de ISPs in Nederland, is het maar afwachten wat voor router je nu weer thuis krijgt gestuurd.
Bovendien lijkt het er op dat de meeste uPnP-implementaties er geen moeite mee hebben om dingen zonder authenticatie te doen.
En het is maar afwachten wat de vendor van je router nu precies heeft geimplementeerd. Je zou verwachten dat een router geen uPnP pakketjes op het outside-interface zal accepteren. Maar is dat zo ? Ik ga dat niet testen. En met de ISPs in Nederland, is het maar afwachten wat voor router je nu weer thuis krijgt gestuurd.
Het alternatief is dat je voor elke scheetconnectie een poort open moet zetten in de normale thuisconsumentensituatie, waar nagenoeg iedereen achter een NAT-router zit. Dat lukt de meeste stervelingen niet.
UPnP is nog nooit veilig geweest. Daarom disable ik de techniek standaard als ik apparatuur configureer. Daar denk ik eigenlijk niet eens meer over na. De manier waarop dit 'nieuws' nu wereldkundig wordt gemaakt verbaasd me dan ook enigszins.
Zoals wiki ook stelt: "Unfortunately, many UPnP device implementations lack authentication mechanisms, and by default assume local systems and their users are completely trustworthy."
Assumption is the mother of all fuck-ups.
Zoals wiki ook stelt: "Unfortunately, many UPnP device implementations lack authentication mechanisms, and by default assume local systems and their users are completely trustworthy."
Assumption is the mother of all fuck-ups.
Dat is ook logisch, als de aanvaller al binnen je lokale netwerk is, helpt het uitzetten van UPnP niets - dat is schijnveiligheid.
[Reactie gewijzigd door Dreamvoid op dinsdag 29 januari 2013 13:55]
Als de aanvaller al binnen je netwerk zit ben je zowiezo de lul en dan maakt upnp aan of uit ook geen reet meer uit.
Dus ik snap de ophef niet zo.
Gewoon zorgen dat ze niet binnen komen. Ja makkelijker gezegt dan gedaan.
Dus ik snap de ophef niet zo.
Gewoon zorgen dat ze niet binnen komen. Ja makkelijker gezegt dan gedaan.
Assumption is the mother of all fuck-ups.
offtopic:
Assumption is the basis of all decisions
Compile jij de sourcecode van je besturingssysteem zelf, nadat je met de hand gekeken hebt of er geen achterdeurtjes in staan? Controleer je of het gras voor je huis wel echt gras is en geen giftige kruidenmutatie? Kijk je 's ochtends of je in hetzelfde huis wakker bent geworden als waar je bent gaan slapen? Verifieer je dat de krant die in je bus valt wel de krant van die dag is? Ik hoop van harte dat je niet zo paranoia bent en het gewoon aandurft een paar realistische aannames te doen in het leven.
Assumption is the basis of all decisions
Compile jij de sourcecode van je besturingssysteem zelf, nadat je met de hand gekeken hebt of er geen achterdeurtjes in staan? Controleer je of het gras voor je huis wel echt gras is en geen giftige kruidenmutatie? Kijk je 's ochtends of je in hetzelfde huis wakker bent geworden als waar je bent gaan slapen? Verifieer je dat de krant die in je bus valt wel de krant van die dag is? Ik hoop van harte dat je niet zo paranoia bent en het gewoon aandurft een paar realistische aannames te doen in het leven.
Waar het om gaat is niet of er aannames worden gedaan, maar of deze realistisch zijn. Uit de reacties van andere tweakers leer ik dat het geen vreemde aanname is: UPNP kan niet in IP-pakkjes ingepakt worden maar moet altijd vanuit het LAN zelf komen. Kwaadwillenden hebben hier in het algemeen niets te zoeken.
[Reactie gewijzigd door 84hannes op dinsdag 29 januari 2013 14:21]
UPnP dat onnodig aan staat maakt het een indringer wel erg makkelijk. Vandaar dat ik die aanname een fuck-up vind. Het is een onnodig protocol bedacht voor amateurs.
En nee, ik ben niet overdreven paranoia. Wel op mijn hoede.
En nee, ik ben niet overdreven paranoia. Wel op mijn hoede.
uPnP gaat over IP.UPNP kan niet in IP-pakkjes ingepakt worden maar moet altijd vanuit het LAN zelf komen.
http://en.wikipedia.org/w..._Plug_and_Play#Addressing
Of dacht jij dat wanneer je data over je LAN gaat, er dan geen IP header meer om zit ?
IP On Everything !
De meeste Tweakers zullen uPNP toch al standaard uit hebben geschakeld of niet?
En de grote menigte zullen, als ze al van dit probleem horen, niet weten wat ze er aan moeten doen...
Dus hoe gaan de fabrikanten (die weinig zin hebben om tig jaar oude apparatuur te gaan investeren) dit aanpakken?
"Nieuwe router, nu nóg veiliger" schiet bij mij te binnen als reclame kreet.
En de grote menigte zullen, als ze al van dit probleem horen, niet weten wat ze er aan moeten doen...
Dus hoe gaan de fabrikanten (die weinig zin hebben om tig jaar oude apparatuur te gaan investeren) dit aanpakken?
"Nieuwe router, nu nóg veiliger" schiet bij mij te binnen als reclame kreet.
ik zet het ook altijd uit, net nog even gekeken maar het stond dus aan 
nu zitten er hier meer mensen op het netwerk maar ik ben de enigste met het router wachtwoord.
net dus alsnog upnp uitgezet en de wachtwoorden veranderd.
nu zitten er hier meer mensen op het netwerk maar ik ben de enigste met het router wachtwoord.
net dus alsnog upnp uitgezet en de wachtwoorden veranderd.
Dat zullen je buren fijn vinden. 
Och, als ik zo eens kijk wat ik bij vrienden en kennissen allemaal aan totaal onbeveiligde netwerken aantref van buren dan denk ik dat de meeste mensen geen flauw benul hebben van wat security is.
Netwerknaam: Dlink. Geen encryptie, geen toegangscontrole, en geen wachtwoord op de admin functies van het Wifi AP. En dan in een flat waar 8 gezinnen wonen, de meeste met koters in de 12~18 range. Die zijn handig genoeg om daarover het web op te gaan, gigabytes aan porno en bangalijsten te down- en uploaden en hun ouders er niets van te laten merken. En de aansprakelijke? De houder van de onbeveiligde aansluiting, natuurlijk, want die heeft niets gedaan aan beveiliging en kan dus verantwoordelijk gehouden worden voor "zijn" download gedrag. Of hij ook verantwoordelijk is voor wat de toegang van minderjarigen tot niet vor kinderen geschikte downloads (en wat de geile tieners allemaal uploaden trouwens...) is nog niet voor een rechter getest, maar echt geweldig safe zou ik me niet voelen.
En die mensen moeten zich zorgen gaan maken over UPnP? No friggin' way.
Netwerknaam: Dlink. Geen encryptie, geen toegangscontrole, en geen wachtwoord op de admin functies van het Wifi AP. En dan in een flat waar 8 gezinnen wonen, de meeste met koters in de 12~18 range. Die zijn handig genoeg om daarover het web op te gaan, gigabytes aan porno en bangalijsten te down- en uploaden en hun ouders er niets van te laten merken. En de aansprakelijke? De houder van de onbeveiligde aansluiting, natuurlijk, want die heeft niets gedaan aan beveiliging en kan dus verantwoordelijk gehouden worden voor "zijn" download gedrag. Of hij ook verantwoordelijk is voor wat de toegang van minderjarigen tot niet vor kinderen geschikte downloads (en wat de geile tieners allemaal uploaden trouwens...) is nog niet voor een rechter getest, maar echt geweldig safe zou ik me niet voelen.
En die mensen moeten zich zorgen gaan maken over UPnP? No friggin' way.
welke tool op www.rapid7.com bedoelen ze?Rapid7 is advising businesses and consumers alike to disable UPnP in devices that they suspect may be vulnerable to attack. The firm has released a tool to help identify those devices on its website www.rapid7.com.
Deze http://www.rapid7.com/res...lug-and-play-jan-2013.jsp ?
hmm - die geeft hier nu 404 ... met metasploit zou het ook moeten kunnen volgens het originele blog post. https://community.rapid7.com/community/infosec/blog
hmm - die geeft hier nu 404 ... met metasploit zou het ook moeten kunnen volgens het originele blog post. https://community.rapid7.com/community/infosec/blog
[Reactie gewijzigd door franssie op dinsdag 29 januari 2013 13:57]
eerste link werkt weer goed, maar tijdens het opstarten van ScanNow for Universal Plug and Play (UPnP) programma trof ik een ongewenst probleempje... ze zijn wel slim, maar wel vervelend, want bij cancel wordt het programma niet gestart!
(er is geen installatie, wel wat uitgepakt in temp directory denk ik)
(er is geen installatie, wel wat uitgepakt in temp directory denk ik)
Please fill out this form and submit to register your personal copy of the ScanNow vulnerability scanner for UPnP.
[Reactie gewijzigd door Dark Angel 58 op dinsdag 29 januari 2013 15:40]
Ik heb UPnP altijd uitstaan, gewoon omdat ik in het verleden iets niet aan de praat kreeg, welke na het uitschakelen van UPnP het ineens wel werkte... Heb het verder ook niet nodig...
Alles werkt hier perfect met elkaar samen, via vaste IP adressen heb ik hier iMac/MacBook/2x iPhone/iPad/Synology NAS/PS3/Xbox360/Wii/2x Popcorn Hour en alles werkt zoals het zou moeten ZONDER UPnP...
UPnP is in mijn ogen dan ook alleen bedoelt voor mensen die niet zo handig zijn met IT gerelateerde zaken en/of graag iets willen dat nagenoeg plug & play is.
Niet dat voor mij het qua veiligheid uit zou maken... heb een afgeschermd netwerk voor mezelf (bedraad op iPhone en Macbook na) ... en op een andere router voor gasten (met een andere range... aanpassingen van buitenaf geblokkeerd en een wachtwoord die de normale mens niet onthouden kan
Alles werkt hier perfect met elkaar samen, via vaste IP adressen heb ik hier iMac/MacBook/2x iPhone/iPad/Synology NAS/PS3/Xbox360/Wii/2x Popcorn Hour en alles werkt zoals het zou moeten ZONDER UPnP...
UPnP is in mijn ogen dan ook alleen bedoelt voor mensen die niet zo handig zijn met IT gerelateerde zaken en/of graag iets willen dat nagenoeg plug & play is.
Niet dat voor mij het qua veiligheid uit zou maken... heb een afgeschermd netwerk voor mezelf (bedraad op iPhone en Macbook na) ... en op een andere router voor gasten (met een andere range... aanpassingen van buitenaf geblokkeerd en een wachtwoord die de normale mens niet onthouden kan
[Reactie gewijzigd door Thalaron op dinsdag 29 januari 2013 13:54]
Ik merk dat veel mensen UPnP-NAT met UPnP verwarren. UPnP-NAT is idd dat ding dat in je router zit waarmee je kan portforwarden automatisch.
UPnP is een standaard waarmee je remote functies kan uitvoeren zoals je dat in een programmeertaal zou doen. Dit gaat via webservices. Apparaten kunnen bepaalde klassen hebben zoals UPnP-NAT en werken dan via een bepaalde specificatie.
UPnP zit bijvoorbeeld ook in DLNA, waarmee je makkelijk media spelers kan laten streamen, of video's kan pushen naar je TV, allemaal UPnP.
Op dit moment weten we nog helemaal niks, maar als ik het zo hoor is er eerder iets mis met de implementatie van UPnP dan het protocol zelf. Applicaties kunnen namelijk gewoon UPnP requests negeren, foutmeldingen terug geven enz. Als er toch wat mis is met het protocol zal dat aangepast moeten worden.
EDIT:
Zoals ik al dacht, in de summary van het document staat niks specifiek over UPnP design fouten.
Ze hebben het over programma's zoals miniupnpd (UPnP-NAT) in routers die ook van buitenaf reageren op SSDP (het discovery protrocol). Vrij bizar, aangezien miniupnpd prima ingesteld kan worden om alleen lokaal te luisteren, bovendien zou de firewall dit ook moeten afvangen.
Ik mag dan nog niet heel het document gelezen hebben, maar dit voelt gewoon als zwartmakerij voor een protocol dat niks mis heeft gedaan.
zie: https://community.rapid7.com/docs/DOC-2150
Edit:
jup, gaat over wat programma's die overflows niet checken. Toch belangrijk in ieder programma met netwerkfunctionaliteit. Dat veel daar van ook nog van buitenaf reageren is dan ook wel erg jammer
UPnP is een standaard waarmee je remote functies kan uitvoeren zoals je dat in een programmeertaal zou doen. Dit gaat via webservices. Apparaten kunnen bepaalde klassen hebben zoals UPnP-NAT en werken dan via een bepaalde specificatie.
UPnP zit bijvoorbeeld ook in DLNA, waarmee je makkelijk media spelers kan laten streamen, of video's kan pushen naar je TV, allemaal UPnP.
Op dit moment weten we nog helemaal niks, maar als ik het zo hoor is er eerder iets mis met de implementatie van UPnP dan het protocol zelf. Applicaties kunnen namelijk gewoon UPnP requests negeren, foutmeldingen terug geven enz. Als er toch wat mis is met het protocol zal dat aangepast moeten worden.
EDIT:
Zoals ik al dacht, in de summary van het document staat niks specifiek over UPnP design fouten.
Ze hebben het over programma's zoals miniupnpd (UPnP-NAT) in routers die ook van buitenaf reageren op SSDP (het discovery protrocol). Vrij bizar, aangezien miniupnpd prima ingesteld kan worden om alleen lokaal te luisteren, bovendien zou de firewall dit ook moeten afvangen.
Ik mag dan nog niet heel het document gelezen hebben, maar dit voelt gewoon als zwartmakerij voor een protocol dat niks mis heeft gedaan.
zie: https://community.rapid7.com/docs/DOC-2150
Edit:
jup, gaat over wat programma's die overflows niet checken. Toch belangrijk in ieder programma met netwerkfunctionaliteit. Dat veel daar van ook nog van buitenaf reageren is dan ook wel erg jammer
[Reactie gewijzigd door wootah op dinsdag 29 januari 2013 14:23]
En toch werkt UPnP gewoon ronduit slecht. Hoe leuk het protocol ook is, en het maakt ook niet uit of het 'niks fout gedaan heeft', het gaat er gewoon van uit dat alles in de LAN zone 'goed' is, en dat is gewoon bijna nooit zo. Alleen als je een beheerd netwerk hebt waarbij je alle aangesloten appraten ook nog eens 100% onder controle hebt mag een protocol als UPnP lekker z'n gang gaan. Maar op dat moment is dat natuurlijk niet meer nodig om dat je dan zelf al weet hoe je apparaten op elkaar moet aansluiten.
Dat is in essentie de kern van het probleem: een protocol dat 'domme gebruikers' in staat stelt zonder kennis van zaken toch verbindingen binnen (en buiten) hun netwerk mogelijk te maken. Het maakt dan geen drol uit hoe dat technisch gezien werkt, want je geeft in feite de gebruikers de middelen in handen om zichzelf hoe dan ook kwetsbaar te maken, zonder dat ze weten waar ze mee bezig zijn. En dat is nou juist wat je niet wil! Je moet gebruikers tegen zichzelf beschermen. Daarom bestaan er verborgen interfaces, CLI's die eindgebruikers niet kennen, gelockte bootloaders, password protected configuraties enz. Gewoon, om dat de massa die het apparaat of de apparaten gaan gebruiken zo weinig weten wat ze het bijna altijd verkeerd zullen doen.
Dat is in essentie de kern van het probleem: een protocol dat 'domme gebruikers' in staat stelt zonder kennis van zaken toch verbindingen binnen (en buiten) hun netwerk mogelijk te maken. Het maakt dan geen drol uit hoe dat technisch gezien werkt, want je geeft in feite de gebruikers de middelen in handen om zichzelf hoe dan ook kwetsbaar te maken, zonder dat ze weten waar ze mee bezig zijn. En dat is nou juist wat je niet wil! Je moet gebruikers tegen zichzelf beschermen. Daarom bestaan er verborgen interfaces, CLI's die eindgebruikers niet kennen, gelockte bootloaders, password protected configuraties enz. Gewoon, om dat de massa die het apparaat of de apparaten gaan gebruiken zo weinig weten wat ze het bijna altijd verkeerd zullen doen.
Ach, 'domme' gebruikers hebben alleen NAT (wat sowieso wagenwijd open staat van binnenuit) of een firewall die alleen verkeer van buiten tegenhoudt.
Dan is UPNP dus niet onveiliger dan een NAT of firewall gebruiken.
Dan is UPNP dus niet onveiliger dan een NAT of firewall gebruiken.
Ik geloof niet dat je begrijpt wat UPnP doet. Als een apparaat in de LAN zone fout is, kan hij zelf gewoon een verbinding naar buiten opstellen over een willekeurige poort, daar heeft hij geen UPnP voor nodig. Het uitzetten van UPnP is totaal zinloos als beveiliging tegen 'foute' programma's in je LAN. Het enige "voordeel" dat er is, is dat je je interne netwerk dicht zet voor inkomende verbindingen. Dat is leuk en aardig, maar dat betekent dat je gewoon heel veel toepassingen onmogelijk maakt. Ga je vervolgens handmatig poorten forwarden, dan ben je juist onveiliger bezig: die poorten staan altijd open, en ook als het bewuste programma niet draait of een ander PC op dat IP adres terecht komt. UPnP zorgt ervoor dat precies die poorten openstaan die nodig zijn en geen enkele extra.Hoe leuk het protocol ook is, en het maakt ook niet uit of het 'niks fout gedaan heeft', het gaat er gewoon van uit dat alles in de LAN zone 'goed' is, en dat is gewoon bijna nooit zo.
[Reactie gewijzigd door Dreamvoid op dinsdag 29 januari 2013 15:10]
Stel mijn PC krijgt malware.
Stel die malware configureert mijn router om bepaalde poorten open te zetten. Bv de poort naar een windows-service waar bekende bugs in zitten.
Ik kom er achter dat mijn PC malware heeft.
Ik wis mijn schijf. Ik herinstalleer Windows.
Windows heeft bepaalde bugs, waar ik niks van weet. (Ik ga niet alle Windows security bulletins lezen. En niet alle bugs worden direct gefixed).
Ik denk dat mijn PC een verse Windows install heeft.
Ik denk dat NAT mij beschermt tegen aanvallen van buiten op lokale WIndows services.
Fout.
Zonder dat ik het in de gaten heb, heeft de verwijderde Trojan het gemakkelijker gemaakt om mijn PC later weer aan te vallen.
(Een echte firewall, of ACLs, zou het niet veiliger maken. Ten minste, niet als mijn PC via uPnP de ACLs zou kunnen aanpassen).
Gaten prikken in mijn security/NAT hoeft niet vaak te gebeuren.
Dus doe ik het liever met de hand.
Dan weet ik precies welke risicos ik loop.
In plaats van dat ieder programma/utility die ik een keertje draai zelf met mijn firewall/NAT instellingen gaat liggen klooien. En meestal nog zonder er iets van te zeggen.
Stel die malware configureert mijn router om bepaalde poorten open te zetten. Bv de poort naar een windows-service waar bekende bugs in zitten.
Ik kom er achter dat mijn PC malware heeft.
Ik wis mijn schijf. Ik herinstalleer Windows.
Windows heeft bepaalde bugs, waar ik niks van weet. (Ik ga niet alle Windows security bulletins lezen. En niet alle bugs worden direct gefixed).
Ik denk dat mijn PC een verse Windows install heeft.
Ik denk dat NAT mij beschermt tegen aanvallen van buiten op lokale WIndows services.
Fout.
Zonder dat ik het in de gaten heb, heeft de verwijderde Trojan het gemakkelijker gemaakt om mijn PC later weer aan te vallen.
(Een echte firewall, of ACLs, zou het niet veiliger maken. Ten minste, niet als mijn PC via uPnP de ACLs zou kunnen aanpassen).
Gaten prikken in mijn security/NAT hoeft niet vaak te gebeuren.
Dus doe ik het liever met de hand.
Dan weet ik precies welke risicos ik loop.
In plaats van dat ieder programma/utility die ik een keertje draai zelf met mijn firewall/NAT instellingen gaat liggen klooien. En meestal nog zonder er iets van te zeggen.
[Reactie gewijzigd door gryz op dinsdag 29 januari 2013 15:57]
Wat je beschrijft is UPnP-NAT en geen UPnP.
Houd de discussie svp zuiver.
Houd de discussie svp zuiver.
Upnp staat hier aan, ik kijk op de router en er zijn geen poortmappings gemaak.
Ik start emule en klik op refresh in de router:
Active Protocol Int. Port Ext. Port IP Address
YES TCP 56683 56683 192.168.1.1
YES UDP 50974 50974 192.168.1.1
Ik sluit Emule weer en klik 30 seconden later weer op refresh: alles staat weer dicht.
Dus tenzij je binnen 30 seconden een machine opnieuw kan installeren loop je dus weinig risico. Misschien zelfs minder risico aangezien de poorten dicht staan als de applicatie niet draait. Bij handmatige portmapping zou een ander programma theoretisch gebruik kunnen maken van dezelfde poort *niet gelijktijdig).
Ik start emule en klik op refresh in de router:
Active Protocol Int. Port Ext. Port IP Address
YES TCP 56683 56683 192.168.1.1
YES UDP 50974 50974 192.168.1.1
Ik sluit Emule weer en klik 30 seconden later weer op refresh: alles staat weer dicht.
Dus tenzij je binnen 30 seconden een machine opnieuw kan installeren loop je dus weinig risico. Misschien zelfs minder risico aangezien de poorten dicht staan als de applicatie niet draait. Bij handmatige portmapping zou een ander programma theoretisch gebruik kunnen maken van dezelfde poort *niet gelijktijdig).
En hoe kunnen die "domme" gebruikers dan normaal gebruik maken van het internet en applicaties die dat nodig hebben met hun nat-router? Het is altijd een hoop gescheld op de onwetende consument vanuit de "superieure" tweaker. Maar een alternatief komt vervolgens nooit. UPNP is juist bedoeld voor normale mensen ipv die 0,00000000000000000001% van de mensen met kennis van zaken.
"Ik merk dat veel mensen UPnP-NAT met UPnP verwarren. UPnP-NAT is idd dat ding dat in je router zit waarmee je kan portforwarden automatisch."
Precies wat ik dacht toen ik het artikel las.
Nu gaat iedereen die twee vormen door elkaar gooien, want ze weten niet wat het verschil is.
Die 'verwondbaarheid' bij UPnP-NAT is al heel lang bekend en kan inderdaad gebruikt worden
voor minder frisse zaken zoals trojans en virussen.
Maar als dat zo lang bekend is en het is zo gemakkelijk, waarom zijn er nog geen massa's van virussen en trojans op het internet die hiervan gebruik maken?
Vermoedelijk omdat het vrij nutteloos is!
Als je hiervan gebruik wilt maken, ben je toch al binnen in het netwerk of pc.
Dus waarom die moeite?
Precies wat ik dacht toen ik het artikel las.
Nu gaat iedereen die twee vormen door elkaar gooien, want ze weten niet wat het verschil is.
Die 'verwondbaarheid' bij UPnP-NAT is al heel lang bekend en kan inderdaad gebruikt worden
voor minder frisse zaken zoals trojans en virussen.
Maar als dat zo lang bekend is en het is zo gemakkelijk, waarom zijn er nog geen massa's van virussen en trojans op het internet die hiervan gebruik maken?
Vermoedelijk omdat het vrij nutteloos is!
Als je hiervan gebruik wilt maken, ben je toch al binnen in het netwerk of pc.
Dus waarom die moeite?
Er zit nogal een verschil in fouten in de standaard en fouten in de implementatie van een standaard.
Waarbij dit een fout in de standaard is, zal dit automatisch tot gevolg hebben dat zo'n beetje elke implementatie hiervan dus dezelfde fouten bevat.
Dus om nu de schuld bij de fabrikanten te leggen vind ik nogal gemakkelijk. Had dan eerst de standaard aangepast voordat er met dit soort nieuws naar buiten wordt getreden.
Waarbij dit een fout in de standaard is, zal dit automatisch tot gevolg hebben dat zo'n beetje elke implementatie hiervan dus dezelfde fouten bevat.
Dus om nu de schuld bij de fabrikanten te leggen vind ik nogal gemakkelijk. Had dan eerst de standaard aangepast voordat er met dit soort nieuws naar buiten wordt getreden.
Voor zover ik hier meemaak, werkt DLNA prima in mijn situatie, zonder UPnP in de router aan te hebben. maar misschien snap ik het dan niet, kan ook.
Ik gebruik Tomato firmware op een Linksys router, UPnP en UPnP-NAT staan beide uitgeschakeld, al zolang ik routers gebruik zet ik alle zut uit welke ik niet gebruik. De diverse uitgeprobeerde DLNA toepassingen werken allen prima zonder die instelling. Streamen naar een PS3, of Android telefoon gaat prima.
Ik gebruik Tomato firmware op een Linksys router, UPnP en UPnP-NAT staan beide uitgeschakeld, al zolang ik routers gebruik zet ik alle zut uit welke ik niet gebruik. De diverse uitgeprobeerde DLNA toepassingen werken allen prima zonder die instelling. Streamen naar een PS3, of Android telefoon gaat prima.
Op dit item kan niet meer gereageerd worden.
Onderwerpen
Populair: Android Samsung Websites en communities Mobiele telefoons Google Sony Games Microsoft Consoles Microsoft Xbox One
© 1998 - 2013 Tweakers.net B.V. Contact Over Tweakers Jouw privacy Algemene voorwaarden Cookies
Tweakers wordt uitgegeven door De Persgroep en wordt gehost door True
