image

QNAP adviseert uitschakelen SSH en Telnet op NAS-systemen wegens sudo-lek

donderdag 28 januari 2021, 09:53 door Redactie, 17 reacties

QNAP adviseert gebruikers van een NAS-systeem om SSH en Telnet uit te schakelen wanneer ze deze diensten niet gebruiken. Aanleiding voor het advies is een kwetsbaarheid in sudo waardoor lokale gebruikers rootrechten kunnen krijgen. Het beveiligingslek is aanwezig in Unix en Linux-gebaseerde besturingssystemen, waaronder QTS, QuTS en QES van QNAP.

Een aanvaller die misbruik van de kwetsbaarheid wil maken moet eerst toegang tot het systeem zien te krijgen, maar dat zou via SSH of Telnet kunnen. Daarom adviseert QNAP als voorlopige bescherming tegen deze kwetsbaarheid om beide diensten uit te schakelen. De NAS-fabrikant werkt aan beveiligingsupdates en zal naar eigen zeggen zo snel als mogelijk met meer informatie komen.

Reacties (17)
28-01-2021, 10:07 door Anoniem
Wat een onzin. Gebruikers hebben geen toegang tot QNAP NAS device.
Daarnaast als QNAP geen fix heeft kan je sudo er beter af halen.
28-01-2021, 10:28 door Anoniem
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?
28-01-2021, 10:31 door Anoniem
QNAP adviseert gebruikers van een NAS-systeem om SSH en Telnet uit te schakelen wanneer ze deze diensten niet gebruiken.

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".
28-01-2021, 11:29 door Anoniem
Door Anoniem:
QNAP adviseert gebruikers van een NAS-systeem om SSH en Telnet uit te schakelen wanneer ze deze diensten niet gebruiken.

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.
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?
Daarnaast: als je nog een plaintext password protocol als Telnet ondersteunt in je organisatie, dan ben je ook niet helemaal lekker.
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.
28-01-2021, 11:33 door Anoniem
Door Anoniem:
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?
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)?
28-01-2021, 11:34 door Anoniem
Door Anoniem: Iemand die de volgende vraag kan beantwoorden?

...

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?

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.
28-01-2021, 12:05 door Anoniem
Door Anoniem: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.

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.
28-01-2021, 12:18 door Briolet
Door Anoniem:…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?

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.
28-01-2021, 13:42 door Anoniem
Door Anoniem:
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.

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?
28-01-2021, 15:14 door Anoniem
Door Anoniem: 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?

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 ;-)
28-01-2021, 17:35 door Anoniem
Door Anoniem:
Door Anoniem:
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.

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

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.
28-01-2021, 19:49 door Anoniem
Door Anoniem: 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?
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 :) ;)
28-01-2021, 21:06 door Anoniem
Door Briolet:
Door Anoniem:…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?

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.

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 :-)
28-01-2021, 21:51 door Anoniem
Door Anoniem:
Door Anoniem: Iemand die de volgende vraag kan beantwoorden?

...

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?

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.

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.
29-01-2021, 09:15 door Anoniem
Door Anoniem:
Door Anoniem:
Door Anoniem:
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.

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

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.

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.
29-01-2021, 10:08 door Anoniem
Door Anoniem:
Door Anoniem:
Door Anoniem:
Door Anoniem:
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.

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

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.

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.
01-02-2021, 13:29 door Anoniem
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?
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.