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

QNAP geeft firmware-update vrij die man-in-the-middle-kwetsbaarheid oplost

Door , 36 reacties, submitter: slopert

QNAP heeft afgelopen weekend een update van zijn QTS-firmware uitgebracht, waar veel van zijn nas-apparaten op draaien. De patch dicht een kwetsbaarheid die het mogelijk maakte voor een aanvaller om met een mitm-aanval gebruikersgegevens te stelen.

QTS 4.2.3 build 20170121 is de versie waarin het euvel opgelost moet zijn. Naar schatting van F-Secure, dat het probleem aan het licht bracht, draaien meer dan 1,4 miljoen apparaten in de praktijk op de QTS-firmware. Het is echter niet bekend hoeveel verschillende modellen precies op QTS draaien en of deze op het moment van schrijven ook allemaal al de nieuwste versie van het os kunnen downloaden.

Het Finse securitybedrijf F-Secure maakte de kwetsbaarheid vorige week wereldkundig. Op dat moment zaten de beveiligingsgaten nog steeds in de QNAP-producten. Hoewel het normaal gesproken niet de bedoeling is om een dergelijk gevaar aan de grote klok te hangen voordat het opgelost is, zeggen de Finnen dat ze het beveiligingsgat al bijna een jaar geleden bij QNAP hadden gemeld, maar dat er sindsdien niets gebeurd was.

Het probleem met QTS was dat er zonder versleuteling door de nas-apparaten contact gezocht werd met de updateserver. Als dit verzoek onderschept werd en een vervalste reactie teruggestuurd wordt, kon een valse firmware-update geïnstalleerd worden die een aanvaller van buitenaf beheerdersrechten geeft, waarna hij of zij vrij spel heeft en bijvoorbeeld gevoelige gegevens van een eigenaar kan stelen.

QNAP Turbo vNAS TVS-663

24 januari 2017 14:50

36 reacties

Submitter: slopert

Linkedin Google+

Reacties (36)

Wijzig sortering
Mij staat bij dat dit een tijd geleden ook hier in het nieuws was. De consensus was toen dat het niet zo heel spannen was. Hoe zijn de meeste NASjes aangesloten? Bedraad. Dan bedraad via router het www op, op zoek naar een update server. Dan ben je dus al buiten je eigen netwerk; dan is er dus van alles mogelijk... Ik snap wel dat QNAP dit issue niet de allerhoogste prioriteit heeft gegeven. Ik heb er in ieder geval rustig om geslapen al die tijd ;) (mijn NAS mag overigens al nooit zelfstandig updaten; dat wil ik als baasje altijd zelf beslissen op basis van de changelogs).
Anders is een mobiel device dat via willekeurig welk open wifi netwerk contact zoekt met een update server; dat zou zeker wel gevolgen hebben voor mijn nachtrust, als ik niets zou doen dan...
Algemeen: we moeten ook niet bij ieder bericht over mitm en andere 'beveiligingsgaten' gelijk het ergste denken. Soms moet een 'hacker' al zoveel inspanning verrichten en toegang hebben tot zus en recht hebben zo... Logisch nadenken, risico's beoordelen en eventueel actie nemen.
Nou, dat het voor jou niet zo spannend is wil nog niet zeggen dat het voor anderen ook weg te wuiven is he? ;) Jij slaat er je vakantiekiekjes en de filmpjes van de kinderen en je belastingaangifte op, een zorginstelling misschien wel patientgegevens.

Je schrijft " buiten je eigen netwerk; dan is er dus van alles mogelijk", dat klopt dus niet als ze wel fatsoenlijk een beveiligde verbinding hebben gebruikt. Dan kan je gewoon een certificate controleren, en weet je NAS dus ook dat de server waar 'ie mee praat ook de goeie is. Dat doorbreek je niet zomaar, degene die dat wel lukt zet dan heel SSL op losse schroeven.
Ik maak inderdaad een afweging voor mijzelf. Met de data die op de NAS staat, wil ik dat de NAS direct verbonden is met het www? Moet ik anders iets met de data, of met de verbinding of whatever. Dat is in mijn beleving onderdeel van de 'risico inventarisatie'.
Algemeen: Het zou fijn zijn wanneer meer mensen denken in risico en kansen en deze afwegen, en hier acties op afstemmen. Dan reactief in actie komen of reageren wanneer het ergens een keer is mis gegaan.
Onze computers hebben legio verbindingen buiten ons eigen netwerk die niet via ssl of https gaan. Voor de grap maar eens een uurtje loggen tijdens het surfen ofzo. Of wanneer de kinderen met vriendjes of vriendinnetjes op het internet zich vermaken. Tel dan voor de grap eens het aantal requests dat wordt gedaan, en welk deel daarvan via een beveiligde verbinding gaan.
Ik wil je niet bang maken hoor, alleen aangeven dat we wel realistisch moeten blijven :9 .
Ik zit in de security-hoek, dus ik denk hier inderdaad in risico's en kansen. Mooie mogelijkheid dit. Zou zo'n NAS een gedownloade firmware ook checken op geldigheid? Waarschijnlijk niet, en da's kinderlijk eenvoudig getest. Dat betekent dat ik nu een goeie attack vector heb om bijvoorbeeld ransomware op NASsen te krijgen, of lid te maken van een botnet. Natuurlijk moet ik moeite doen om een NAS zover te krijgen met mij te praten, maar bij high-value doelen als een ziekenhuis of een onderwijsinstelling of een bedrijf met een R&D afdeling kan die moeite best weleens lonen.

Hoe realistisch is dat? Dat is een afweging die gebruikers, particulieren & bedrijven, voor zichzelf moeten maken. Is het aan afweging die QNap zelf voor al haar gebruikers kon maken? Nee, dat denk ik niet.
Natuurlijk is er een controle op de integriteit en herkomst van firmware. Die voldoet per merk aan strenge regels en alleen al om het flashen van een corrupte firmware te voorkomen een essentieel middel.
Het bouwen van alternatieve firmwares is dus een bewerkelijk proces waarbij het signeren van het eindproduct met een certificaat tot de standaarden zal behoren.
Gehackte firmware maakt ook meestal gebruik van een tussenloader om de controles te vermijden. Dat kan niet via een MITM aanval gebeuren maar is een fysieke handeling.

Dat Qnap hierop een vreselijke slechte uitzondering is valt dan ook erg op.

[Reactie gewijzigd door SED op 25 januari 2017 12:40]

Dat doorbreek je niet zomaar, degene die dat wel lukt zet dan heel SSL op losse schroeven.

Update checks zelf hoeven bovendien niet eens perse over HTTPS te gaan. Immers HTTPS is best te omzeilen tenzji je ook zaken als key-pinning gebruikt. Ook in bedrijfsomgevingen is het heel normaal om HTTPS te onderscheppen, decoderen, controleren op malware, bedrijfsgeheimen of zaken die juridisch moeten worden gecontroleerd (o.a. in financiele sector niet ongewoon), en na controle weer hercoderen.

Wat het werkelijke lek is, is dat er kennelij geen certificaat-controle plaats vond. Let wel, uiteraard wil je ook HTTPS, maar De Basis van update secuity is ondertekening en controle van deze handtekening van de updates zelf. Kennelijk gebeurde ook dat niet.

Dubbele faal dus.
Dat inbreken op HTTPS is dus gewoon een MITM aanval. (via een HTTPS/HTTPS back2back proxy).
En dat is met een wildcard certificaat (en prive ondertekent ook makkelijk te doen),
je kunt immers je eigen CA opzetten hiervoor, en het CA certificaat als betrouwbaar markeren op systemen waar je controle over hebt.

Overigens zullen browsers als Chrom(ium|e) of Firefox heir wel over klagen omdat die uitgebreidere certificaat controles uitvoeren.
Overigens zullen browsers als Chrom(ium|e) of Firefox heir wel over klagen omdat die uitgebreidere certificaat controles uitvoeren.

Nee, want die controles worden juist om deze technieken mogelijk te maken volledig door Google (en ik dacht ook Mozilla) uitgeschakeld voor intranet doelen _/-\o_ Die proxy is immers een intranet-adres.

Overigens voert Google juist minder controles uit dan andere browsers. Enkel betreft enkele Google sites zelf doen ze aan certifciaat-pinning. Maar het gros wordt enkel op validiteit gecontroleerd aan de hand van de centrale OS database (van Microsoft igv Windows), hetgeen minder is dan alle aneder browsers (muv Safari) doen.
Een proxy hoeft geen intranet adres te hebben.
Nee, technisch niet maar meeste zo niet alle bedrijfsproxies in deze context zijn dat wel. Immers, anders is het nut van controle wat beperkter omdat de data technisch reeds het bedrijfsnetwerk verlaten heeft.

Plus zoals gezegd, als het internet is, allerlei zaken zoals EMET's en Chrome's certifciaat-pinning veel roet in het eten gooien.
Dus je hoeft in een land als turkije/iran/egypte etc. alleen maar een "intranet" IP adres (10.xx.x.x) te gebruiken er is geen certificaat controle meer?....

Dat levert pas een bron voor afluisteren op, En de NL overheid heeft ook geen probleem meer voor afluisteren, gewoon providers een "intranet" adres laten uitgeven en alles via een Proxy laten lopen.

Ik ga nog een kijken hoe dit zit maar het lijkt mij onwaarschijnlijk.
Dus je hoeft in een land als turkije/iran/egypte etc. alleen maar een "intranet" IP adres (10.xx.x.x) te gebruiken er is geen certificaat controle meer?....

De certifciaat-pinning van o.a. Chrome wordt inderdaad volautomatisch uitgezet. Dat is logisch, want hoe anders kun je Chrome gebruiken in een intranet omgeving waar je alle HTTPS wil onderscheppen.

Merk op dat dit enkel gaat om bedrijfs-computers, niet jouw eigen prive-laptop of telefoon. (Tenzij je die enrollt via intune of zo in het bedrijfsnetwerk, waarna instellingen en intranet-proxy certificaat automatisch op jouw apparaat geplaatst worden.).

Het is ook geen gevaar, want enkel jouw bedrijf kan de versleutelde encryptie breken. Niemand anders. Als je jouw bedrijf niet vertrouwt, moet je gewoon geen prive zaken op je bedrijfscomputer doen. Iets wat bij dat soort bedrijven dikwijls toch al verboden is ... O-)

Terug naar het onderwerp: om die reden moeten updates zélf altijd ondertekend zijn. HTTPS is een extraatje dat nuttig is, maar niet strikt noodzakelijk.
De certifciaat-pinning van o.a. Chrome wordt inderdaad volautomatisch uitgezet. Dat is logisch, want hoe anders kun je Chrome gebruiken in een intranet omgeving waar je alle HTTPS wil onderscheppen.
Omdat je DAT dus eigenlijk niet wil, HTTPS onderscheppen.
Dat wil je dus wél als bedrijf. O.a. om te voorkomen:

- dat malware encrypted binnen komt
- bedrijfsgeheimen encrypted naar buiten gaan
- het vaak ook een juridische verplichting is. O.a. in de financiele wereld ivm handel in voorkennis.

Jij wilt niet dat *jouw* data gelezen wordt door derden. Zo wil een bedrijf dat ook niet, maar heeft er geen probleem meer om haar eigen data te kunnen lezen. Sterer nog, men wil alle data die het bedrijf in en uit gaat kunnen lezen.

Jij denkt teveel vanuit als ik nu mijn prive zaken op de bedrijfscomputer doe, kan het bedrijf meelezen. Dat klopt. Vandaar ook dat ik schreef: "Als je jouw bedrijf niet vertrouwt, moet je gewoon geen prive zaken op je bedrijfscomputer doen. Iets wat bij dat soort bedrijven dikwijls toch al verboden is ... O-) "
Bij een eenmans zaak kun je stellen dat Bedrijfs problemen = prive problemen (en omgekeerd).... maar dat even ter zijde.

"Mee lezen" op sessie kan beter goed op de endpoints geregeld worden. Verspreiden van data KAN (en ZAL) eerder via andere wegen lopen, en als je daar bang voor bent dan moet er een platform voor inrichten: WerkPC praat met Platform, Platform praat met de buiten wereld... (Of je dan intern wel/geen HTTPS gebruikt is NIET relevant).

De zaak inrichten dat er een MITM KAN zijn ==> dat er ook misbruik van gemaakt zal worden. Dat kan dan ook intern omdat je ook INTERN niet meer zeker kan zijn dat het juiste certificaat gebruikt wordt. (Extra Proxy, of 2 extra, op de lijn...)

Overigens HTTPS kan 2 way gebruikt worden, het kan ook als Authenticatie gebruikt worden, dwz. dat een Client certificate noodzakelijk is voor maken van verbindingen, en dat kan op deze manier zeker niet werken.

Daarnaast ben ik niet bang voor meelezen vanuit bedrijven, maar een bank transactie van afd. Finance mag toch niet on the fly gemodificeerd kunnen worden? Of Hoop je dat de Proxy beheerder niet een Bank transactie onderschept, en splitst in een extra overboeking naar een overzeese rekening.

Encryptie beveiliging heeft geen grijs gebied, er is niet een beetje encryptie... of zwakke encryptie oid, het is er WEL of het is er NIET.
Een beetje kapotte encryptie => er is geen beveiliging.

(Oh en een workaround..., voordat een bestand via [non-]HTTPS verzonden wordt, eerst even door aespipe halen ( http://loop-aes.sourceforge.net ) of aescrypt ( http://www.aescrypt.com/ ) halen.)

[Reactie gewijzigd door tweaknico op 27 januari 2017 11:26]

Mijn reactie gaat dan ook niet inhoudelijk in op het risico, kans of impact.
Ik vind het een blunder dat hierover niet is nagedacht door QNAP (security by design).
Daarnaast ben ik van mening dat security issues oplossen altijd een prioriteit zou moeten zijn (onafhankelijk van r x k).
ff ergens wat DNS poisoning bij een ISP doen en je hebt plots het beheer over een hoop nasjes die zelf bij jou langskomen om te checken of je malware in de aanbieding hebt. Lijkt me dat dit wel wat gevaarlijker is dan jij inschat
Een tijd geleden, 7 dagen terug, om precies te zijn.
Het is ook geen rocket science om te bedenken dat mitm die hier nodig is niet heel realistisch is. En als iemand dat al kan uitvoeren heb je grotere problemen.

Het is inderdaad niet netjes dat een fabrikant een beveiligingsprobleem een jaar weet te negeren. Maar wat belangrijker is, is voorkomen dat je er bij je volgende aankoop weer mee te maken hebt. Je kan een fabrikant voortaan wel negeren, maar daarmee voorkom je geen toekomstige problemen als je niet weet wat je alternatieven zijn die wel aan je eisen voldoen. Hoe ga je nu zorgen dat je wel een fatsoenlijk alternatief hebt? Op basis van hoop?
Noem eens een paar andere hardware leveranciers die producten van 2011 nu nog volledig ondersteunen? Mijn qnap 419 krijgt deze update ook nog.

Samsung S2 (i9100)? Nee, niet meer door samsung. Zie de juig stemming eens dat lineage deze nog wel ondersteunt: nieuws: Lineage maakt bekend welke toestellen builds van CyanogenMod-opvolger...
Samsung tab2 (10 inch, p5110)? Nee, niet meer door samsung, niet eens meer door cyanogen sinds afgelopen augustus
Apple dan: Ipad 2? nee, ook die niet meer sinds afgelopen september.

Ik heb geen synology nas maar volgens mij is de DS411 vergelijkbaar: 4 slots en uit 2011. Die krijgt ook nog updates. Dat zou een alternatief kunnen zijn.
Je kan ook je eigen NAS bouwen met Windows, een Linux distro of OS X, die worden veel langer nog gepatched. Zeker in het geval van 4-bay NASsen is het prijsverschil maar klein.

[Reactie gewijzigd door Dreamvoid op 24 januari 2017 20:50]

NAS4Free en FreeNAS zijn dan de betere versies om aan te raden. :)
niet te vergeten de geweldige support van de helpdesk, want eerlijk is eerlijk de support afdeling verdiend alle lof. mijn 5 jaar oude 410+ had een defecte harddisk, tijdens het rebuilden had ik stroomuitval. waardoor een andere harddisk de smartstatus 'bad' kreeg en het rebuilden echt mega traag ging.

sávonds met de helpdesk gemaild (in het engels) en de volgende dag in het nederlands of ze via Teamviewer even mee konden kijken _/-\o_
(naderhand werkte alles en ook de slechte disk vervangen)
"[F-Secure Senior Security Consultant Harry Sintonen] notified QNAP about these issues in February 2016. However, to the best of Harry’s knowledge, they’ve yet to release a fix (although QNAP claims to be working on one)."
https://safeandsavvy.f-se...lity-research-to-survive/

Waar haal jij vandaan dat QNAP deze melding heeft genegeerd?
Euhm, het staat letterlijk in het artikel
... zeggen de Finnen dat ze het beveiligingsgat al bijna een jaar geleden bij QNAP hadden gemeld, maar dat er sindsdien niets gebeurd was.
en het is ook wel af te leiden uit je eigen quote: "they've yet to release ..."

Kan me ook niet voorstellen dat QNAP een jaar nodig heeft om een dergelijke fix te voorzien

[Reactie gewijzigd door Kenhas op 24 januari 2017 15:38]

Voor mij zijn 'negeren' en 'ergens mee bezig zijn' twee compleet verschillende zaken; voor jou wellicht niet, maar dat is dan voor jouw rekening...
Als het een jaar duurt, komt dat bij mij over als "negeren". En nu het publiek bekend gemaakt werd door F-Secure hebben ze opeens binnen een week een patch :?

Het is allemaal perceptie natuurlijk. Bij mij komt het over als dat ze het probleem een jaar genegeerd hebben en nu het bekend is, schieten ze in actie.
Misschien moet je gewoon T.net's bron lezen, je weet wel die waar ik zo handig een link naar bijvoeg...

PS. Ik heb je niet gedownmod, iets met waard en gasten...
Tja....
1. Ik reageer op de inhoud van een artikel op Tweakers.
2. In jouw eigen quote staat precies hetzelfde: "... notified QNAP about these issues in February 2016".
offtopic: Volgens mij kun je reacties na jouw reactie in dezelfde tree niet modden.
Ben verder wel behoorlijk tevreden met QNAP NAS, maar inderdaad. Dit hoort niet te gebeuren.
Dit is trouwens niet de eerste keer dat QNAP veel te lang wacht met oplossen van (critical) bugs en dichten van gaten hoor . Samba critical bug paar jaar geleden , openssl versie van 12 jaar oud die ze gebruikten toen heartbleed dringend gepatched moest worden enzovoort . Ik onthoud het allemaal niet meer .

Ik heb zelf een QNAP nas in gebruik . Hun hardware is goed , hun software in mijn ogen is dat niet .
Volgende keer een ander merk voor mij .
Eens met update policy in het verleden bij QNAP. Ben wel van mening dat ze hun best doen eea sneller op te lossen en deze patch getuigd daarvan.
Een een jaar na dato klinkt veel beter dan 12 jaar na dato..., maar toch overtuigt het niet echt.

Op dit item kan niet meer gereageerd worden.


Nintendo Switch Google Pixel XL 2 LG W7 Samsung Galaxy S8 Google Pixel 2 Sony Bravia A1 OLED Microsoft Xbox One X Apple iPhone 8

© 1998 - 2017 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Hardware.Info de Persgroep Online Services B.V. Hosting door True

*