QBittorrent krijgt update die veertien jaar oude kwetsbaarheid verhelpt

De ontwikkelaars achter qBittorrent hebben een fix uitgebracht voor een kwetsbaarheid die al sinds 2010 in de torrentclient zit. De bug kan misbruikt worden om man-in-the-middleaanvallen uit te voeren.

Beveiligingsonderzoeker Sharp Security heeft vastgesteld dat de DownloadManager-class van de opensource torrentclient sinds april 2010 alle foutmeldingen met betrekking tot SSL-certificaatvalidatie negeert. Als deze validatie wordt overgeslagen, kan elke server die zich voordoet als een legitiem exemplaar gegevens onderscheppen, wijzigen of toevoegen, en qBittorrent zou deze gegevens vertrouwen. Aanvallers kunnen hier op verschillende manieren misbruik van maken om gebruikers naar malafide links te sturen of schadelijke bestanden te laten downloaden door het systeem van gebruikers.

Sharp Security stelt dat de kwetsbaarheid is verholpen in versie v5.0.1, die sinds begin deze week beschikbaar is. In de patchnotes van deze update noemt qBittorrent een bugfix die 'SSL-fouten niet negeert', zonder in detail te treden. Het cybersecuritybedrijf raadt gebruikers aan om de update handmatig via een browser te downloaden en niet via de app zelf, aangezien aanvallers ook de updatemelding kunnen misbruiken.

Reacties (60)

[danmark_ori]

" sinds april 2010 alle foutmeldingen met betrekking tot ssl-certificaatvalidatie negeert. "
Hoe is er in de afgelopen 14 (!) jaar dan getest, vraag ik me af.

[oef!]

Het zijn een stel vrijwilligers die samen aan een project werken. Je mag niet verwachten dat er een testproces achter zit alsof het een professionele organisatie was.

En zelfs al was het een professionele organisatie, dan nog had iemand die specifieke testcase moeten maken. Ik geef je nu al op een briefje dat er veel meer applicaties zijn waarin zoiets als dit verkeerd gaat.

[Horatius]

En zelfs al was het een professionele organisatie, dan nog had iemand die specifieke testcase moeten maken. Ik geef je nu al op een briefje dat er veel meer applicaties zijn waarin zoiets als dit verkeerd gaat.

Ik kan je inderdaad uit eerste hand vertellen dat een professionele organisatie het zeker niet beter maakt perse.
Er lopen enorm kritieke processen op software waar testen wel gebeurt maar goed testen? Alles behalve.

Developers testen vaak wel een beetje, maar wanneer het richting acceptatie of productie gaat wordt het vaak te ingewikkeld.

Niemand vind repetitieve testen en keiharde details uitzoeken leuk, dus heb niet perse meer vertrouwen in professioneel of community driven.
Hoe langer ik in de IT wereld rondloop krijg ik alleen maar meer het gevoel dat professioneel ontwikkeld staat voor 'minder getest'.

Immers wordt een dev team gemeten op wat ze opleveren, zo lang het niet fout gaat is er niemand die omkijkt en is de hele proces keten blij.

[dasiro]

het probleem is ondertussen al zo oud als de straat: je schrijft software die moet doen wat je verwacht en pas daarna komt de vereiste dat hij niet doet wat je niet verwacht. Dat eerste is vaak al een uitdaging, maar met dat 2e is een straatje zonder einde en kan software exponentieel ingewikkeld, traag en gebruiksonvriendelijk maken.

[Ayporos]

Het ligt er natuurlijk erg aan wát voor software je ontwikkeld..
Simpele software die niks met kritieke data of met communicatie of zo doet is één ding.
Een torrent client heeft als primaire doel peer-to-peer bestanden uitwisseling te faciliteren echter en dat is toch echt iets anders.
Van zo een stuk software, of je nou in het kamp van 'yarrr' of 'vrijheid van informatie' of 'legitieme gebruiksdoeleinden' zit, lijkt mij dat het voorkomen van Man-in-the-middle kwetsbaarheden toch wel redelijk hoog op de lijst met prioriteiten zou moeten staan.

[dasiro]

Eigenlijk maakt dat niet uit. Als iets niet gevraagd wordt, dan zal het er niet in zitten. "maak het veilig" of "use best practice" zijn vage omschrijvingen en geen correct gedefinieerde vereisten waar je op voorhand de juiste metrics voor kan aanmaken.

Ik heb op het werk al eens de discussie gevoerd met als vraag "wanneer is er genoeg security?", maar slechts een hol antwoord ("nooit") teruggekregen. Voor letterlijk élk proces zal je een scenario kunnen bedenken wat misbruikt kan worden tot op het punt dat niemand nog zijn werk kan uitvoeren.

[phizzie]

Als aanvulling: je kan als bedrijf inderdaad doorslaan met een beleid, zodat processen c.q. werk onwerkbaar wordt. Je kan ook doorslaan als wet- en regelgevingen instantie die die kant op gaat (met de bijbehorende conflicterende vereisten). Ook de eindverantwoordelijke kan doorslaan in minimalisme (zo lang het werkt is het prima, niet méér investeren dan noodzakelijk).
Het tegenargument zit in o.a. agile ontwikkelen ingebouwd: de business case, dwz de toegevoegde waarde moet bekend zijn. Deze waarde mag ook een verzekering zijn: wat is de kans op schade van incident X en wat schat men hoe hoog die schade is? Stel: door het leveren van verkeerde gegevens kan een machine verkeerd afgesteld worden. De kans dat dat gebeurt is 1:100.000 meldingen (eens in de 20 jaar). Wanneer het fout gaat is er 5% kans op ongeluk met grote schade >€100M, 60% kans op afbranden gebouw à €15M, 35% kans op onderdeel falen €1M. De eigenaar accepteert dit risico. De ontwikkelkosten mogen dan bedragen: maximaal (5M+9M+0,35M)/100.000 = €143,5k als verzekering, voor de looptijd (20 jaar).

[SilentLucidity]

Klopt. Testen vind ik niet leuk, tenminste, repetitieve testen niet. Testen automatiseren waarbij alle functionaliteiten getest worden, bijvoorbeeld mbv given, when, then, vind ik wel leuk. Combineer dat met ~95% code coverage en je komt echt een eind. Helaas moet je echter de rest van je team, en in het geval van loonslaaf zijn, je werkgever mee hebben.

[aikebah]

Wel een grote kanttekening bij die coverage:

Code coverage is een snel misleidende KPI. Een leuke waarde voor intern in het development team om te zoeken naar ongedekte of slecht gedekte code secties, maar ook niet meer dan dat. Zonder variation testing in de mix zou ik er niet teveel waarde aan willen hechten mbt kwaliteit van de test-inspanningen voordat er een grondige inspectie van de testscenarios en voorspellingen zelf is gedaan, al is het al wel een stuk beter dan 'niets'.

Ik heb liever 50-70% coverage van degelijke testen gekozen op 'de grootste kans op maken van fouten in de logica' en 'grootste (bedrijfs/aansprakelijkheids/veiligheids) risico's bij het draaien van de software' dan een snel bij elkaar geraapt given/when/then gericht op het halen van een 95% coverage (langs de makkelijkst te bereiken lijnen van multiple condition branches). Code coverage zegt niets meer dan 'de coderegel is doorlopen bij het uitvoeren van een test'.

Dat gezegd hebbende.. is er in de praktijk vaak een veel belabberder dekking en moeten er vaak nog veel (te veel) fouten in de productiefase ontdekt worden.

[Boeshnl]

De beste test is gewoon in productie toch? 😬

[Hansie9999]

Je bedoelt testen zodat een update van je anti virus bij het opstarten je windows client/server niet een bluescreen doet geven ? Zo een testen ?

Zoals recent in het nieuws gebeurt dit ook niet altijd goed bij HEEL grote firma's

[closefuture]

Ik durf wel te stellen dat het gros van alle software (inclusief closed-source software) geen tests heeft om te controleren of bijvoorbeeld de certificaat chain goed checked word.

Ik durf ook wel te stellen dat het merendeel van de developers waar ik mee gewerkt heb PKI eigenlijk niet voldoende snapt. Nu kun je misschien zeggen dat PKI te complex is maar cryptografie gecombineerd met trust management, revocation, etc. is ook gewoon complexe materie.

[IrBaboon79]

Dat kan je je bij veel van die langlopende/laat ontdekte zaken afvragen….

Ik kan mij bijvoorbeeld nog zo’n dingetje met openssl herinneren - heeft ook jaren erin gezeten… en zo zijn er nog wel enige tientallen te vinden in vele pakketten…

Open source en vele ogen principe klinkt leuk maar blijkbaar leest men niet zo nauw de code…

[Creesch]

Open source en vele ogen principe klinkt leuk maar blijkbaar leest men niet zo nauw de code…

Dat is met closed source echt niet anders hoor, maar daar is het veel minder zichtbaar als het gebeurt. In alle jaren die ik in software development heb gewerkt heb ik al zo vaak mensen beslissingen zien maken die tot dit soort zaken kunnen leiden. Sterker nog, door de hoge druk die er soms staat op software ontwikkelteams binnen de corporate wereld is het in sommige opzichten zelfs waarschijnlijker. Testen is sowieso een ondergeschoven kindje, security alleen maar belangrijk op papier (de "audit" van de veel te dure externe partij zegt dat het goed is) en het moet zo snel mogelijk naar productie.

[IrBaboon79]

Helemaal mee eens. Ik heb niets tegen open source hoor, maar men haalt er altijd dat ‘iedereen kijkt in de code’ verhaal bij en dat is pertinent niet waar. Ja, Iedereen kan erin kijken maar dat doet bijna niemand dus het is praktisch bijna net zo obscuur als closed source.

[NoobishPro]

Helemaal mee eens. Er zijn in bijna alle softwares leaks. Juist kwaadwillenden zullen hier meer naar zoeken dan anderen. Ik heb meerdere open source projecten onder handen gehad met duizenden forks en contributies en hier toch nog gigantische fouten in gevonden.

Daarnaast is er security in obscurity. Dat neigen mensen nogal eens te negeren.

Ik laat mijn hoofdproduct volledig bekijken, inclusief servers, ports, alles, door white hats. Die zijn tot nu toe aanzienlijk nuttig geweest. Dat bovenop obscurity biedt gewoon veel waarde.

[Pulletjen]

Je kan zelfs stellen dat het in sommige gevallen obscurer is aangezien kwaadwillenden de code ook kunnen inzien.

[Creesch]

Nee, volgens mij zijn we het niet eens.

Ja, Iedereen kan erin kijken maar dat doet bijna niemand dus het is praktisch bijna net zo obscuur als closed source.

Dit is pertinent niet waar. Er wordt wel degelijk meer gekeken naar open source code over de gehele linie. In closed source software zal er meestal alleen maar naar code gekeken worden als men iets nieuws wil ontwikkelen of een aanpassing wil doen.

Over de gehele linie gezien denk ik oprecht dat meer zaken worden gespot en opgelost in open source software dan closed source software.

[PCG2020]

(...) Het cybersecuritybedrijf raadt gebruikers aan om de update manueel via een browser te downloaden en niet via de app zelf, aangezien aanvallers ook de updatemelding kunnen misbruiken.

qBittorrent verwijst bij een beschikbare update door naar de downloadpagina van de makers op FossHub; je kunt qBittorrent niet in de app zelf downloaden en updaten.

(Nu kan die pagina ook wel nagemaakt worden natuurlijk, dus wellicht is het verstandig om via qBittorent zelf naar de officiële downloadpagina te gaan.)

[STFU]

De file bij FossHub heeft dezelfde checksum, dus het zit gelukkig wel goed.

[supersnathan94]

Totdat je een MITM hebt.

Ze zeggen niet dat het zo is, maar dat het zou kunnen. Je huidige client negeert eventuele waarschuwingen namelijk.

Dus dat het bij jou toevallig goed gaat bied geen garantie dat het bij anderen goed gaat.

[ToolBee]

Als alternatief voldoet Tixati.

[Remzi1993]

Waarom zou ik closed source software gebruiken ipv open source? Wij hebben geen idee wat voor soort beveiligingsproblemen dat heeft omdat we niet de code kunnen checken.

[Mathijs Kok]

Waarom zou ik closed source software gebruiken ipv open source? Wij hebben geen idee wat voor soort beveiligingsproblemen dat heeft omdat we niet de code kunnen checken.

En in Open Source kunnen de boeven in de code naar kwetsbaarheden zoeken, tegenwoordig vaak geautomatiseerd. Ik zie in een project dat wij Open Source hebben dat er bots (met AI) gebruikt worden om te zien of we bekende fouten gemaakt hebben. Een daarvan is een honeytrap en we zien die dagelijks getriggerd worden. Dat zijn geen mensen die willen helpen om de code beter te maken, dat zijn mensen die kijken of onze code toegang geeft tot systemen. Wij gaan dus terug naar closed source.

[supersnathan94]

Wij gaan dus terug naar closed source.

Waarom? Static code analysis is al zo oud als de weg naar Rome. Als je dat niet zelf ook al doet dan snap ik het enigszins, maar wat ben je dan aan het doen?

[iqcgubon]

En in Open Source kunnen de boeven in de code naar kwetsbaarheden zoeken, tegenwoordig vaak geautomatiseerd.

Dit Github dit tegenwoordig niet gewoon automatisch voor jou als developer? Dat mes snijdt langs twee kanten hoor. Als het open source, wordt er tenminste tegen getest.

[NoobishPro]

En specifiek jij weet exact wat qbittorrent doet?

Klinkt als een strawman.

Als je het over torrenting tools gaat hebben ben zelfs ik meer fan van open dan closed. Ik gebruik ook qbittorrent, maar er is geen enkele garantie noch bewijs dat open source veiliger is dan closed source.

Zelfs met open source weten de kwaadwilligen waarschijnlijk meer over de fouten in de software dan de hele rest van de community. Bij course closed source kunnen ze het tenmiste niet rustig uitvogelen met directe tests op stukjes code.

[RoestVrijStaal]

Zelfs met open source weten de kwaadwilligen waarschijnlijk meer over de fouten in de software dan de hele rest van de community. Bij course closed source kunnen ze het tenmiste niet rustig uitvogelen met directe tests op stukjes code.

Security through obscurity is schijn.

Erger nog, bij closed source kunnen bugs die tot exploits leiden verzwegen worden totdat die bruikbaar worden in een exploit-chain.

Op het moment dat er exploits in een open source software pakket gevonden worden, is het een goede vuurproef of er genoeg mankracht en kennis is voor het open source project.

[Argantonis]

Als iets dit verhaal wel onderuit heeft geschopt was het Heartbleed wel. Als er iets wel veel werd gebruikt dan is het wel OpenSSL, en dat is ook compleet onopgemerkt gebleven.
Bovendien heeft het niks te maken met open-source of closed-source of degene die de bug vindt goede of slechte bedoelingen heeft.

[Reactie gewijzigd door Argantonis op 2 november 2024 04:56]

[NoobishPro]

Kun je een argument geven voor de stelling "security through obscurity is schijn"? Want vrijwel iedere dev leert om obscurity in te bouwen zodra ze aan hun eerste project beginnen en dat is niet uit de lucht komen vallen.

Betreft het "kunnen zwijgen" over een gevonden bug in closed source; wederom een strawman.
Waarom zou iemand niet kunnen zwijgen als ze iets vinden in open source code? Sterker nog, wss zijn ze er juist actief naar op zoek om het te misbruiken.

Er zijn net zoveel zero-days gevonden in open source als in closed source, als niet meer.

Een andere comment wijst al naar heartbleed om dit te ontkrachten, zo zijn er nog vele andere voorbeelden.
We zijn hier nota bene aan het discussiëren op een topic over een meer dan 10 jaar oude exploit in open source...

Stellingen zijn leuk, maar waar is de onderbouwing?

[supersnathan94]

Kun je een argument geven voor de stelling "security through obscurity is schijn"? Want vrijwel iedere dev leert om obscurity in te bouwen zodra ze aan hun eerste project beginnen en dat is niet uit de lucht komen vallen.

Oh? Ik niet hoor. Ik heb geleerd alles helemaal de moeder te documenteren dus obscuur is het dan alles behalve.

[NoobishPro]

Sorry, maar ik denk dat je een verkeerd begrip hebt over wat "security through obscurity" betekent.

Je verwart slordig programmeren met obscurity. Obscurity doe je niet binnen je eigen code, dat doe je naar de buitenwereld. Obscurity is camouflage. De kunst van het verbergen van de details van een mechanisme.

[Reactie gewijzigd door NoobishPro op 2 november 2024 12:16]

[supersnathan94]

Sorry, maar ik denk dat je een verkeerd begrip hebt over wat "security through obscurity" betekent.

En ik denk dat jij een verkeerd begrip hebt over het principe.

De kunst van het verbergen van de details van een mechanisme.

Ja en dat werkt dus helemaal niet als losstaand mechanisme. Dit aanleren als “beveiligingsprincipe” is echt niet oké en ook helemaal niet aan de orde bij opleidingen. De reden om iets closed source te maken is IP, maar dan nog moet je het origineel wel beschikbaar laten als open source.

Er zijn net zoveel zero-days gevonden in open source als in closed source, als niet meer.

Dat is ook het hele punt. Je snapt neem ik aan wel dat als er niet kan worden gezocht (closed source) het niet automatisch betekent dat de zero-days er niet zijn en/of dat ze niet gebruikt worden? Het betekent alleen dat jij daar als dev een blinde vlek hebt.

Het feit dat hier iemand na 14 jaar toch even aan de bel trekt is juist goed. Want anders had je dus nooit geweten dat je kwetsbaar bent, dat er een mogelijke exploit voor misbruikt wordt en wat je er tegen zou kunnen doen.

Alleen het feit dat je nu weet dat het probleem bestaat is al 10 keer beter dan het nooit weten en dus ook niet kunnen zien of het misbruikt wordt.

[NoobishPro]

Dit is een situatie "agree to disagree".

Open-source fans hebben vrijwel altijd een voorkeur van bevestiging, daar valt niet echt mee te discussiëren.

Open-source is de absolute fundering van de vrije digitale wereld. Het zal er altijd moeten zijn. Het is echter geen basis om op te besluiten of een stukje software daarom beter zou zijn dan een ander. Veel mensen gaan voor open-source zonder ooit ook maar één regel van de code te lezen.

Tevens is niet alle open-source gelijk. Closed source heeft ook voordelen voorbij een "IP". Alsof dat trouwens zo negatief is...

Als leverancier van closed source software kan een foutje mij miljoenen kosten, als niet miljarden. Om aan te nemen dat er minder baat bij zou zijn om deze codebase goed uit te testen is een absoluut basisloze gedachtegang.
Ik huur white-hats in om shit te testen en die adviseren toch echt obscurity. Ik huur mensen in die weten wat ze doen, contracten hebben en wettelijk verantwoordelijk zijn i.p.v. semi-blind te vertrouwen op vreemden op het internet. Daarnaast ben ik zelf ook wettelijk gevonden om te doen wat ik zeg dat ik doe met de data van mijn gebruikers.

Het open-sourcen van mijn software zou niets anders doen dan het mogelijk te maken voor concurrenten om mijn product te stelen en voor hackers om mijn code in te zien.

De grootste grap hier is misschien nog wel dat zelfs ALS ik mijn product open-source, gebruikers nog steeds geen enkel idee hebben wat er daarwerkelijk op mijn server draait.
Er zijn al meerdere bedrijven betrapt op het hebben van toch net wat meer code op hun servers dan wat de open-source code weergeeft.

Het is gewoon vertrouwen op het woord van een ander, niet meer en niet minder, net als bij closed source. En nogmaals; als jij kiest iets te gebruiken "omdat het open source is", maar vervolgens een installer pakt of simpelweg de code niet compleet en totaal doorneemt ---En begrijpt --- heb je nog steeds geen idee wat er nou eigenlijk gebeurt.

[Dubbeldrank]

Er zijn vele torrent clients, maar Tixati is closed source. Dus dat zal ik nooit boven qBittorrent verkiezen.

[jacobkap]

De update voldoet ook

[jurroen]

Waarom zou iemand die qBittorrent gebruikt switchen? Durf jij je handen in het vuur te steken voor deze proprietary client, dat die geen MitM mogelijk maakt? Dat er geen kwetsbaarheden in zitten? En dat er geen bewuste backdoor in zit?

Als ik die twee even snel vergelijk, lijkt 'ie vooral mank qua featureset in vergelijking. Buiten de vertrouwenskwesties lijkt het een minderwaardige client.

RC4 connection encryption for added security

[MrFax]

En daar zitten geen beveiligingslekken in dan?

[Jazco2nd]

In hoeverre was deze bug werkelijk een dreiging wanneer je QB alleen lokaal draait, niet exposed naar het internet en alleen achter VPN verbinding laat maken met andere torrent clients?

[Bor]

Je kan hier iets met de CVSS score. CVSS, het Common Vulnerability Scoring System, is een gestandaardiseerde methode om de ernst van beveiligingslekken in software te kwantificeren.

Dit betreft de kwetsbaarheid beschreven onder CVE-2024-51774.

CVSS v2
Base Score: 6.4
Vector: CVSS2#AV:N/AC:L/Au:N/C:P/I:P/A:N
Severity: Medium

CVSS v3
Base Score: 9.1
Vector: CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
Severity: Critical

Uitleg van de vector: https://nvd.nist.gov/vuln...PR:N/UI:N/S:U/C:H/I:H/A:N

[Reactie gewijzigd door Bor op 2 november 2024 14:24]

[Jazco2nd]

Daar ben ik zeker bekend mee. Daarmee ondersteep je ook mijn punt. Als je QB niet achter https gooit, is deze vulnerability vrijwel niet relevant.

[Bor]

Het gaat hier niet om "achter https" gooien. De kwetsbaarheid zit in de DownloadManager class. Daarbij, wanneer je geen TLS toepast ben je sowieso kwetsbaar

[Jazco2nd]

Kwetsbaar voor de mensen in het gezin in het huis waar ik woon 🤷
Ik kan geen voorstel maken van een situatie waarin je een torrent client buiten je eigen netwerk wil exposen.. en eigenlijk ook niet een voorstel maken van wie nog met RSS feeds in een torrent client loopt te kloten. Die tijd is toch wel voorbij ?
Torrents/magnets via api toevoegen via *arr lijkt me tegenwoordig het meest gebruikelijk. Geen idee of dan die specifieke class nog wordt gebruikt.

Edit: @Bor ik heb het even opgezocht: dit werd alleen gebruikt voor downloaden van RSS feeds en torrent files. Je bent wel heel erg old skool bezig als je dat nog gebruikt..

[Reactie gewijzigd door Jazco2nd op 4 november 2024 00:19]

[Bor]

Je download alleen binnen je eigen netwerk? RSS feeds worden verder nog veel gebruikt. Zo zijn er ook hele volksstammen die QB interactief gebruiken incl. de search mogelijkheden. Misschien niet door jou maar de gewraakte class doet meer dan alleen RSS.

dit werd alleen gebruikt voor downloaden van RSS feeds en torrent files. Je bent wel heel erg old skool bezig als je dat nog gebruikt..

Jij doet iets anders met een torrent client?

[Reactie gewijzigd door Bor op 4 november 2024 08:19]

[Jazco2nd]

Tegenwoordig is vrijwel alles magnet. Zeker als je handmatig download (de methode die jij waarschijnlijk bedoeld, dat je zelf naar een site gaat, of via rss in QB), is het niet heel verstandig .torrent te downloaden. Das de meest onveilige methode. Dat wordt al jaren afgeraden na allerlei incidenten met torrent files.

Als je *arr apps gebruikt, worden de magnets of torrents door een ander programma opgehaald (Prowlarr) en lokaal naar je torrent client gestuurd.

Je torrent client zit achter VPN. Maar Prowlarr niet (anders wordt je vrij snel geblokkeerd).

Bij magnet wordt de torrent info uit de hyve gedownload, niet van obscure sites.

Als je dus arr apps gebruikt, gebruik je geen DownloadManager class (voor zover ik ben nagegaan).

Ik geloof best dat er nog wat mensen de RSS feed in QB zetten of nog handmatig torrent files downloaden. Maar die zijn dan sowieso onverstandig bezig en volgen geen best practices.

Sowieso is het VEEL eenvoudiger om met Prowlarr handmatig te zoeken, als je liever alles handmatig doet.

[litemotiv]

Die dreiging is dan praktisch gezien nul.

Het is een theoretisch scenario waarbij een gebruiker data zou binnenhalen van server X, en waarbij partij Y dan het verkeer onderwerg zou onderscheppen en omleiden naar server Z, waarbij er een niet geldig SSL certificaat zou worden ingezet.

Dan moet een kwaadwillende dus al weten dat de gebruiker QBittorrent gebruikt, en precies weten waar en wanneer de gebruiker een verbinding initieert, en vervolgens in staat zijn om het verkeer af te vangen en te routeren naar een gekloonde nepserver. Dat is iets wat al ontzettend uitzonderlijk is, en zou betekenen dat het om een hele bewuste en doelgerichte actie tegen iemand gaat.

Tot een paar jaar terug was SSL niet de standaard op internet en kon dit [theoretisch] sowieso met elke verbinding gedaan worden.

[Geekomatic]

Umm, gezien het soort servers waar qBittorrent zich gemiddeld mee verbindt
lijkt me dit in de praktijk niet een al te groot probleem...

Belankrijker is dat er niet met de inhoud van bestanden gesjoemeld kan worden,
maar dat is door cryptografische hashes goed afgedekt, toch?

[Reactie gewijzigd door Geekomatic op 2 november 2024 11:55]

[segil]

offtopic:
Windows defender blijft bij mij qbittorrent blokkeren. Ongeacht of ik het toevoeg aan de exclusion list, ik krijg dat niet gefixed.

[TeeDee]

Mooi he,open source. Iedereen kan meekijken met de code, en daarom is het veilig. ¯\(°_o)/¯

[iqcgubon]

De beste encryptie-algoritmes zijn open source net OMDAT iedereen kan meekijken...

[.MaT]

Ja, want dat gebeurd nooit in closed source

https://www.pcworld.com/a...ing-since-windows-95.html
https://threatpost.com/20...oft-windows-users/147336/

[Bor]

Wat een onzin. Lekken in software die je lokaal draait zijn ook lekken en niet alleen een theoretisch security issue, zeker niet wanneer het lek zit in het deel van het programma dat verantwoordelijk is voor de controle op veilige communicatie zoals hier. Lekken in software je "alleen lokaal draait" een theoretisch issue noemen en totaal niet boeiend

[Jazco2nd]

Maar 99.9999% gebruikt dat deel waar jij naar refereert helemaal niet. Je webUI draait gewoon lokaal, http. Komt geen SSL aan te pas. En de torrent verbindingen lopen ook niet over SSL voor zover ik weet.

[Bor]

De WebUI? Waar heb je het over? Deze kwetsbaarheid zit in de DownloadManager class.

The usages of DownloadManager across the program are extensive, and affect searches, .torrent downloads, RSS feeds, favicon downloads and more.

Heb je de bron ook gelezen?

Exploit Possibilities

Because all the Python installer exe URLs and update RSS feed URLs are hardcoded, they can be trivially enumerated and a malicious script in MITM context can attack every vulnerable version. Better, the RSS feed URLs provide a fingerprint for the software as there is no other reason to visit one of those URLs unless qBittorrent is running. This means mass surveillance programs like PRISM and equivalent can easily detect qBittorrent users via passive traffic monitoring. Then, because there is no cert validation, there is no need for expensive and complex deployments like QUANTUM to perform a Man-On-The-Side attack – you can just spoof the destination server.

Another aspect of the URLs being hardcoded is that an adversary can selectively intercept only requests from qBittorrent which do not verify the connection, instead of alerting a victim when his browser/other applications fails to securely connect to the internet.

Because this software is open source, it is trivial to add a backdoor to it and recompile, and therefore give a victim fully functional software, avoiding the victim’s suspicion.

Scripting possibilities, when used in conjunction with mitmproxy using `-s` to supply a python script:

Automated replacement of all Python exes with arbitrary exe: RCE with a single click
Automated replacement of all qBittorrent update URLs in RSS feed: Browser Hijacking/RCE with moderate user interaction
Automated replacement of all/specific links in qBittorrent RSS viewer: RCE until 2019, Download Hijacking

[Reactie gewijzigd door Bor op 2 november 2024 14:27]

[Jazco2nd]

Ik wist niet eens dat QB zelfstandig RSS feeds kon benaderen. Verder als ik het zo lees, gaat het om python executables. Zelf draai ik WB rootless in docker. Dan moet je wel een betrouwbare image hebben of zelf de boel compilen. Dan zit je wel goed.

Voor de typische Windows achtige gebruiker die QB als alles in 1 gebruikt met RSS feeds is het inderdaad zeker geen triviale vulnerability dus je hebt helemaal gelijk.

[Reactie gewijzigd door Jazco2nd op 3 november 2024 03:26]