Ongepatcht lek in QNAP-firmware laat mitm-aanvaller nas-apparaten overnemen

F-Secure zegt drie kwetsbaarheden ontdekt te hebben in QNAP-netwerkschijven. Wanneer een aanvaller deze drie kleinere kwetsbaarheden zou combineren, kan deze beheerdersrechten afdwingen. De kwetsbaarheid is al bijna een jaar bekend bij de fabrikant.

De kwetsbaarheid van de netwerkschijven begint bij het updateproces. Wanneer de drives contact zoeken met QNAP om te controleren of ze de nieuwste firmware draaien, gebeurt dat zonder versleuteling. Wanneer een aanvaller als man-in-the-middle zich voordoet als de server van QNAP, kan hij een valse firmware-update terugsturen die een aanvaller van buitenaf beheerdersrechten geeft. Daaropvolgend kan een kwaadwillende doen wat hij wil, zoals bijvoorbeeld wachtwoorden stelen.

Het Finse F-Secure zegt de kwetsbaarheid al in februari van 2016 gemeld te hebben aan QNAP, maar er is nog geen update voor verschenen. Op de F-Secure-blog stelt het bedrijf wel dat QNAP inmiddels werkt aan een oplossing. In diezelfde blogpost worden ook de technische details van de kwetsbaarheid uiteengezet.

Het beveiligingsbedrijf heeft zijn onderzoek en tests verricht met de QNAP TVS-663. Het bedrijf vermoedt echter dat meer dan 1,4 miljoen apparaten kwetsbaar zijn. Dat getal is gebaseerd op hoeveel apparaten er draaien op de firmware die de kwetsbaarheid heeft. Dat is QTS versie 4.2 en nieuwer. Getroffen gebruikers wordt aangeraden om in ieder geval het automatisch updaten van de nas uit te schakelen en met de hand eventuele updates van de site van QNAP zelf te halen.

QNAP Turbo vNAS TVS-663

Reacties (59)

[Mijzelf]

Drie kwetsbaarheden? Ik tel er 1, misschien 2, als je het niet beveiligen van het checken op een update en het niet beveiligen van het downloaden van een update als losse kwetsbaarheden ziet.

[tobias93]

Als je kijkt naar de bron vind je inderdaad 3 kwetsbaarheden die alle 3 los gefixt kunnen worden:
1. MITM vulnerability, zodat je verkeerde info aan de gebruiker kan voorspiegelen
2. Build-veld waar code in geïnjecteerd kan worden zodat deze in de browser uitgevoerd wordt
3. Server-veld waarmee code direct op de server uitgevoerd kan worden als de update geaccepteerd wordt.

Je moet dus de informatie veranderen, daarna een commando in het server-veld invullen zodat je toegang krijgt als dit uitgevoerd wordt en dan m.b.v. het build-veld de update direct starten zodat de gebruiker dit niet hoeft te accepteren. Valt hiervan een stap weg is de kwetsbaarheid een stuk lastiger te misbruiken.

[kodak]

Met als belangrijkste stap dat je aanvaller MITM moet zijn voordat die de kwetsbaarheden kan gebruiken. Als MITM op een netwerk kan is er meestal al meer fout dan dat je je alleen zorgen moet maken om deze kwetsbaarheden. Meestal niet een netwerk waar je een NAS in wil zetten.

edit:
Terechte opmerking van the_stickie dat MITM ook een upstream risico is. wmb maakt dat weinig verschil. Als je dat als reeel risico ziet doe je er goed aan om voor al je communicatie te bedenken of en hoe je dat via je upstream wil accepteren, niet alleen voor je NAS die het niet zo nauw neemt met accepteren van informatie.

[Reactie gewijzigd door kodak op 2 augustus 2024 06:22]

[the_stickie]

Het is dus geen heel handzame methode, maar wel prima geschikt voor gerichte aanvallen.

MITM wil niet persé zeggen dat men 'op jouw netwerk zit'. Verder upstream (provider, exchanges,...) zijn er nog genoeg mogelijkheden om het verkeer aan te passen om je eigen machine als QNAP server te vermommen.

[MrFax]

Juist. Dat het internet niet jouw nas kan bereiken betekent niet dat de jijzelf geen update verzoek kan uitvoeren via het internet.

Maar in het geval van updaten moet of je eigen netwerk of qnap zelf gehackt worden. Als het bij de ISP misgaat dan is dat toch wel wat anders.

[Reactie gewijzigd door MrFax op 2 augustus 2024 06:22]

[the_stickie]

Ik heb de details in deze niet onderzocht, maar mogelijk volstaat het aanpassen van een DNS request om de QNAP naar een rogue update server te verwijzen.
Dat kan op tientallen manieren.

[MrFax]

Ja maar uiteindelijk is het toch je eigen netwerk waarbij de DNS aangepast moet worden, of de isp.

[the_stickie]

jouw netwerk, dat van je isp, of enig ander netwerk waar het (dns)verkeer passeert. Ook de dns server zelf kan hiervoor misbruikt worden.

[CAPSLOCK2000]

Ik vermoed dat die updates geen digitale handtekening hebben.
Als dat wel zo is dan is het ook niet zo erg om ze via een onbeveiligde verbinding te downloaden. Je kan, als het goed is opgezet, lokaal controleren of die updates voorzien zijn van een digitale handtekening van de fabrikant. Veel Linux-distributies doen het zo omdat ze veel gebruik maken van gesponsorde servers om hun files te hosten. Die servers worden door externen beheerd en zijn dus eigenlijk niet te vertrouwen, daarom wordt er niet op HTTPS vertrouwd maar op digitale handtekening. Typisch wordt daar PGP voor gebruikt.

[BamSlam_]

Dit soort dingen zijn een van de redenen dat ik in mijn router normaal gesproken mijn NAS blokkeer van communicatie met het internet. De NAS is dan uitsluitend bereikbaar vanaf mijn interne huisnetwerk. Periodiek deblokkeer ik de NAS tijdelijk als ik via Tweakers heb vernomen dat er een software update is of om te kijken of er updates voor apps zijn.

[CAPSLOCK2000]

Het vervelende daarvan is dat updates dan niet automatisch geinstalleerd worden. Als mens loop je altijd achter de feiten aan. Tegen de tijd dat je uit het nieuws verneemt dat er iets aan de hand is dan is het al te laat. Een professionele beheerorganisatie heeft misschien mensen die alle security-kanalen volgen en zelf een inschatting maken maar voor particulieren is dat teveel gevraagd.
De realiteit is nu eenmaal dat consumenten niet de discipline hebben om vijf jaar lang regelmatig patches te draaien of in ieder geval te controleren of ze er zijn.

Ik adviseer daarom iedereen om automatische patches aan te zetten tenzij je betaald wordt om het met de hand te doen (=je bent professioneel systeembeheerder en weet wat je doet). Ik ben bang dat je met het uitschakelen van automatische updates meer kwaad doet dan goed.

Dat je NAS alleen via je LAN bereikbaar is helpt een hoop maar het is nog geen zekerheid. Er zijn aanvallen die daar rekening mee houden, dan hacken ze eerst je PC (bv via een besmette website) en vanaf daar scannen ze je interne netwerk en vallen ze de rest van binnen uit aan.
Als het echt belangrijk is moet je niet (alleen) op een firewall vertrouwen.

Tegelijkertijd snap ik ook wel dat je geen zin hebt in apparaten die op eigen houtje naar huis gaan bellen en zelf nieuwe software installeren met god weet wat voor nieuwe features of bugs. Persoonlijk los ik dat op door geen appliances te kopen maar alles zelf te bouwen op grond van Vrije Software die ik vertrouw en kan controleren. Ik besef me dat dat voor de meeste mensen geen optie is maar voor mij gelukkig wel.

[BamSlam_]

Daarom staat mijn NAS ook altijd standby en zet ik hem alleen aan als ik echt iets wil backuppen. Ja, inderdaad, ik gebruik hem als backupschijf en niet als online storage waarbij de uptime redelijk gegarandeerd is.

[SED]

Harde schijven regelmatig aan en uitzetten in backup sistuaties waarbij consistentie en continuiteit essentieel zijn is geen goed idee. De meeste schijven draaien jaren probleemloos maar haperen bij het inschakelen. Dat is dus iets wat je moet beperken tot slaapstand in een nas.

[Barryke]

Als je je NAS zo wil gebruiken kan je nog een stap verder gaan door standby te vermijden - en het ding echt uitzetten, zodat je alle stekkers er uit kan trekken zodat het een "offline backup" is.. denk aan blikseminslag.

[Mijzelf]

Dit soort dingen zijn een van de redenen dat ik in mijn router normaal gesproken mijn NAS blokkeer van communicatie met het internet.

Het vervelende daarvan is dat updates dan niet automatisch geinstalleerd worden. <snip> Tegen de tijd dat je uit het nieuws verneemt dat er iets aan de hand is dan is het al te laat.

Wat maakt dat uit? Een apparaat dat niet via het internet te benaderen is, heeft ook geen security updates nodig.

[CAPSLOCK2000]

Wat maakt dat uit? Een apparaat dat niet via het internet te benaderen is, heeft ook geen security updates nodig.

Omdat de computer waarmee je dat apparaat wel benadert met een virus besmet kan zijn.

Daarnaast is het meestal verstandig om ook non-security updates te installeren. Het zou zonde zijn om data te verliezen door een bug in de firmware van je NAS.

[Keypunchie]

Wat maakt dat uit? Een apparaat dat niet via het internet te benaderen is, heeft ook geen security updates nodig.

Defense-in-depth.

Wat als de aanvaller al in je netwerk is gekomen? Wat als je router onveilig blijkt (zie laatst Netgear perikelen)?

[Anonymoussaurus]

Hoezo? Je kan toch gewoon prima het automatisch zoeken naar updates uit zetten? Dan ben je niet kwetsbaar, en ben je dus enkel kwetsbaar als je handmatig gaat zoeken, en dan moet je ook nog eens de dikke pech hebben dat er net een aanvaller tussen jou en de server zit.. Lijkt mij een hele kleine kans. Je methode zorgt natuurlijk wel voor extra zekerheid en veiligheid.

[BamSlam_]

Dat van die updates is een ding. Door het ding te blokkeren van internetaccess mitigeer ik ook de mogelijkheid dat het ding van buitenaf gehackt wordt en onbevoegden toegang tot mijn data krijgen.

[Anonymoussaurus]

Klopt, dat is natuurlijk wel lekker veilig. Je gooit hem natuurlijk alleen online als je uit je huis gaat, en dat je weet dat je hem nodig gaat hebben, of als je natuurlijk thuis zit.

[tweaknico]

Wat is er mis met een VPN verbinding naar huis en het apparaat dan lokaal benaderen?... Geen directe internet access nodig dus.
Zo zouden ook alle Philips Hue, Nest etc. etc. moeten werken, daar zit nu overal een MITM tussen.

[Anonymoussaurus]

Maar ik zeg ook niet dat er iets mis met een VPN verbinding. Wie heeft het hier überhaupt over een VPN verbinding? Daar hadden BamSlam_ noch ik het over .

[tweaknico]

Ehm, ik dacht even dat het over veilige toegang van af het internet naar je NAS ging... maar ik kan me vergist hebben... in dat geval sorry.

Maar als het toch over veilige toegang van af Internet @ large naar je prive LAN gaat dan kan een VPN van bv. mobiel of remote locatie naar jouw CPE of VPN gateway een perfecte oplossing bieden.

(VPN's zijn niet alleen OUTBOUND, je kunt ook je eigen "on premises" IPSEC of OpenVPN service gebruiken).

[Anonymoussaurus]

Ja, daar ging het ook over, maar het ging helemaal niet om een VPN. Het ging puur om het afschermen van je NAS op het internet, en dat heeft niks met een VPN te maken.

[tweaknico]

Ik gebruik een VPN om een betrouwbare verbinding naar Huis te maken, Over die VPN kan ook de NAS bereikt worden, buiten die VPN niet.

Jij denkt bij VPN geloof ik dat er een 3e partij bij hoort voor downloaden oid... Helaas die VPN bedoel ik niet.
Er draait een VPN SERVER, geen client, op mijn firewall, waarmee ik vanuit andere locaties een betrouwbare verbinding kan maken.

Dus het gaat nog steeds over afschermen van m'n NAS en tegelijk zorgen dat IK er op een betrouwbare manier bij kan.

[Anonymoussaurus]

Ik gebruik een VPN om een betrouwbare verbinding naar Huis te maken, Over die VPN kan ook de NAS bereikt worden, buiten die VPN niet.

Jij denkt bij VPN geloof ik dat er een 3e partij bij hoort voor downloaden oid... Helaas die VPN bedoel ik niet.
Er draait een VPN SERVER, geen client, op mijn firewall, waarmee ik vanuit andere locaties een betrouwbare verbinding kan maken.

Dus het gaat nog steeds over afschermen van m'n NAS en tegelijk zorgen dat IK er op een betrouwbare manier bij kan.

Dan heb ik je inderdaad verkeerd begrepen, maar dat komt omdat we het eerst over de situatie van BamSlam_ hadden, en niet over jouw situatie .

Maar goed.. even pratende over jouw situatie dan maar:

Dat met die VPN is een veilige methode om je NAS te benaderen inderdaad (want je moet jezelf dan in feite 2 keer identificeren, want inloggen). Als jij zegt dat er een VPN server draait... dan bedoel je dus gewoon een VPS .

[tweaknico]

Gewoon een echte server geen Virtual Private Server..
niet op colocate. Zoals waarvan je Auuuuuu roept als het op je tenen valt.

En wat ik kan kan in feite iedereen, zeker als je een veilige verbinding naar thuis spul wil hebben, bv. NAS, of andere IoT bediening. Nergens een MITM voor nodig (zoals voor Philips Hue, Nest etc.)

[Reactie gewijzigd door tweaknico op 2 augustus 2024 06:22]

[Anonymoussaurus]

Maar ook dat noem je geen VPN, maar een dedicated server .
Dat weet ik, maar ik betwijfel of dat bij élke router kan (dan praat ik vooral over de flut routers van providers).

[tweaknico]

Ahem, de verbinding tussen bv. mijn mobiel en mijn server loopt over VPN (Virtual Private Network) , tools in gebruik zijn: IPSEC (laptop -> home) of OpenVPN (what's in the name) (telefoon ->naar home)
Het betreffende systeem is verder verbonden met andere systemen van collega's dmv. IPSEC verbindingen.
Dus VPN. En dat is gebruikte technologie die overal toepasbaar is.
In het geval van OpenVPN relatief eenvoudig maar het rand de IP specificaties enigszins aan, IPSEC is niet lastiger, maar komt wat minder bekend over als je weinig met netwerk-lagen onder laag 7 te maken hebt.

Voor OpenVPN kun je een tool instaleren op elk willekeurig systeem poort forward is voldoende, als je routers hebt als Draytek, Zyxel etc. die kunnen MINSTENS, 2 IPSEC tunnels aan. (Voor SSL tunnels [ niet helemaal openvpn ] heb je licenties extra nodig).

[Anonymoussaurus]

Aha... Nu snap ik wat je bedoelt ja... Ik dacht de hele tijd dat je het had over dat je een eigen VPS had, maar je had het steeds over een VPN. Maar ja, softwarematig met een VPN verbinden, dan snap ik hem ja . Dacht dat je de hele tijd wilde zeggen dat je een eigen VPN of VPS had.

Maar natuurlijk weet ik wat een VPN, IPSec, VPS, SSL etc is. Het was gewoon de miscommunicatie (want je kan de zinnen op meerdere manieren lezen).

Port forwarding hoef je natuurlijk niet te doen als UPnP is ingeschakeld, maar veilig is dat natuurlijk niet. OpenVPN gaat volgens mij sowieso via SSL tunnels.

[tweaknico]

uPNP is bij alle installaties waar ik bij betrokken ben disabled.
Safety first... OpenVPN kan ook over UDP (te prefereren ==> geen SSL Tunnel). OpenVPN over TCP breekt allerlei aannames die in UDP zitten mbt. (mogelijk gewenste packet loss).

Vandaar voorkeur voor IPSEC (follows all IP specs) , OpenVPN over UDP en als laatste pas OpenVPN over TCP, SSLtunnels.
Voor SSL Tunnels is er aparte software ( stunnel )

(noot: ik ben niet over VPS begonnen... en VPS != VPN Server)

[Anonymoussaurus]

Dat ligt er natuurlijk maar net aan. Voor FTP ga je natuurlijk geen TCP gebruiken.. en al helemaal niet via VPN, want dan duurt het natuurlijk een eeuwigheid. Het ligt er dus maar net aan wat je doet via die die tunnel/VPN.

Ah, ik had het letterlijker moeten lezen, dat "VPN server". Maar waarom zeggen "VPN server" in plaats van "VPS"? Komt inderdaad toch gewoon op het hetzelfde neer? Is net zo makkelijk .

[tweaknico]

Nee, het is niet hetzelfde, een VPS (Of het is (dat is nu eenmaal de pest bij afkortingen)
a: (Virtual Private Server) is een VM met console access in bij een hosting bedrijf.
b: Virtual Private Service [ een service in een Failover Linux Cluster , beschikbaar op meerdere nodes] gerelateerd aan VIP (Virtual IP adres).

FTP is een TCP service.... Een tunnel hoort transparant te zijn
voor de data die er doorheen gaat. En UDP verkeer hoort lossy te kunnen zijn als recovery model, maar is dat niet over een TCP/OpenVPN tunnel.

[Anonymoussaurus]

Ik bedoelde VPS als Virtual Private Server. Ik had het dus niet over een Virtual Private Service .

Ik vind het nogal onlogisch waarom FTP van TCP gebruik maakt. Het was TFTP dat gebruik maakte van UDP. Hetzelfde met video's: waarom is dat UDP? Als er een pakketje is verstuurt, maar die is 'corrupt' of is beschadigd, dan laat UDP dat pakketje gewoon lekker vallen, maar dan lijkt het mij dat de frames ook worden gedropt die in dat pakketje zaten.

[tweaknico]

Klopt, bij video en audio is het wachen op een retransmit veel duurder (gedwongen pauze) dan het laten vallen van een fragment.
bij Audio kan bij toepassen van de juiste codec (bv GSM) loss tot 50% oplopen terwijl het geluid blikkerig klinkt.

Bij video zitten er elke X frames een full screen beeld is zodat bij veel loss er tenminste elke 2 a 3 seconden herstel kan plaats vinden.
Bij falen krijg je dan het befaamde "blokjes" beeld waarbij delen verkeerd bijgewerkt worden. Daar valt een verstoring wel meer op.
(Daarnaast is door de kleine blokjes een aanzienlijke besparing op bandbreedte mogelijk, video Codecs implementeren dat)

TFTP is om andere redenen in UDP uitgevoerd, TFTP is voor ondersteuning van Boot processen, waarbij er geen Operating system is om zaken te regelen, het is dus het meest minimale om een OS te kunnen laden vanuit een BIOS. FTP heeft uitgebreide mogelijkheden om ook vertalingen te kunnen doen van tekst bestanden (ASCII vs. BINARY transfers). etc.
Kortom TCP is gunstiger voor het verzenden van streams dan data, ivm aanpassen aan beschikbare latency en bandbreedte.
Onderdeel daarvan is recovery van loss op link niveau, en vereist daarvoor wat afstemming (Setup, Shutdown, Acks).
UDP is gunstiger voor eenvoud maar vereist herstel op applicatie niveau en dat is soms handiger, bij real time data door loss te accepteren, op andere plekken door wel de vraag opnieuw te stellen (DNS). UDP is meer Vraag/Antwoord pingpong.

[jozuf]

Het is een klein laagje extra veiligheid maar garandeert helemaal niets. Er zijn zat andere apparaten in je lan die wel toegang hebben, naar ik aanneem. Die kunnen dan prima als eerste hop worden gebruikt om je netwerk in te komen en vervolgens verspreiden naar andere apparaten.
Het enige wat je nu doet is 1 van de mogelijke hops eruit trekken. En dat is nog wel een hop die op Linux draait. Persoonlijk zal ik de Windows machines een stukje gevaarlijker achten (mede door het type gemiddelde gebruiker die achter die dingen zit).
Ik zou de focus zelf dan ook niet zozeer leggen op je nas, maar vooral/ook op andere apparaten in je netwerk die ws veel gevoeliger zijn.

[Reactie gewijzigd door jozuf op 2 augustus 2024 06:22]

[DennusB]

Jammer dat ze er zo lang over doen. Wat dat betreft is Synology echt VEEL beter met z'n update beleid!

[Amiga3000]

Die heeft toch ook al een keer ransomware problemen gehad.

nieuws: Synology: ransomware treft alleen ongepatchte systemen

http://www.synology-forum...gepast!-ransomware-locky/

dus helaas komt het daar ook voor.

Gewoon zelf je updates downloaden

[SED]

Zeker, maar daar was wel een patch beschikbaar en in dit geval is er al een jaar lang geen reactie.
dat maakt het een stuk serieuzer.
In dit geval is er dus geen update bij Qnap te downloaden en staa thet gat voorlopig nog wagenwijd open.

[R4gnax]

Die heeft toch ook al een keer ransomware problemen gehad.
dus helaas komt het daar ook voor.

Dat was iets heel anders. Een echte vulnerability in een aantal services, die misbruikt kon worden als je NAS direct vanaf het internet toegankelijk was.

Dit was niet zoiets uitermate onprofessioneel knulligs als geautomatiseerd firmware updates downloaden via een onbeveiligde verbinding en deze te installeren zonder extra maatregelen te treffen zoals het verifiëren van een aan het update file vebonden digitale handtekening.

[Reactie gewijzigd door R4gnax op 2 augustus 2024 06:22]

[jozuf]

Of gewoon je eigen nas bouwen al die honderd in een dozijn apparaten zijn veel te aantrekkelijk om je peilen op te richten. Dat itt een eigen ingerichte server die vrij specifiek gaat zijn qua mogelijke beveiliging issues. Afhankelijk van de persoon die het inricht (en moet je als aanvaller dan ook specifiek targetten ipv een gat wat in apparaat x of firmware y zit) .
Met de klap op de vuurpijl is dat ook nog is goedkoper, krijg je meer performance voor minder en heb je veel meer mogelijkheden.

[Reactie gewijzigd door jozuf op 2 augustus 2024 06:22]

[glatuin]

Slecht weer allemaal. Goede nieuws is dat deze berichtgeving QNAP zal dwingen hier ites aan te doen. Intussen zelf maar gauw de automatische update uitgezet. Ik moet zeggen ik download dankzij de snelle meuktracker de firmware toch al meestal zelf.

[ThaJens]

Na bijna een jaar nog niet geüpdate? Erg jammer weer.

[Verwijderd]

Bewijst maar weer eens dat bedrijven beveiliging niets interesseert. Ik denk dat er daarom een soort beperkte aansprakelijkheid moet komen voor beveiligingsfouten.

[hiostu]

Na alle meldingen over ransomware die ook qnap en synology nassen konden besmetten, heb ik besloten om mijn NAS maar uit te laten als ik hem niet gebruik. Dat voelt toch veiliger voor mijn backups

[eevh]

Inderdaad, hier alleen even aan voor af en toe een backup van wat foto's.

[Verwijderd]

Inderdaad, hier alleen even aan voor af en toe een backup van wat foto's.

Dan lijkt me een USB harddisk toch echt wat handiger.

[hiostu]

Ja maar de qnap had ik al en daarin zitten ook meteen 2 schijven die gemirrord zijn.

[Sayko]

Weinig verschil met USB kabel in het poortje steken

Shoot was voor eevh

[Reactie gewijzigd door Sayko op 2 augustus 2024 06:22]

[eevh]

Niet altijd, want die hangt niet standaard aan het netwerk.
Aan/uit-knopje NAS is zó ingedrukt en zit op altijd op dezelfde plek itt tot mijn USB'tjes.

[Rembert]

Onze huis-NAS zet ik thuis aan met de Synology app: wake-on-lan. Ben ik op de zaak en heb ik iets van de thuis-NAS nodig, dan VPN ik naar huis. Met de fritz-box kan ik dan een wake-on-lan request sturen naar de NAS en een paar minuten later draait het ding. Ik gebruik zelden de aan/uit-knop.

[Sayko]

Ik merkte al een shitload aan attacks vanuit voornamelijk Vietnam op mijn qnap afgelopen maanden. Meteen maar de verbinding vanuit de buitenwereld uitgezet. Blijf de logfiles even schuldig. Snel een router met VPN fixen hier

[666stokstaartje]

En ik maar denken dat ik met sterk wachtwoord goed zit Okay 24/24 online gaf me al geen 100% veilig gevoel. Maar toch; ik ga het automatisch updaten uitzetten. En, in navolging van een aantal van jullie, gebruik ik vanaf mijn lan vanaf nu de magic bullit als ik er iets van nodig heb of op wil slaan. Spaart nog energie uit ook (Hoef dus niet eens naar dat aan/uitknopje te lopen )

Edit: aanvulling met laatste zin.

[Reactie gewijzigd door 666stokstaartje op 2 augustus 2024 06:22]

[mutley69]

Kan je dat niet patchen door zelf iets in /etc/hosts te zetten zodat ie tijdelijk niet meer zichzelf kan patchen tot er een fix is? Of knal die servers zelf in /etc/hosts?

[mjl]

Kwestie van automatisch update checken uitzetten en updates handmatig downloaden van de QNAP site.

Auto update zat al niet in QTS 4.2. Alleen het checken van de aanwezigheid en als de user dan toestemming geeft wordt de firmware pas gedownload en na nog een bevestiging geïnstalleerd. Met de kwetsbaarheden kan dan dus met de eeeste user actie een malware firmware worden gedownload en wordt dan meteen geïnstalleerd.

[tobias93]

edit: niet goed gelezen

[Reactie gewijzigd door tobias93 op 2 augustus 2024 06:22]