Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Transmission-bittorrentclient werkt aan patch voor rce-lek

De ontwikkelaars van de bittorrentclient Transmission werken aan een patch voor een rce-lek, dat door een onderzoeker van Googles Project Zero is gevonden. Hij demonstreerde een aanval via een kwaadaardige site op de webinterface van de client.

Tavis Ormandy, de onderzoeker die de kwetsbaarheid vond, schrijft dat een aanvaller via een kwaadaardige website toegang kan krijgen tot de webinterface van een Transmission-gebruiker, die alleen via localhost bereikbaar zou moeten zijn. Door gebruik te maken van een techniek die bekendstaat als dns rebinding, toont Ormandy aan dat hij de Transmission-instellingen kan wijzigen en bijvoorbeeld een bepaald script kan draaien zodra een torrent is gedownload. In een gepubliceerde demo van de aanval meldt de onderzoeker dat deze ongeveer vijf minuten in beslag neemt. De aanval zou werken in Chrome en Firefox op zowel Windows als Linux. De macOS-versie is ook kwetsbaar, zo achterhaalde een tweaker.

Inmiddels heeft het lek het kenmerk CVE-2018-5702 gekregen en is de patch gemerged, zo blijkt uit de GitHub-pagina van Transmission. Het lijkt erop dat de patch zal uitkomen in versie 2.93 van de software. Die is momenteel nog niet beschikbaar. Een lid van het ontwikkelaarsteam zegt tegen Ars Technica dat alleen gebruikers kwetsbaar zijn die Transmission met toegang op afstand en zonder wachtwoordbeveiliging gebruiken.

Ormandy meldt dat hij de ontwikkelaars een patch heeft gestuurd op 1 december, maar dat deze vorige week nog steeds niet was toegepast. Hij uit zijn frustratie over het feit dat dit zo lang duurt en zegt dat opensourceprojecten er vaak uren over doen om een patch toe te passen en niet maanden. De onderzoeker laat via Twitter weten dat hij ook rce-lekken in andere bittorentclients heeft gevonden, maar dat deze nog niet publiek zijn, omdat Project Zero een deadline van negentig dagen hanteert.

Door

Nieuwsredacteur

59 Linkedin Google+

Reacties (59)

Wijzig sortering
Dat is inderdaad ook aan de lange kant. Zoals hij zelf al zegt:
Hij uit zijn frustratie over het feit dat dit zo lang duurt en zegt dat opensourceprojecten er vaak uren over doen om een patch toe te passen en niet maanden.
Dat is ook de kracht van opensource projecten.. Van Enterprises zoals Microsoft verwacht je dat ze hier lang over doen...
Van enterprises zoals Microsoft zou je mogen verwachten dat ze permanent personeel in dienst hebben dat lekken kan dichten. Voor opensource projecten geldt vaak dat ze vrijwillig beheerd worden. Daarnaast is het ook vrij gebruikelijk dat (vooral oudere) projecten al een behoorlijke tijd meer of mindere mate in de steek zijn gelaten.

De projecten die actief beheerd worden zijn uiteraard degenen die doorgaans ook binnen uren reageren. Ik weet overigens niet of transmission bij die inactieve projecten hoort, ze hebben nog wel wat commits gedaan in de afgelopen maanden, maar je kan ook wel zien dat het is afgenomen sinds 2013.
Alleen is het landschap wat Microsoft moet onderhouden een stuk groter en ingewikkelder dan de ontwikkelaars van Transmission. Dus is het logischer dat ze een team hebben wat de coŲrdinatie doet bij bugs en andere vulnerabilities.
Het gaat er bij mij niet in dat niemand even vijf min de tijd heeft om een email te tiepen naar Travis met de nette melding dat alles in goede orde ontvangen is en dat men snel aan de slag gaat.
Het gaat er bij mij niet in dat niemand even vijf min de tijd heeft om een email te tiepen naar Travis met de nette melding dat alles in goede orde ontvangen is en dat men snel aan de slag gaat.
Dat klinkt inderdaad alsof het nauwelijks moeite is en ik ben op zich met je eens dat het netjes was geweest. Maar zoals @ACM al te kennen geeft bestaat het ontwikkelteam van Transmission 100% uit vrijwilligers. Deze vrijwilligers hebben allemaal ook andere dingen te doen zoals hun eigen werk en misschien een gezin met kinderen. Ook zaten de feestdagen er nog tussen. Daarnaast is het Transmission project sinds 2013 nog maar mondjesmaat actief. Het is er dus waarschijnlijk simpelweg bij ingeschoten, maar gelukkig is het inmiddels wel opgepakt.
Het lijkt me eigenlijk wel logisch dat er minder activiteit is in de repo, transmission is gewoon een stabiel stuk software ondertussen dat niet vol gepropt hoeft te worden met iedere mogenlijke feature (imho)
Echter blijkt dus het tegenovergestelde waar. Microsoft heeft een hele rits aan producten die zij moeten onderhouden en tegenwoordig ook nog eens allemaal met elkaar in connectie staan. Daar nemen ze dus wat langer de tijd voor om alles uit te voeren en uitvoerig te testen (dat laatste schiet er ook nog wel eens bij in heb ik het idee - Windows Updates :D)

Open Source projecten zijn meestal 1 product of soms enkele, maar staan vaak los van elkaar. Hierdoor kan een update makkelijk snel worden doorgevoerd.

Anderszijds ben ik het met je eens. Van grote enterprises MAG je verwachten dat het snel gebeurd door een goede structuur binnen het bedrijf, goede communicatie. Bij een opensource project is het vaak precies andersom. Echter zijn de verwachtingen dus precies omgedraaid van de realiteit - in de meeste gevallen!
Mwah, aan de andere kant is steeds nieuwe code toevoegen ook voedsel voor programmeerfoutjes. Het mes snijdt aan twee kanten. Gelukkig draaide ik deze software in Docker.
Enerzijds fijn dat Google probeert software veiliger te maken, anderzijds wel erg onbehoorlijk dat ze de bedrijfsvoering van anderen menen te mogen dicteren in de zin van "regel het maar binnen 90 dagen anders publiceren we en zitten al je gebruikers in de ellende als iemand de bug misbruikt" (zouden ze natuurlijk al kunnen zitten zonder het te weten, maar dit vergroot de kans op misbruik wel aanzienlijk).

Misschien dat dit bij sommige organisaties de enige manier is om ze in beweging te krijgen, maar ik kan me ook voorstellen dat het bij complexe software soms langer duurt e.e.a. te fixen.

Deze organisatie was gewoon netjes aan een patch bezig en het lijkt zelfs al bekend in welke update deze verschijnt. Doe dan gewoon niet zo lullig als Google zijnde. Frustratie mag hier geen rol in spelen.

[Reactie gewijzigd door Vizzie op 16 januari 2018 08:46]

Dat heet 'Responsible Disclosure' en is gebruikelijk bij security bugs. Ik weet uit ervaring dat dat ook bij grote bedrijven gebeurd en dat iedereen alles daarvoor uit handen laat vallen indien nodig. Daar wordt vast een sprintje of twee voor vrijgemaakt :-)

Alternatief is dat de bug direct op het internet wordt geklapt. Dan zijn de gevolgen vele malen groter.

3 maanden is soms kort maar het maakt wel dat er even focus is, ook bij het management. Common practice, al je het mij vraagt.
Dat heet 'Responsible Disclosure' en is gebruikelijk bij security bugs. Ik weet uit ervaring dat dat ook bij grote bedrijven gebeurd en dat iedereen alles daarvoor uit handen laat vallen indien nodig. Daar wordt vast een sprintje of twee voor vrijgemaakt :-)

Alternatief is dat de bug direct op het internet wordt geklapt. Dan zijn de gevolgen vele malen groter.

3 maanden is soms kort maar het maakt wel dat er even focus is, ook bij het management. Common practice, al je het mij vraagt.
het risico bestaat dat je daardoor (de verminderde focus op de rest en wel focus op die ene bug) je misschien wel MEER bugs introduceert als iedereen alles uit z'n handen moet laten vallen..
Praktisch gezien heb je gelijk, maar we moeten ergens een grens trekken. Als je niet snel en effectief op dit soort problemen kan reageren moet je misschien maar geen netwerksoftware bouwen. Net zoals je ook geen eten mag verkopen als je daar niet hygiŽnisch mee omgaat. Bij dit soort problemen ben ik liever wat te streng dan te los.
Gevoelsmatig ben ik het met je eens dat het kort is, maar nu duurt het (in het algemeen) veel te lang. 30 dagen om de bug te fixen betekent in praktijk dat het 3 maanden duurt voor de fix beschikbaar is. In we tussentijd is iedereen kwetsbaar en anderen hebben er vaak indirect ook last van.
We moeten ofwel sneller patchen ofwel minder fouten maken. Dat laatste is natuurlijk beter, maar dat kost een investering (in tijd, codereviews, betere frameworks en migraties, etc...) Wat publieke druk maakt het makkelijker om die investering te down.
Sneller patchen is niet altijd de oplossing. Ik ga liever goed patchen. En een vulnerability die nu ontdekt wordt kan er al jaren in zitten. Dus zolang een gevonden vulnerability niet direct aan de grote klok wordt gehangen is de situatie niet onveiliger als daarvoor.
Daarbij ga je er van uit dat nog niemand anders het gat heeft gevonden. Misschien dat er al op grote schaal misbruik van wordt gemaakt zonder dat iemand het merkt, dat is helaas volkomen realistisch. Wat extra netwerkverkeer naar een torrentbak gaat niemand opvallen.
USN zegt bijv:
It was discovered that Transmission incorrectly handled certain POST
requests to the RPC server and allowed DNS rebinding attack. An
attacker could possibly use this issue to execute arbitrary code.
Als je browser niet op localhost draait kan de aanvaller dit ook niet exploiten tenzij hij weet op welk(e) IP(s) en port jouw Transmission RPC draait.

Flikker je het achter een SNT, en bindt je Transmission alleen op die SNT /32 en een non-standaard port dan gaan ze dat niet raden.

Kwalijker is het dat publieke domeinen door DNS en browser domweg geresolved worden naar private IPs, en stilletjes benaderd worden. Welke mongool heeft bedacht dat dat een goed idee is? Zo kun je vast ook wachtwoorden op routers bruteforcen (of beter: als er geen wachtwoord op zit!). IIRC heeft NoScript daar een verdediging voor.
Als je browser niet op localhost draait kan de aanvaller dit ook niet exploiten tenzij hij weet op welk(e) IP(s) en port jouw Transmission RPC draait.
Ja en nee, als er dan toch al code draait binnen het doelnetwerk is het een kwestie van tijd voor iemand een portscanner of packetsniffer of iets dergelijks weet te bouwen om op afstand rond te snuffelen.
Kwalijker is het dat publieke domeinen door DNS en browser domweg geresolved
worden naar private IPs, en stilletjes benaderd worden. Welke mongool heeft bedacht dat dat een goed idee is?
Wat is het alternatief? Dat je in je eigen netwerk geen DNS mag gebruiken? Binnen je thuis-netwerk is dat misschien nog te doen, maar een beetje bedrijf met honderden of duizenden medewerkers en computers kan eigenlijk niet zonder.

Je zou op het idee kunnen komen om een lijstje met "echte" domeinen te maken, en RFC1918 adressen verbieden, maar daarmee zijn die adressen nog niet weg. Dan gaan mensen intern verzonnen domeinen gebruiken, zoals dat nu ook al gaat. Veel bedrijven die daar ".local" of ".lan" voor gebruiken of zo. Maar hoe gaat je browser weten welke verzonnen domeinen echt zijn en welke niet? Is de .local van mijn bedrijf echter dan die van jouw bedrijf?
Met DNSSEC kun je nog iets zeggen over welke domeinen bestaan en welke niet, mits je een internetverbinding hebt. Je zou kunnen bedenken dat je geen RFC1918 mag resolven uit een echt bestaand domein, maar dan moet je ook accepteren dat je ze wel mag resolven uit niet-bestaande domeinen. Als je antwoorden uit niet-bestaande domeinen gaat accepteren is het einde zoek.

Als je dan toch iemand de schuld wil geven dan wijs ik liever naar de ISPs die ons NAT hebben opgedrongen met hun zuinigheid. Eerst omdat je maar 1 computer op een internetabonnement mocht aansluiten, later omdat je maar 1 IPv4-adres kreeg ondanks dat je meerdere computers mocht aansluiten.
Daardoor is een hele generatie opgegroeid met het idee dat RFC-1918 adressen op een of andere manier veilig zijn en dat NAT een firewall overbodig maakt.
Zo kun je vast ook wachtwoorden op routers bruteforcen (of beter: als er geen wachtwoord op zit!). IIRC heeft NoScript daar een verdediging voor.
Dat klopt en dat gebeurt inderdaad echt. Vandaar dat ik overal hamer op "beveiliging in lagen" en benadruk dat "privť-netwerken" eigenlijk niet bestaan. Behandel ieder netwerk alsof het het publieke internet is.
Dat je in je eigen netwerk geen DNS mag gebruiken?
Dat hij alleen lokaal zou mogen resolven en dat dus op het moment dat jij via een (al dan niet publieke) resolver een publiek domein resolved en deze verwijst naar een lokaal IP adres, er een alarmbel zou moeten rinkelen (dat dus blacklisten, en vervolgens de sysadmin het laten whitelisten want rate limiten is niet goed genoeg). Dat blacklisten doen we met TLS certificaten tegenwoordig ook standaard. Vroeger (iig in de '90s) was dat niet het geval!!

Voor een browser zou hetzelfde kunnen gelden: blacklisten van referenties van publieke websites (domeinen) die refereren naar lokale domeinen (en/of IP adressen).

Dus de manier waarop NoScript het doet, is de juiste. Als je dat dan nodig hebt in je bedrijf dan whitelist je die maar specifiek en sla je dat op.

DNSSEC is vooral een garantie top-down, niet zo zeer bottom-up. In dit geval is dat niet zo belangrijk, maar in andere gevallen wel. Binnen een LAN zou je prima een privaat DNS server kunnen gebruiken icm DNSCurve en DNSSEC waarbij je keys self-signed (dat is OK, als je ook certificate pinning gebruikt) en vervolgens in je publieke DNS requests je resolver die domeinen laten blokkeren. Maar dat laatste hoeft al niet eens met *.local

Wat betreft die ISPs. Ziggo heeft me een keer IPv6 only geleverd. Nog even buiten het feit dat die kabelmodem/router er om de haverklap uit vloog zit je dan praktisch gezien op IPv6 only. Nee bedankt. ISPs moeten tijdelijk dual stack leveren aan klanten, en dan pas IPv4 uitschakelen. Iets met backwards compatibility. Die mag op dit niveau van goede kwaliteit zijn. Een 6 to 4 proxy die de ISP zelf draait om soms e.e.a. te NATen is dan niet goed genoeg! Het is too little, too late, maar de klant mag daar niet de dupe van zijn.
Dat hij alleen lokaal zou mogen resolven en dat dus op het moment dat jij via een (al dan niet publieke) resolver een publiek domein resolved en deze verwijst naar een lokaal
<knip>
Voor een browser zou hetzelfde kunnen gelden: blacklisten van referenties van publieke websites (domeinen) die refereren naar lokale domeinen (en/of IP adressen).
Wat is een "publiek domein"? Volgens mij kan je browser dat onderscheid niet maken.
Dus de manier waarop NoScript het doet, is de juiste. Als je dat dan nodig hebt in je bedrijf dan whitelist je die maar specifiek en sla je dat op.
We hebben het niet alleen over bedrijven. We zijn onze huizen vol domotica aan het stoppen en daarbij wordt er ook gebruik gemaakt van lokale adressen en DNS-namen. Komt nog bij dat de meeste consumenten routers ook via de browser worden bediend.
DNSSEC is vooral een garantie top-down, niet zo zeer bottom-up. In dit geval is dat niet zo belangrijk, maar in andere gevallen wel. Binnen een LAN zou je prima een privaat DNS server kunnen gebruiken icm DNSCurve en DNSSEC waarbij je keys self-signed (dat is OK, als je ook certificate pinning gebruikt) en vervolgens in je publieke DNS requests je resolver die domeinen laten blokkeren. Maar dat laatste hoeft al niet eens met *.local
Dat ziet er op het eerste gezicht uit als een uitstekende oplossing, maar volgens mij verplaatsen we de beslissing van de browser naar de DNS-resolver. Daarmee weet je webbrowser nog steeds niet wat nu "lokaal" is en wat niet. Dat was mijn punt, je browser kan die beslissing eigenlijk niet maken.
Een DNS-resolver heeft iets meer kans, maar die heeft dan weer geen idee waar zo'n verzoek vandaan komt.

Dat een dergelijke omgeving opzetten veel te ingewikkeld is voor een thuissituatie laat ik maar even daar (consumenten gaan niet met CA's en certs slepen ;), dat is vast wel oplosbaar.
Nee bedankt. ISPs moeten tijdelijk dual stack leveren aan klanten, en dan pas IPv4 uitschakelen.
Mijn punt is dat ze daar 20 jaar eerder mee hadden moeten beginnen, in plaats van te wachten tot ze een probleem hadden dat niet meer genegeerd kan worden.

Ik voel overigens wel iets voor het idee om op een of andere manier aan de computer duidelijk te maken wat het lokale netwerk is en waar verzoekjes vandaan komen, maar ik weet nog niet hoe.
Een simpele oplossing zou zijn om de adresbalk van je browser paars te maken als je een RFC1918 adres bezoekt, maar ik ben bang dat we de massa nooit uitgelegd krijgen wat dat precies betekent en wat je dan moet doen en dat het dus alleen maar voor verwarring zou zorgen.
Maar dan zijn er bedrijven zoals Microsoft die jaren op een bekende bug gaan blijven zitten voor verschillende redenen (kosten, nieuwe producten prioriteren of bugs delen met een overheidsorganisatie). Er is geen enkel excuus om een bug niet binnen de week of maand te kunnen oplossen, zelfs goed patchen, meestal is het slechts een lijn of twee die verandert wordt.
Laten we het even op de applicatie Transmission houden. De code-base van Transmission is niet zo groot - zie https://github.com/transmission/transmission - en de pull-request om het op te lossen is al helemaal klein: https://github.com/transm...c5b22fdcc598694ecd4d02f43

Dus praktisch zou ik zeggen dat het zeker niet meerdere maanden hoeft te duren voordat het wordt opgelost.
Nou ja, het is natuurlijk niet vreemd dat Google op die manier druk op de ontwikkelaars legt. Dit is namelijk dezelfde druk die een ontwikkelaar zou hebben als een kwaadaardige partij dit lek had gevonden en verkocht via TOR oid.

Wat me wel opvalt is dat, volgens het Github issue, de bug was doorgegeven op 1 November, wat geen 90 dagen geleden is. Verder zie ik ook dat na het publiek maken van de fix, iemand de patch daarna nog moest aanpassen voor de volgende release en dat dat uitkwam op andere fouten. De patch van de onderzoeker was dus niet perfect.
Enerzijds fijn dat Google probeert software veiliger te maken, anderzijds wel erg onbehoorlijk dat ze de bedrijfsvoering van anderen menen te mogen dicteren
Ik ontvang security@gnome.org email berichten. Dit bevat enorm veel projecten waarvan enkelen behoorlijk veel beveiligingsbugs ontvangen.

90 dagen is enorm lang en erg netjes. Het maakt mij vrij weinig uit of een beveiligingsbug eerst publiek wordt gemaakt of dat ze het stil proberen te houden. Voor sommige projecten zijn er geen actieve ontwikkelaars meer. Dat was voorheen het geval met librsvg (https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=librsvg). Als resultaat uiteindelijk zelf gezegd tegen een onderzoeker dat ze de bug maar publiek maken. Uiteindelijk resultaat? Nieuwe librsvg ontwikkelaar die steeds meer functionaliteit herschrijft in de programmeertaal Rust (de taal voorkomt veel problemen).
Nou, dat vind ik een moeilijk statement als iemand die voor de hobby wel eens op vulns jaagt.

Besef wel dat als deze bug er al een tijdje inzit, Google niet de enige is die 'm kan gevonden hebben, en gezien de aard van de applicatie lijkt het me ook niet onbelangrijk dat een RCE toch echt wel prio krijgt?

Daarbovenop schrijft de auteur dat de onderzoeker ook meteen een patch heeft meegestuurd. Dan is het maar een kwestie van controle van de patch en mergen.

Ik zie niet meteen een geldig excuus waarom een RCE die reported is maanden blijft openstaan...
...dat alleen gebruikers kwetsbaar zijn die Transmission met toegang op afstand en zonder
wachtwoordbeveiliging gebruiken."
Wat mij betreft vraag je er wel ook om als je alle adviezen in de wind gooit en zo slordig omgaat met je beveiliging.

Edit:
Sowieso een beetje vreemd om remote management aan te zetten op je locale machine trouwens al zou een dergelijke aanval misschien ook werken op een intern IP, maar zelfs ik weet die niet vaak goed te gokken.

[Reactie gewijzigd door MiesvanderLippe op 16 januari 2018 08:39]

Mwah denk dat er zat mensen zijn die op afstand een torrent aan willen kunnen zetten. Ik ben het er mee eens dat het misschien niet al te slim is. Als je remote access wil kan je beter een VPN opzetten.
Als je remote access wil kan je beter een VPN opzetten.
Als je Transmission draait op een Linux server dan is er ook nog de transmission-cli aanwezig waarmee je alles kunt doen over SSH. Ik heb geen idee of deze CLI ook op Windows beschikbaar is via de command prompt of PowerShell.
Als je alleen maar clients op je LAN of VPN toegang geeft ben je alsnog vatbaar voor deze en andere DNS rebinding exploits.
Voor sommige browser addons zet je deze aan. Zo kan je bijvoorbeeld direct torrents laden, zonder dit handmatig steeds te hoeven inladen.

Waar het volgens mij in fout gaat is UnPn deze zet/kan de remote port openzetten, iets waar ik achterkwam na het installeren van Qbt. Maar dat wordt hier weer op een andere manier gedaan zo te lezen.

Dus dat mensen dit aanzetten kan ik goed begrijpen en ook dat je geen wachtwoord erop zet, want het is toch lokaal.
Dus dat mensen dit aanzetten kan ik goed begrijpen en ook dat je geen wachtwoord erop zet, want het is toch lokaal.
Het is een klassieke fout die we nog heel vaak gaan zien, ben ik bang. Je kan er maar beter van uitgaan dat je hele netwerk via internet bereikbaar is, want vroeg of laat zal dat waarschijnlijk echt waar zijn. Het is het aloude adagium dat beveiliging in lagen komt. Vertrouwen op een enkele laag (zoals een firewall of NAT) is niet genoeg.
Dat lijkt mij eigenlijk wel, aangezien deze qua code voor zover ik weet vrijwel gelijk is aan de Linux versie. In ieder geval de front-end, waar deze exploit voor geldt.
Ja het leek mij ook, maar gezien enkel Windows en Linux expliciet genoemd worden in het artikel vroeg ik me toch af of er misschien een verschil is qua functies ofzo waardoor die misschien niet kwetsbaar is.
Ik heb het even nagevraagd op hun Github pagina en heb bevestigd gekregen dat de MacOS versie inderdaad ook gewoon kwetsbaar is als je met remote access werkt.
https://github.com/transm...68#issuecomment-357914029
Goeie, ik vermeld het. Ik verwees in de tekst naar het feit dat Ormandy het op Linux en Windows heeft getest, maar dat kan duidelijker idd.
Alleen als je remote access aan hebt gezet.
Ik gebruik zelf transmission op een VPS. De poort zelf staat publiek, echter wel beveiligd met wachtwoord. Ben ik kwetsbaar?
Nee, al zou ik altijd een VPN zetten tussen de gebruiker en de VPS.

Sommige dingen wil je gewoon niet direct aan het WAN hangen.
Dat heeft hier niks mee te maken. DNS rebinding is juist een methode om apparaten in je LAN/VPN aan te vallen.
Nee, tenzij je websites bezoekt met je VPS.

Als je http://127.0.0.1:9091 bezoekt, en je ziet daar een web interface waar je geen wachtwoord hoeft in te vullen, en je zit op versie 2.92 of lager, dan ben je kwetsbaar.
Als ik het goed begrijp werkt dit als ik met de machine waar Transmission op draait het internet op ga en met mijn browser op een kwaadaardige site kom. Dus mijn VM (die niet eens van buitenaf bereikbaar is) die de downloadrommel afhandelt en ook nog eens achter een VPN zit ivm Brein is daar niet vatbaar voor?
Klopt.

Als je http://127.0.0.1:9091 bezoekt, en je ziet daar een web interface waar je geen wachtwoord hoeft in te vullen, en je zit op versie 2.92 of lager, dan ben je vatbaar.
Je bent dan wel vatbaar, maar dan moet de aanvaller ook het adres van je VM raden (die jij in je browser intypt als je Transmission gebruikt). Dat maakt het dus vrijwel onmogelijk tenzij het om een gerichte aanval gaat, maar het kan wel.
Ik moet opeens dan misschien toch maar wat vhosts gaan aanpassen in mijn nginx configuratie, zodat bepaalde sites alleen maar via LAN te bereiken zijn. :+ Dan kan ik vervolgens via VPN naar de sites toe. :) Lijkt mij een stuk veiliger, niet alleen voor Transmission, maar ook voor andere tools die ik draai thuis. :)

[Reactie gewijzigd door CH4OS op 16 januari 2018 08:59]

Als de transmission daemon alleen maar via LAN bereikbaar is ben je nog steeds vatbaar voor deze aanval. (lees het Wikipedia artikel over DNS rebinding maar)
Dat begrijp ik, maar dan moet de aanval zelf ook vanaf LAN uitgevoerd worden.
Ja, dat is het hele punt van deze exploit. Je gaat naar een kwaadaardige website toe en die zorgt ervoor dat je browser deze aanval uitvoert.
Een lid van het ontwikkelaarsteam zegt tegen Ars Technica dat alleen gebruikers kwetsbaar zijn die Transmission met toegang op afstand en zonder wachtwoordbeveiliging gebruiken.
Volgens mij sluit je daarmee al een hoop uit. Zowel aan het internet hangen van je torrent client als dat zonder authenticatie doen is niet erg slim...
Probleem is dat veel mensen denken dat wanneer web interfaces alleen bereikbaar zijn via localhost en de web interface achter NAT zit, ze denken dat deze interface onbereikbaar is.
Mooi dat dit aandacht krijgt op Tweakers, en dat meer software meldingen onderweg zijn. :Y)

Al is dan niet altijd even makkelijk voor open-source projecten, toch denk ik dat 90 dagen disclosure deadline goed is. Je moet ergens een lijn trekken.
alleen gebruikers kwetsbaar zijn die Transmission met toegang op afstand en zonder wachtwoordbeveiliging gebruiken.
Gebruikers die dat doen kunnen net zo goed een joekel van een Welcome! bord ophangen. Als dit alleen die groep treft is dit dus een heel minor bug, totaal niet nieuwswaardig!

Admin-edit:Spelfouten en/of ander commentaar m.b.t. nieuwsposts horen thuis in
Geachte Redactie.

[Reactie gewijzigd door Zeehond op 16 januari 2018 15:13]

Ik ging er van uit dat als ik alleen maar IP-adressen van mijn lokale netwerk toestond en mijn netwerk netjes is afgeschermd met een firewall, dit veilig genoeg zou zijn. Helaas zat ik daar dus fout. Ik denk dat ik niet de enige was.
Nee jij zit dus goed. Tweakers verwoord het een beetje ongelukkig, maar zie het artikel van Ars.
Alleen als je Transmission openzet voor remote access (buiten je LAN dus!) ťn zonder wachtwoord, ben je kwetsbaar. Maar als je dat doet, heb ik als noob zelfs geen exploit nodig om bij je binnen te komen. Dus dit is een hoop opgeblazen nieuws om niks.
Flikker het gewoon achter een VPN/SNT/SSH/RDP oid, ben je ook klaar.
Nee, dat geen oplossing! Je bent dan nog steeds kwetsbaar. Dat is het hele probleem.

[Reactie gewijzigd door lonaowna op 16 januari 2018 14:10]

Normaal gesproken is dat wel de oplossing maar je hebt nog steeds te maken met software.

Dan nog draait hij bij mij in Docker. Je kunt daarmee niet op mijn thuisnetwerk komen, en je bent ook geen root in die container. Het enige wat je kunt is via de VPN het internet op. Nou jongen, veel plezier ermee.

[Reactie gewijzigd door Jerie op 16 januari 2018 21:19]

Nee, dat klopt niet. Ik ben wel kwetsbaar.

Het probleem is dat als ik naar een kwaadaardige website ga, die website met behulp van DNS rebinding er voor kan zorgen dat mijn browser (die dus in mijn LAN zit), bepaalde commando's naar Transmission stuurt. (Transmission ziet niks raars, de commando's komen gewoon van mijn computer binnen de LAN)

Met het "openstellen voor remote access" wordt bedoelt de RPC interface aanzetten, ook al is deze alleen maar toegankelijk binnen mijn LAN.

Wikipedia legt het goed uit, en dit deel is dus essentieel:
This attack can be used to breach a private network

[Reactie gewijzigd door lonaowna op 16 januari 2018 13:56]

Buiten het feit dat een wachtwoord aan te raden is. Echter zou DNS Rebinding Protection hier ook een oplossing zijn.

Dan worden externe DNS antwoorden gericht op RFC1918 adressen genegeerd.

Op dit item kan niet meer gereageerd worden.


Call of Duty: Black Ops 4 HTC U12+ LG W7 Samsung Galaxy S9 Dual Sim OnePlus 6 Battlefield 5 Microsoft Xbox One X Apple iPhone 8

Tweakers vormt samen met Tweakers Elect, Hardware.Info, Autotrack, Nationale Vacaturebank en Intermediair de Persgroep Online Services B.V. © 1998 - 2018 Hosting door True

*