Wat een onzin. Gebruikers hebben geen toegang tot QNAP NAS device.
Daarnaast als QNAP geen fix heeft kan je sudo er beter af halen.

Iemand die de volgende vraag kan beantwoorden?

Ik zie veel berichten voorbijkomen over een lek met QNAP. Zelf heb ik een Synology NAS.

Ik weet dat veel berichten over lekken niet automatisch betekent dat bepaalde software niet goed is; het kan zelfs een goed teken zijn dat men tranparant is en exploits snel erkent en oplost.

Nu met dit SSH lek begin ik daar toch vraagtekens bij te vragen wat betreft QNAP. Is Synology nu zoveel beter of QNAP erg slecht met onderhouden van de software?

Dat dit advies gegeven moet worden... Een van de eisen van software is om die pas na hardening live te zetten. Services die niet gebruikt worden dienen daarbij dus altijd uitgeschakeld te worden. Dat is noodzaak, maar ook gewoon beheer- en security-hygiëne. Daarnaast: als je nog een plaintext password protocol als Telnet ondersteunt in je organisatie, dan ben je ook niet helemaal lekker. Als dit soort adviezen gegeven zouden moeten worden aan b.v. een auto-monteur, dan zou je adviezen krijgen als "We adviseren je vanuit het Peugeot hoofdkantoor om een lekkende olieleiding en haperende motor te repareren bij een kleine of grote beurt".

Ok dus van jou mag een fabrikant geen adviezen geven over het gebruik van hun spullen omdat iedere koper al geacht wordt te weten hoe dat allemaal zit, en geacht wordt te denken zoals jij denkt?
Dit soort uitspraken geeft goed aan hoe gevaarlijk dat "denken volgens standaards" is. Het zit op hetzelfde plan als "wachtwoorden moeten iedere 3 maanden veranderd worden". Het gaat uit van een of ander scenario dat niet noodzakelijk van toepassing is op de situatie, en past daar een algemene eis op toe die een gevoel geeft van "ik doe de dingen goed" terwijl er geen enkel echt effect (verbetering) is.
NATUURLIJK moet je geen telnet over internet gebruiken, maar dat zegt niks over de risico's bij het gebruik van telnet over het management VLAN.

Dit heeft denk ik meer te maken met op wie de aandacht gericht is. Bepaalde mensen hebben er lol in om een specifiek apparaat helemaal te onderzoeken en dan de gevonden problemen stuk voor stuk te melden aan de fabrikant, ipv de hele lijst in een keer te sturen.
Dus foutje 1 wordt gevonden, wordt gemeld, fabrikant maakt een update en trekt die door de hele test en uitrol trein heen en waarschuwt de gebruikers, die installeren de update (of niet) en dan komen ze met de volgende fout uit de hoed.
Dan gaat het hele circus weer van start. Wellicht gokken ze erop dat de gebruikers op den duur update-moe worden, of dat de fabrikant de standaarden voor testen etc een beetje laat zakken als ze iedere paar weken een paniek update moeten uitbrengen.
Of ze proberen gebruik te maken van al die activiteit om een backdoor oid er in te loodsen (doordat ze hebben ingebroken bij de betreffende fabrikant)?

Het probleem zit 'm in het sudo commando, en niet in SSH of Telnet. Het advies om SSH of Telnet uit te zetten is slechts om shell toegang tot de NAS te stoppen, zodat de sudo-vulnerability niet geëxploiteerd kan worden.

Precies zo'n houding zorgt voor ellende. Effe lekker een risico-acceptatie eruit gooien en onveilige oplossingen implementeren. Zit toch standaard in het OS. Lever het nou eens veilig op. First Time Right, zeker bij security! Als je risico-profiel na 6 maanden verandert, b.v. doordat je een disgruntled engineer hebt of je iets over het hoofd hebt gezien bij de acceptatie van deze onveilige oplossing (en ik spreek uit ervaring dat heel veel mensen dingen over het hoofd zien bij een risico-acceptatie, vooral doordat ze zeer sturend naar een voor hun wenselijke oplossing toe kletsen), dan kun je weer opnieuw beginnen met testen, implementeren en documenteren. Oh de werkplek van de network engineer is gecompromitteerd, en nu kan met het telnet wachtwoord de complete backup worden versleuteld? Maar we hadden toch een risico-acceptatie waar zo goed over nagedacht is?

Sommige dingen hebben regels, juist omdat je daardoor niet meer na hoeft te denken over andere maatregelen. Kijk naar auto's. Waarom hebben we regels voor gebruik van een gordel? "Als ik 20 kilometer per uur rijd en goed uitkijk, dan maakt dat toch helemaal niets uit?". Doe die gordel om en je bent van een hoop risico's verlost, net zoals je van een hoop risico's verlost bent waar de meeste mensen niet eens aan denken bij Telnetgebruik.

Nee, blind opvolgen van regels is zeker niet goed en zal ik niet promoten, maar als de regel is "niet door rood rijden", dan vinden we het ineens raar als je daar vragen over stelt. "Ja, dat zijn mensenlevens", heb ik vaker horen zeggen. Op die manier kun je alles wel wegredeneren. First Time right, de belangrijkste les binnen security. Daarom is het ook zo'n security-chaos bij de meeste bedrijven.... doordat niet is nagedacht over veiligheid van oplossingen.

Het gaat hier over een sudo lek en niet over een ssh lek.

Volgens mij speelt dit probleem niet bij de Synology nas. Daar kan iemand met gewone user rechten helemaal niet inloggen via SSH #. En als iemand met een administrator account toegang weet te krijgen, heeft hij dat lek niet nodig. Een administrator kan zich altijd met het commando 'sudo -i" rootrechten geven.

#: met bepaalde uitzonderingen. Er zijn pakketten, zoals git, die het gewone gebruikers wel toestaan om via ssh in te loggen, maar dan hebben ze alleen een commando set beschikbaar die voor git nodig is.

Oh nee? En als een aanvaller is binnengedrongen is in je management VLAN, kan die dan niet de credentials sniffen omdat je telnet gebruikt?

Waarom zou je een clear-text protocol gebruiken als het net zo makkelijk wel versleuteld kan? Echt, het kost geen enkele moeite om SSH te gebruiken ipv telnet.

Juist die houding van: “oh het blijft toch intern, zit geen risico aan, kan niemand bij” is gevaarlijk. Want wat als er wel iemand bij kan?

Hi, het probleem is niet zo zeer Qnap, maar het OS waar het op draait. De fabrikant probeert alleen mee te denken/zich in te dekken. Ik ben zelf groot fan van Synology, maar heel eerlijk, Qnap is ook prima. Het komt vaak neer op wat je voorkeur is qua features, interface, etc.
Qua security hoef je zeker niet over te stappen. Wat anderen hier al aangeven, het is best practice om ssh/telnet alleen lokaal open te hebben of liever gewoon uit en tijdelijk aanzetten wanneer je het nodig hebt, maar ook dat is persoonlijke voorkeur :-) Zoveel techneuten, zoveel meningen ;-)

Nee, want het is een switched netwerk. Dus als die aanvaller mee kan kijken dan heeft ie kennelijk al toegang tot de endpoints en dan gaat SSH echt niks meer helpen.

Maakt niet zo veel uit, je moet alleen geen management poorten aan het interwebs hangen. De sudo fout waar ze het over hebben is CVE-2021-3156. Een normale user kan zich root maken met een simpel stukje exploit code, daar is verder geen enkele vorm van autheticatie omzeiling bij nodig. De fout zit in sudo 1.9.5p2 en lager.
- Installeer sudo 1.9.5p2 handmatig vanaf: https://www.sudo.ws/
- Of update je systeem en controlleer of sudo v1.9.5p2 aanwezig is "sudo --version of sudo -V"
- Voer de redhat mitigatie uit :) ;)

Even gekeken op mijn Qnap. Daar staat Telnet en SSH uit.
Volgens mij heb ik dit ooit uitgezet..
Verder staat er bij "Only administrators can login remotely". Zelfde als Synology dus.
Draai de laatste firmware. Wellicht is dit anders in oudere firmware versies.

Er zijn veel lekken met Qnap software. Advies is niet direct aan Internet hangen, via VPN.
Hoop dat de VPN software niet lek is :-)

Het is nog veel veiliger om zo'n NAS niet aan je netwerk te koppelen, maar dan ga je eraan voorbij dat zo'n apparaat dan vrij nutteloos is.

Als je denkt dat switched netwerken niet te sniffen vallen, dan adviseer ik je om je huiswerk beter te doen. Denk o.a. aan arp cache poisoning. Gewoon versleutelen, dan hoef je je daar in deze context geen zorgen meer over te maken.

ARP cache poisoning is alleen mogelijk als je al op het netwerk zit. Als iemand kennelijk al binnen is op het management VLAN dan hoef je je geen illusies meer te maken.

Bij mijn weten *kan* je niet eens als gewone gebruiker inloggen met de standaard SSH versie die QNAP meelevert. De enige gebruiker die kan inloggen is 'admin' en dat is feitelijk gewoon root. Heb me hier nog kwaad om gemaakt in het verleden omdat dit het gebruik van SSHFS met de QNAP vanaf Linux clients behoorlijk in de weg staat. Dit ga je uiteraard niet met je admin/root gebruiker doen. Dus moet je met (een oudere versie van) Samba of NFS de boel gaan ontsluiten, wat ook behoorlijke nadelen heeft (Samba en special characters of symlinks bijv. en NFS wat alleen toegangsrestricties biedt op basis van IP)
Wel kun je via de QNAPClub Store OpenSSH los installeren, maar dan ben je al buiten de QNAP lijntjes aan het kleuren.

Of ze moeten dit in QTS versies na 4.2.6 hebben veranderd en daar ineens wel SSH toegang voor niet-admin gebruikers hebben toegestaan?