Kwetsbaarheid in PuTTY maakt het mogelijk om sommige private keys te stelen

Een ernstige kwetsbaarheid is ontdekt in PuTTY, een veelgebruikte SSH-client. Het beveiligingslek stelt aanvallers in staat om in sommige gevallen de private keys van gebruikers te stelen. De kwetsbaarheid treft PuTTY-versies 0.68 tot en met 0.80. Het probleem is inmiddels verholpen.

Door de kwetsbaarheid, die wordt gevolgd onder CVE-2024-31497, kunnen aanvallers de NIST P-521-keys van gebruikers verkrijgen. Dat kan door de code waarmee de PuTTY-client 'signatures' genereert via het Ecdsa. Die code bevat een bias waardoor gegenereerde handtekeningen gebruikt kunnen worden om de achterliggende private key te achterhalen. Aanvallers zijn daartoe in staat als ze ongeveer zestig van dergelijke signatures in handen hebben. Ze hebben daarvoor wel toegang nodig tot de handtekeningen van het slachtoffer, bijvoorbeeld door een SSH-server die het slachtoffer gebruikt tijdelijk over te nemen.

Met de gestolen keys kunnen aanvallers vervolgens valse signatures maken en zich toegang verschaffen tot servers waarop de betreffende key is gebruikt. Het advies aan gebruikers is om onmiddellijk de getroffen private keys in te trekken en nieuwe keys te genereren. Aanvallers kunnen namelijk al voldoende signatures hebben bemachtigd voordat de patch werd uitgebracht. Alleen Ecdsa-keys van 521bit zijn kwetsbaar. Dergelijke keys zijn bovendien alleen kwetsbaar als ze zijn gebruikt via de PuTTY-client of de PuTTY Authentication Agent.

De nieuwe versie van PuTTY, versie 0.81, lost het beveiligingslek op. Ook diensten als FileZilla, WinSCP, TortoiseGit en TortoiseSVN zijn kwetsbaar. De recentste versies van die software hebben het probleem ook verholpen.

Reacties (227)

[ernstoud]

Als ik audits doe bij netwerkbeheerders zie ik vaak PuTTY of KiTTY. Blijft verwonderlijk, net als een maand geleden met XZ, dat in professionele omgevingen geen andere oplossingen voorhanden lijken te zijn dan dergelijke tools die vaak hobby matig door developers onderhouden worden.

Ik gebruik KiTTY op mijn LAN maar naar buiten toe liever niet.

Stepping stone lijkt me toch de beste oplossing of SSH port knocking.

[stuiterveer]

Probleem is dat PuTTY voor lange tijd de enige degelijke optie was voor Windows, en dat alternatieven meer stilletjes zijn uitgerold zonder dat dit bij het algemene publiek aangeslagen is.

WSL is sinds Windows 8.1 "pas" een optie waarbij je dus SSH kunt gebruiken via die weg, maar dan neem je aan dat gebruikers dit mogen installeren en, zo ja, of ze hier überhaupt van weten en of ze inzien dat WSL dan een "noodzaak" is, even los van de vraag of een heel subsysteem niet wat overkill is als je enkel SSH wilt gebruiken.

Nou is sinds 1 of 2 (EDIT: correctie, kennelijk sinds 2018, zie context verder onder in dit bericht) jaar een algemene Windows uitgebracht die SSH standaard onderdeel maakt van Windows, maar dit is verdomd stilletjes uitgebracht. De enige manier waarop mensen hiervan zouden weten is door het gewoon te proberen en dan te zien of "ssh" nog steeds in een error resulteert dat het commando niet wordt herkend. Dus aangezien dit stilletjes is uitgerold zullen de meeste mensen nog steeds automatisch PuTTY gebruiken of aanraden.

Voor context wat betreft hoe stilletjes het is uitgerold:
https://community.ipfire....ard-on-windows-10-11/9251 hier wordt aangegeven dat het beschikbaar is, puur door een gebruiker die opeens merkte dat het geen error meer gaf. De uitrol (althans, het feit dat dit weer werd geprobeerd) werd in de dev blog van Microsoft beschreven, maar hoeveel eindgebruikers of zelfs IT admins lezen een dev blog? Daarin wordt ook gezegd "Read more about our detailed plans, roadmap, and where you can play with the in-progress code here", maar in die link wordt weer geen enkele keer SSH aangehaald.
Verdere officiële release documentatie over de April 2018 update benoemt ook nergens SSH:

• https://techcommunity.mic...-version-1803/ba-p/188568
• https://blogs.windows.com...ows-10-april-2018-update/

Dus ja, er zijn wel alternatieven, maar hoe algemeen bekend of bruikbaar zijn die daadwerkelijk voor het gros van de mensen?

[Reactie gewijzigd door stuiterveer op 22 juli 2024 19:38]

[fastedje]

Er is toch al jarenlang de cygwin ssh variant beschikbaar? De laatste jaren is WSL een beter optie.

[DataGhost]

Ik weet niet hoe het tegenwoordig is maar ik vond de Windows-terminal (o.a. cmd en powershell) waarin je dat moest uitvoeren vroeger echt extreem kut om mee te werken. Je kon vroeger bijvoorbeeld niet eens het venster resizen in de breedte en copy/paste was een tenenkrommend proces. Ondertussen bestond PuTTY al gewoon met veel meer features en bovendien in een simpele enkele binary. Voor Cygwin moest je eerst nog een hele omgeving installeren. Dus in ieder geval in praktische zin was het geen fatsoenlijk alternatief. Dit was rond de tijd van XP, hoewel het volgens mij in Windows 7 niet veel verbeterd was. Dus als je dan een bepaalde tool gebruikt die goed werkt en goed blijft werken, blijf je die dus gebruiken, ook al is de support in Windows zelf beter geworden.

[.oisyn]

en copy/paste was een tenenkrommend proces

Niet dat ik dat gedrocht van een conhost wil verdedigen, maar dit puntje is niet helemaal terecht. Je kunt namelijk echt al héél lang quick drag instellen, maar het stond standaard idd niet aan. Dan is het gewoon een kwestie van slepen voor een selectie, en dan richt click voor copy/paste.

Volgens mij kon dat in het windows 9x tijdperk al

.edit: lol, yup, net geprobeerd in een online Windows 95 emulator
Het heette "QuickEdit mode". Screenshot.

[Reactie gewijzigd door .oisyn op 22 juli 2024 19:38]

[DataGhost]

Ja en dan heb je een rechthoekige selectie te pakken. Succes met het selecteren van een hele zin die halverwege de eerste regel begint en ergens anders op een andere regel eindigt. Dan zal je toch de bounding box moeten selecteren en met een tussenweg via kladblok ofzo het stukje eruit pikken wat je eigenlijk nodig had. Oja en een selectie die hoger was dan het venster kon je ook lekker vergeten.

[Reactie gewijzigd door DataGhost op 22 juli 2024 19:38]

[.oisyn]

Ja en dan heb je een rechthoekige selectie te pakken

Ah ja, dat is idd kut, al moet ik zeggen dat ik in de ~30 jaar dat ik het gebruik niet supervaak een selectie heb moeten maken van meerdere regels lang waarbij het niet in een rechthoek past. Maar als dat moet dan is het idd even aankutten met notepad of iets vergelijkbaars.

[Remzi1993]

Plakken en kopiëren kan nu pas met de.moderne Windows Terminal. Dat kon al heel lang in Linux

[stuiterveer]

Er is toch al jarenlang de cygwin ssh variant beschikbaar?

En hoe makkelijk is die uit te rollen voor een standaard eindgebruiker ten opzichte van bijvoorbeeld PuTTY, even los van hoeveel mensen hiervan weten ten opzichte van PuTTY?

[Reactie gewijzigd door stuiterveer op 22 juli 2024 19:38]

[fastedje]

De installer kan je zowel met een gui als een script uitrollen.

[zanza006]

Deze is niet gratis "Vandycke SecureCRT". Gebruikt deze toch al +15 jaar.
Heb nog gezien dat andere bedrijven deze software gebruikten.

[Drharlin]

Ik zweer ook bij SecureCRT, zelf aangeschaft want bij de werkgever is Putty goed genoeg "want gratis"

[Kip]

Er is geen enkele gebruikelijke professionele IT omgeving waarbij er geen software component wordt gebruikt die hobbymatig door een developer is ontwikkeld of wordt onderhouden.

[RobbieB]

Het is onvoorstelbaar dat de IT wereld nog steeds zo’n wilde westen is. Ik snap de historie erachter, maar het wordt echt hoog tijd dat er flinke kwaliteitsnormen aan software gesteld gaan worden, net zoals dat bv ook in de bouwsector is met uitgebreide NEN-normen waar aan voldaan moet worden.

Het is toch van de zotte dat Jan van 15 op z’n zoldertje een stuk software kan ontwikkelen, dit op GitHub kan knallen en dat dit zonder enige vorm van formele checks & balances in de meest kritische software gebruikt kan worden.

Log4j had ons wakker moeten schudden, maar het XZ-incident laat maar weer eens zien dat we niks geleerd hebben.

En voordat iedereen weer begint: maar dan wordt het allemaal veel te duur en moeilijk. Ja, dat is zo. Maar een bedrijf dat platligt door een ransomware aanval is veel meer geld kwijt. Om nog maar niet te spreken over de impact van vitale infra die geraakt wordt.

[Reactie gewijzigd door RobbieB op 22 juli 2024 19:38]

[B_FORCE]

Het is niet alleen een wilde westen, er is ook extreem weinig educatie en controle in.

Noem het maar een soort van ARBO regeling voor IT en netwerken.

Wat het dan vervolgens nog meer kansloos maakt, is dat men vervolgens juridische wel allerlei dingen verwacht?

Het komt er dus een beetje op neer dat je allerlei mensen zonder formele opleiding laat auto rijden, en vervolgens ze verantwoordelijk stelt voor de fouten die ze maken.

Overigens denk ik niet dat een dergelijke controle heel duur hoeft te zijn wanneer er een juiste structuur wordt aangebracht.

[smiba]

Noem het maar een soort van ARBO regeling voor IT en netwerken.

Sorry maar als ik ergens de kriebels van krijg is het bureaucratie die gaat bepalen wat wel of niet correct is in IT.

Ik heb echt 0 vertrouwen dat er ook maar een groep bureaucraten bij een kan komen die daadwerkelijk productieve en functionele regels of doelstellingen richting IT kan maken. Ik bedoel kijk alleen al naar het gros van de ISO certificeringen waar ik echt hersendodende resultaten uit heb zien komen, 0 daadwerkelijke kennis aan boord maar we hebben wel de certificeringen!

Het grootste probleem in IT is imo dat jan en alle man met extreem oppervlakkige kennis maar naar binnen weet te komen, leuk dat je een opleiding hebt gevolgd en nu Windows Admin ben, maar wat er nou eigenlijk achter de schermen gebeurt weet je niet. Denk dat als je bij mening SysAdmin gaat praten over CPU architecturen, opcodes of zelfs hardware signals dat er echt weinig van binnen komt. Zelfde trouwens voor veel admins van andere systemen trouwens.

We zijn IT gewoon heel abstract gaan maken om zo snel mogelijk meer mensen in te kunnen huren, om te werken aan de equivalent van een hele complexe brandstofmotor zonder te begrijpen hoe het geheel nou eigenlijk werkt.

[Reactie gewijzigd door smiba op 22 juli 2024 19:38]

[Horla]

Het probleem is dat veel mensen verwachten dat de IT'er alles kan. IT is zo allesomvattend en ingewikkeld geworden dat je niet meer kan verwachten dat we alles kunnen. Bij mij komen ze met alles waar een stekker aan zit voor bij IT. Onlangs was er een probleem met de koffieautomaat en IT moest het maar oplossen. Laat ik nu juist een atypische IT'er zijn die geen koffie drinkt. Not my problem

[BRAINLESS01]

Met de complexiteit van IT systemen van vandaag is het onmogelijk om alles te weten, dan is het juist goed dat je je als systeembeheerder niet bezig hoeft te houden met opcodes en CPU architecturen (tenzij je een goede reden hebt om geen x86/x64 te gebruiken). Voor 99% van de bedrijven is Windows een prima oplossing, en voor 99% van de problemen die bedrijven ervaren heb je als systeembeheerder echt niets te maken met opcodes, CPU architectuur of hardware signals. Zelfs als het probleem daar ligt, ben je dan meestal afhankelijk van Microsoft, Intel, AMD of andere leveranciers voor een oplossing. De kunst zit erin om een team te vormen dat bestaat uit mensen met verschillende kennisniveaus, zodat je klussen kunt verdelen aan de hand van complexiteit. Ook die mensen die jij weg zet alsof ze te makkelijk binnen komen zijn nuttig in een goed lopend team.

Om je voorbeeld van een brandstofmotor te pakken, je hoeft als monteur echt niet voldoende kennis in huis te hebben om zelf een brandstofmotor te kunnen ontwerpen. Je moet voldoende kennis hebben om standaard onderhoud te doen en zodra er iets stuk gaat moet je weten hoe je dat kunt vervangen. Als het dan écht helemaal stuk gaat moet je de hele motor kunnen vervangen. Meer niet.

Als we nog bezig waren met opcodes en hardware signals zouden we nog steeds met user interfaces uit de jaren 70-80 zitten, omdat het veel te complex is om op zo'n laag niveau software te bouwen. Probeer voor de grap eens een user interface te bouwen op een simpele embedded cpu met display, die dingen kosten tegenwoordig een paar tientjes in China. Er is nog een groot verschil tussen een paar lijntjes tekenen en daadwerkelijk een grafische omgeving bouwen. Ik denk dat je letterlijk jaren bezig bent, maar dan heb je nog niets wat lijkt op een moderne user interface. Succes met schaduwen, transparantie en andere effecten zonder gebruik te maken van bestaande libraries.

[B_FORCE]

Oh dat ben ik trouwens helemaal met je eens hoor

Ook de ARBO wordt je knettergek van.
Helaas is dat wat er gebeurt wanneer mensen wederom weer van het middel het doel maken.

Het ging mij er meer om dat er nu helemaal geen controle is.
Ik bedoel hier controle vrij breed, niet zozeer daadwerkelijke regels.

[Some12]

Normen zijn onzin. Bureaucratische onzin.

Wat je eigenlijk moet hebben is een aantal goede handen (lees: maintainers) aan het stuur. Kwestie van kritieke software identificeren en forken. Desnoods audit je het tot in den treuren.

Maar echt goede software wordt eerst ontworpen (tot op de pseudo code) en daarna pas geschreven. En dan nog kruipen er bugs in.

Je wilt niet weten hoeveel “professionele” hotshots commerciële software schrijven, zonder planning, met een deadline, met een tachtig-uurige werkweek.

Maak jezelf geen illusies.

[RobbieB]

Als we met deze gedachten door waren gegaan met de huizenbouw was Nederland nu 1 grote krottenwijk geweest omdat alles zo goedkoop mogelijk moet. Datzelfde zie je nu met software gebeuren.

mensen die normen onzin vinden zijn vaak mensen die het te veel vinden kosten om zich eraan te houden of denken dat ze het beter weten (wat zelden het geval is).

[Some12]

Heb jij dan een norm voor professionele processen?

Ik heb wel een ideetje:
https://inst.eecs.berkele...Write-the-Right-Stuff.pdf

Maar dan alsnog valt of staat het met engineering, en dat is mensen-werk.

Edit: link zit tegenwoordig achter paywall: archieflinkje aangepast.

[Reactie gewijzigd door Some12 op 22 juli 2024 19:38]

[k995]

Het is onvoorstelbaar dat de IT wereld nog steeds zo’n wilde westen is.

Dat is het niet, dat is als bij elke auto-ongeluk roepen "toch erg dat de weg zo nog een wilde westen is"

[kaas-schaaf]

net zoals dat bv ook in de bouwsector is met uitgebreide NEN-normen waar aan voldaan moet worden.

Dit bestaat wel degelijk, in de wereld van de certificate authorities heb je gewoon normen (als je wilt met NEN nummer, veelal equivalent aan de originele ETSI of ISO) en voor dingen als trusted service providers nog meer. Echter voor "normale" software is hier niet aan te voldoen, laat staan voor een hobbyproject. Overigens is deze fout er ingeslopen omdat er simpelweg bij ontwikkelen nog geen standaard was, welke er nu wel is en de update implementeert die ook. (RFC6979)

[laptopleon]

Dat is met zoveel zaken, inderdaad. Waarom is er nog steeds geen wettelijk verplicht of i.i.g. aangeraden sjabloon voor pdf facturen bijvoorbeeld? Gewoon een afspraak welke velden op een factuur moeten staan, met welke naam. De simpelste dingen zouden al zoveel gedoe schelen.

[CyBeR]

Dat is met zoveel zaken, inderdaad. Waarom is er nog steeds geen wettelijk verplicht of i.i.g. aangeraden sjabloon voor pdf facturen bijvoorbeeld? Gewoon een afspraak welke velden op een factuur moeten staan, met welke naam. De simpelste dingen zouden al zoveel gedoe schelen.

Er is gewoon een wettelijke vereiste vanuit iig de belastingdienst waar een factuur aan moet voldoen hoor.

[laptopleon]

Ja, voor wat betreft welke btw-nummers etc, maar een boekhoudprogramma weet nu vaak niet welk bankrekeningnummer van de afzender en welk van de geadresseerde etc. Dit zou heel eenvoudig in de pdf kunnen worden ingebakken, ook onzichtbaar.

[BugBoy]

De meeste software is gewoon te complex om geen security issues te hebben. Er zijn heel wat mogelijkheden om problemen te voorkomen, maar niets is 100% veilig. Meer compliance gaat dat echt niet veranderen.

Mijn motto: Compliance is voor managers, Security is voor developers.

[RobbieB]

Dat is hetzelfde als roepen dat een wolkenkrabber te complex is om geen aardbeving en brandproblemen te hebben en daar zijn de afgelopen jaren ook echt gigantische sprongen in gemaakt. Het is pure onwil t.b.v. meer winst.

Mensen willen voor een dubbeltje een kwartje krijgen en zijn dat bij software gewend. Die gedachten moeten echt veranderd worden.

En als security voor developers is, dan hebben ze nog veel werk te zetten, want mijn ervaring als security engineer is dat het voor de meeste developers een after thought is ipv een primaire requirement.

[Reactie gewijzigd door RobbieB op 22 juli 2024 19:38]

[ernstoud]

Lees de reacties op mijn opmerking dat het mij verwondert en je hebt het probleem te pakken.

[YoMarK]

Je beargumenteerd je standpunt ( in het kort is je standpunt: we moeten tools zonder winstoogmerk die door een community worden onderhouden weren binnen bedrijfsomgevingen ) helemaal niet.

[Reactie gewijzigd door YoMarK op 22 juli 2024 19:38]

[Z80]

Waarom zou je putty NIET gebruiken?
Het is een klein stukje software dat je niet hoeft te installeren. Doet dat wat het moet doen. En werkt zonder admin rechten.
En mocht het een bug bevatten is niet meteen het hele systeem waar het op draait onveilig.

[ernstoud]

Heb je het artikel gelezen? Er zit een kwetsbaarheid in. Die gelukkig weer snel verholpen is.

Maar omdat je het niet hoeft te installeren, het doet wat het moet doen (afhankelijk van je eisen), werkt zonder admin rechten, denk jij dat het veilig is? Daar gaat het niet om. De kwetsbaarheid zat in het key protocol, niet in installatie, functies of admin rechten.

Kortom… Lees het artikel nog eens goed.

[Z80]

Dat heb ik. Jij ook?
Deze key-generator waar de fout in zat, is gepatched.
Maar ook gekeken hoe de fout is uit te buiten? Je moet eerst een ssh server waar deze specifieke key op gebruikt is overnemen om minimaal 60 versies van de keyexchange te onderscheppen. En je moet het geluk hebben dat de zelfde key ook op een ander systeem gebruikt is, wil je er misbruik van kunnen maken.

[ernstoud]

Zeker. Wat wil je daar mee zeggen?

[Z80]

Dat je nog steeds geen antwoord geeft op de vraag waarom NIET gebruiken?
Maar allerlei uitwegen zoekt om geen concreet antwoordt te hoeven geven.

[ernstoud]

Moet ik nogmaals herhalen wat ik al ongeveer twintig keer in deze thread gezegd heb?

Lees even de thread, tip: zoek in je browser.

Bijvoorbeeld 13:04 vandaag:

“Mijn punt was niet meer en niet minder dan dat mij het gebruik van PuTTY verbaast in zeer kritische omgevingen. Klaarblijkelijk raakt dat gezien de reacties een gevoelige snaar. Bijzonder.

Ja, PuTTY en andere tools zijn defacto standaards lijkt het. Maar juist dat verbaast mij als auditor omdat ik op valide vragen over bruikbaarheid, fit-for-purpose, licentie, risico e.d., vaak vage of geen antwoorden krijg.

En zeker als er geen alternatief is dan verwacht ik dat er mitigerende maatregelen getroffen zijn. Dus opslag van keys in een HSM, stepping stone, out-of-band management etc.“

Samengevat; ik hoef geen redenen te geven om een bepaald - voor security belangrijk - tool wel of niet te gebruiken. Dat moet je zelf doen, op basis van risico.

Waarom zou ik jou redenen moeten geven voor wel/niet gebruiken? Ik ken jouw omgeving niet.

[BugBoy]

Hoe zou jij onderzoeken welk product wel/niet veilig is om te gebruiken? Veiligheid van software is niet te bewijzen, dus de meeste mensen gebruiken tooling die veelgebruikt wordt. Putty was de defacto standaard op Windows, dus het is niet vreemd dat mensen dat gebruiken. Wat zou jij dan wel gebruikt hebben als je een SSH verbinding zou moeten opzetten en hoe zou jij aantonen dat het beter is?

[ernstoud]

Bij organisaties die zeer kritische omgevingen kennen, is certificering van het proces en de tooling daarin aan de orde. Dat zou dan bijvoorbeeld een security audit kunnen betekenen voor software. Quality Assurance noemen we dat.

Ik heb gewoon uit interesse gekeken of dat voor PuTTY gebeurd is. De website (https://www.chiark.greenend.org.uk/~sgtatham/putty/faq.html) zegt:

“If you want to be sure there aren't any security holes, do a security audit of the PuTTY code, or hire a security engineer if you don't have the necessary skills yourself…”

Ik heb niet kunnen vinden of een dergelijke audit wel eens uitgevoerd en gepubliceerd is.

Dat betekent niet dat het niet geschikt is voor een bepaald doel. Maar de vraag omdraaien… zou jij omgevingen weten te bedenken waar je PuTTY zonder andere risico verlagende maatregelen niet zou gebruiken? Ik wel.

Ik heb die omgevingen van binnen gezien. Dus stepping stones, isolatie van internet, firewalls van concurrerende merken back-to-back met slechts 1 rule. Monitoring. Hardening. Screening. Alles resilient en redundant. Alle handelingen vastgelegd in procedures. Elk jaar verplichte trainingen etc. etc.

[likewise]

En welke audit club zou deze leak gevonden hebben?

Even serieus, na hoeveel facturen en audits heb jij de zekerheid dat deze kwetsbaarheid eruit zou zijn?

En nu dezelfde vraag voor de nog onbekende kwetsbaarheden in de software die je wel inzet?

[ernstoud]

Sorry, maar is dit trollen of ben je serieus?

100% security bestaat niet. Moet je daarom geen security (audits) doen?

Wat wil je nou van mij horen precies?

[likewise]

Ik vraag alleen welke club een security audit doet en dit issue gevonden zou hebben?

Want in mijn ervaring wordt er met mooie termen gegooid en hoge facturen gestuurd in de naam van "security audits" maar echte developers die naar de code kijken zijn er maar weinig, laat staan dat ze durven te garanderen dat hun security audit garanties biedt.

De developers die wel naar de code kijken komen veelal uit een andere hoek.

[5pë©ïàál_Tèkén]

Definieer 'gebruiksvriendelijk'. Als iets abstract, complex is en/of veel features & opties heeft, dan zal daar allemaal op een of andere manier een interface voor moeten zijn. Het verleidelijke is om features weg te laten uit de interface en een default setting te gebruiken. Nu gebeurt er op TCP/IP & OSI-niveau zo veel dat elke simplificatie er van risico's met zich meebrengt.

En nu zit 'de schrik' er even in en realiseren sommige ITers dat PuTTY misschien geen eerbied doet aan het vraagstuk van hun organisatie.

[mjl]

Vervolgens blijven ze het gebruiken want het is zo ‘handig’ en wat ze gewend zijn. Genoeg IT-ers gezien die vrolijk iets als teamviewer gebruikten terwijl er een company policy was dat dat niet mocht. Maar ja, een IT-er weet wel wat hij doet dus dan is het opeens veilig om de regels te overtreden voor het gemakkie ….

[Ricko1]

Teamviewer mag je zakelijk niet gebruiken zonder licentie. Dat begint bij €40 per maand voor één gebruiker https://service.teamviewer.com/nl-nl/overview

Daar kan een bedrijf serieuze rechtzaken van krijgen. Er zijn ook genoeg alternatieven die beter zijn dan teamviewer.

[mjl]

Vandaar ook de stomme verbazing destijds van de eindgebruikers … die werden op de vingers getikt maar IT ging vrolijk door.

[muffer]

Relevante XKCD.

[Woodsnaps]

Sorry, maar wat bedoel je met gebruikelijk? Ik heb bij Apple en PWC aan projecten gewerkt, waar alles zo dichtgetimmerd zat als maar kon. Daar was echt geen plaats voor hobbyisten-software…

[Elminster]

Geen hobbyisten software?

https://opensource.apple.com/releases/

In de release van macOS 14.4 zit onder andere:
https://github.com/apple-...ses/tree/ncurses-71.100.2
https://invisible-island....urses.faq.html#who_did_it

[Woodsnaps]

Mooi dat je dit kán downloaden, maar volgens mij heb jij mijn comment niet echt goed begrepen.

[Elminster]

Ik veronderstel van niet?

Ik wilde aantonen dat macOS (& friends) intern ook "hobbyisten software" gebruikt.
Zoals zowat elk bedrijf ter wereld.

[ernstoud]

Vandaar mijn verwondering. Netwerkbeheerders die cloud omgevingen van kritische processen benaderen met PuTTY. Ik begrijp de open source wereld en de kwaliteit is soms ok., maar toch verbaast me dit alles.

In de Oracle Cloud Infrastructure bijvoorbeeld (bron: https://www.oracle.com/we...cloud_VM_using_Putty.html)

What Do You Need?
Windows.
PuTTY as an SSH client.
Your service instance’s IP address.

Als Oracle in staat is zo’n cloud infra te bouwen dan zouden ze toch de cliënt om die te benaderen, op basis van OpenSSH, kunnen aanbieden?

[The Zep Man]

Vandaar mijn verwondering. Netwerkbeheerders die cloud omgevingen van kritische processen benaderen met PuTTY. Ik begrijp de open source wereld en de kwaliteit is soms ok., maar toch verbaast me dit alles.

Het zal je verbazen wat in het closed source wereldje allemaal speelt. Gek genoeg krijg je daar veel minder zicht op.

Als Oracle in staat is zo’n cloud infra te bouwen dan zouden ze toch de cliënt om die te benaderen, op basis van OpenSSH, kunnen aanbieden?

Waarom zou Oracle zelf een client aanbieden? Dat is alleen maar meer werk voor weinig winst. Ook in OpenSSH worden wel eens fouten gevonden.

[Reactie gewijzigd door The Zep Man op 22 juli 2024 19:38]

[Soldaatje]

Omdat Windows pas sinds Windows 10 1809 OpenSSH aan boord heeft. Voor eerdere versies wordt Putty aanbevolen. Overigens worden er RSA sleutels aanbevolen en geen ECDSA. https://docs.oracle.com/e...o-an-instance-using-putty

[kaas-schaaf]

Meestal word ECDSA afgeraden met de NIST P256 en P384 curves omdat de oorsprong daar een beetje dubieus van is (P521 gebruikt een Mersenne prime en die wordt redelijk vertrouwd), beetje kort door de bocht om het helemaal af te raden maar vanuit support perspectief snap ik dat wel.

[Blokker_1999]

Als fervent Kitty gebruiker begrijp ik heel goed waarom mensen het doen. Je zegt zelf dat een Oracle zelf maar een OpenSSH cliënt moet meeleveren,l, maar wat maakt dat dan ineens beter dan Putty? Beide zijn gewoon FOSS implementaties van hetzelfde protocol.

[Nardon]

Maar waarom zou die client dan automatisch veiliger zijn dan PuTTY? Ook die kan kwetsbaarheden bevatten. Het voordeel van een open source tool is juist dat deze extern geaudit kan worden op veiligheid, en dat gebeurt dus ook regelmatig waardoor dit soort kwetsbaarheden aan het licht komen en opgelost worden. Als Oracle zelf een client maakt moet je er maar vanuit gaan dat zij dat ook zo laten doen.

[moredruid]

Ik begrijp de open source wereld en de kwaliteit is soms ok., maar toch verbaast me dit alles.

Definieer "soms ok". Mij lijkt dat een Open Source OS dat in aantallen gemakkelijk concurreert met het aantal Windows server installs en dat door een aantal van de grootste IT bedrijven ter wereld (IBM, Oracle) aangeboden wordt wel iets meer dan "ok" is. Of een database server (MySQL, PostgreSQL). Of een webserver (Apache, Nginx).

PuTTY is een prima tool. Als ik in MITRE kijk zie ik 31 CVE's voor PuTTY (sinds 2003), en 141 CVE's voor RDP (sinds 2001). Welke van de 2 was ook alweer Open Source en "bijgehouden door een hobbyist", en welke van een miljardenbedrijf dat hier een heel team voor heeft zitten?

Ik heb genoeg dure closed source software gezien waarvan de kwaliteit dramatisch slecht was, dus Open/Closed source is geen argument.

Oracle heeft echt wel de capaciteit om zelf een client te schrijven, maar waarom zou je een heel team betalen om zo'n client te schrijven en te onderhouden als er een prima gratis tool is? PuTTY gebruikt gewoon de OpenSSH libraries, net als iedereen die zo'n client heeft geprogrammeerd (SecureCRT, MobaXterm, enz). Volgens jouw redenering zouden ze dan ook een eigen RDP client moeten aanbieden.

[ernstoud]

De closed vs. open source discussie is een dead end. Daar komen we nooit uit en dat bedoelde ik ook helemaal niet. Ik ga daar niet op in, want discussies of mijn geloof beter is dan dat van jou of andersom is zinloos.

Het gaat er om dat je het juiste tool gebruikt voor een toepassing en daarbij sprak ik verwondering uit dat ik zie dat zonder verder nadenken dan PuTTY gebruikt wordt in kritische omgevingen.

Dat was alles wat ik zei.

[moredruid]

Dat zei ik dus ook al: open of closed source is geen argument.

Dat er al dan niet gedachteloos PuTTY wordt gebruikt in een kritische omgeving kun je vergelijken met een hoop sysinternals.com tools die gedachteloos door veel Windows sysadmins werden gebruikt voordat Microsoft sysinternals overnam.

Je kunt je verbazen/verwonderen over het feit dat iemand zonder zich erin te verdiepen software gebruikt voor het beheer van zijn/haar omgeving, en ik denk ook wel dat je dat bedoelt. Maar dat geldt net zo goed voor andere (on)betaalde tools met hun bijbehorende licenties. Door te pikken op PuTTY (begrijpelijk gezien het artikel) kwam je opmerking op mij (en kennelijk meer mensen) polariserend over aangezien PuTTY juist een voorbeeld is van hoe het wel kan.

[ernstoud]

Mooie reactie, dank je. En dat “pikken op PuTTY” is hoe het gelezen wordt. Dat wordt zo blijkt vaak zo onbedoeld gelezen als kritiek op FOSS. Zie de reacties. En dan sta je op tenen.

Terwijl ik juist dat een beetje bedoel… doe eens een stap terug. Is het logisch dat ik dit product gebruik? Kan het veiliger, moet het veiliger? Moeten we daar eens over in overleg? Kennen we die 31 CVE’s in dit product? Zit er daar 1 bij die voor ons belangrijk is? Is die gepatched? Hebben we ook versie beheer op die gratis tools? Zitten ze in onze CMDB?

Dat dus.

[Webber]

"Ik begrijp de open source wereld en de kwaliteit is soms ok.,"

Soms ok? Really?

Ik zal een paar open source projecten opnoemen waarvan de kwaliteit een stuk meer dan OK is om deze bias tegen open source wellicht iets te nuanceren:

• Complete besturingssystemen, zoals Ubuntu, Pop!_OS, enzovoort.
• Windows tooling, zoals PowerShell, Windows Terminal, PowerToys, enz.
• Database systemen, zoals MySQL, MariaDB, MongoDB, PostgreSQL, Cassandra, enz.
• Virtualisatietools voor processen en workloads, zoals Docker, Kubernetes, enz.
• Automatiserings tools voor infrastructuur, zoals Terraform, Ansible, enz.

Dit is een vlugge greep van hoge kwaliteit open source projecten. Dit zijn bepaald geen uitzonderingen. En niet om lullig te doen, maar de halve wereld draait tegenwoordig op of door middel van dergelijke open source technologieën.

Edit: fix typo

[Reactie gewijzigd door Webber op 22 juli 2024 19:38]

[Oon]

Wat voor alternatief zou je voorstellen dan? Onder Windows was PuTTY een hele tijd de enige bruikbare implementatie van SSH, tegenwoordig kan het via WSL of kun je via de Git installer makkelijk up to date linux binaries binnenhalen, maar het blijft altijd wel gestuntel om bijv. een reverse proxy op te zetten via CLI, dan is een interface waar je een vinkje aan zet toch wel heel handig.

[lenwar]

Onder Windows was PuTTY een hele tijd de enige bruikbare implementatie van SSH

In elk geval een gratis bruikbare implementatie. Er zijn al jaren en jaren prima commerciële SSH-clients natuurlijk.

[Accretion]

Dat is geen garantie op een beter product.

[lenwar]

Dat zeg ik toch ook niet? Het statement was dat PuTTY het enige ‘bruikbare’ product was, en dat was wat mij betreft onvolledig.
Of die commerciële producten beter of minder goed zijn, laat ik in het midden.

[xFeverr]

Sinds Windows 10 build 1809 zit er een OpenSSH client in Windows. Al bijna 6 jaar lang. Is dat lang? Misschien niet in vergelijking met PuTTY, maar toch al een behoorlijke tijd. Gewoon Powershell/cmd openen en ssh Oon@mijnsshserver typen en je bent vertrokken.

Nog een tip voor mensen die Windows Terminal gebruiken: je kunt verbindingen naar servers die je vaak raadpleegt ook als profiel toevoegen. Dan heb je ze allemaal binnen handbereik.

[MiesvanderLippe]

Er zit echt al heel lang gewoon een openssh client in Windows? Waar hebben jullie het over? En als je hem nog niet hebt kun je hem gewoon aanzetten in features, of installeren via Winget.

[WoutervOorschot]

Het was heel lang de enige fatsoenlijke implementatie inderdaad. Je kunt overigens SSH zowel client als server al enkele jaren gewoon als windows component installeren, geen wsl of git nodig.

[fastedje]

Cygwin is al vele jaren beschikbaar op Windows.

[ernstoud]

Je noemt zelf de alternatieven. En natuurlijk een out-of-band stepping stone naar core systemen.

En “makkelijk” en “handig” zijn woorden die tijdens audits dan wel toegelicht moeten kunnen worden in de trant van risico.

[Blokker_1999]

Dus je vindt het beter dat mensen een virtuele omgeving opstarten met een geemuleerde Linux dan dat ze een lichtgewicht client gebruiken?

Ik weet wat ik professioneler vindt overkomen, en dat is het KISS principe.

[stuiterveer]

Heel leuk, maar hoe lang zit die daadwerkelijk standaard in Windows? Dat is pas sinds een jaar of 2.

[Webgnome]

Professioneel of niet het maakt uiteindelijk niet heel veel uit toch? Bij een professioneel pakket heb je echt geen zekerheid dat het perfect werkt en geen lekken bevat.

[lenwar]

Het probleem bij hobbyisten is dat je aan hun grillen en tijd bent overgeleverd. Grote softwarehuizen bieden een vorm van garantie dat zij bekende grote fouten in een redelijke termijn fiksen.

Een mooi voorbeeld van een tijdje terug was bij KeePass, waar de codemaker weigerde een bepaalde beveiligingsfout te repareren. (Uiteindelijk had hij het toch gedaan, maar het gaat even om zijn grillen in het voorbeeld).
Bij een softwarehuis nemen ze dat veel serieuzer.

N.b. ik wil zeker niet suggereren dat alle hobbyisten laks of onkundig zijn!

[mocean]

Grote softwarehuizen bieden een vorm van garantie dat zij bekende grote fouten in een redelijke termijn fiksen.

Alleen als je een hele grote partij bent met een kneiter dure SLA. Anders heb je ook gewoon pech.

[lenwar]

Daar is niks algemeens over te zeggen.
Als er een bekende grote fout in Chrome, Excel, Safari, PhotoShop, whatever zit, is de kans dat deze snel wordt opgelost en gedistribueerd groter, dan bij een bij een product dat door een hobbyist met volle passie wordt bijgehouden na z'n werk en buiten z'n vakanties.

een vorm van garantie

Hiermee doel ik dus niet op een contractuele basis, maar gewoon dat kans zeer aannemelijk is dat ze dit gewoon doen. Alleen al omdat ze meer middelen hebben om het te doen.

[morphje]

Als je grote pakketten noemt, noem dan ook vergelijkbare open source software. Sterker nog, ik denk persoonlijk dat je meer voorbeelden kan vinden van snelheid van fixes in open source software dan in closed source. Closed source is echt geen garantie van kwaliteit of snelheid of moet ik even spitten in het archief van windows updates die hele systemen om zeep hielpen of gewoon soms jaren lang vrij duidelijke bugs in software hebben gehad? Er zijn genoeg voorbeelden te vinden van bugs die niet serieus genomen werden (om je keepass voorbeeld aan te halen).

Elk stuk software, open of gesloten, is gevoelig voor bugs en Putty is niets anders. En daarbij, Putty is wel gruwelijk stabiele software (iets wat niet stuk is hoef je niet te patchen) en de releases die uitkomen zijn zeer beperkt qua bugs.

En ga even de timeline na. De CVE is van 4 april. Binnen twee weken is er een patch. Dat zie ik niet veel closed source bedrijven doen hoor. Niet slecht voor een hobbyist op een zolder, toch?

[lenwar]

Ik heb het ook niet over open source of closed source. Dat heeft er ook niet zo veel mee te maken. Ik had ook Firefox, GIMP en LibreOffice Calc kunnen pakken als voorbeelden. Daar zitten ook organisaties/bedrijven achter die het over het algemeen gewoon goed doen.

In dit geval heeft de maker van PuTTY het inderdaad heel netjes gedaan! Zware oprechte kudos!

Ik bedoel echter in z’n algemeen.

[svennd]

11 dagen na de CVE creation is de fix er al, daar kan menig softare boer nog van leren.

[lenwar]

Klopt. Bij PuTTY gaat het inderdaad redelijk goed, dit soort zaken.

Mijn statement is meer algemeen. Er zijn ook softwarehuizen die er niet goed mee omgaan.

En zoals ik al schreef. Ik wil zeker niet suggereren dat hobbyisten laks of onkundig zijn.

[moredruid]

Dus gewoon geen software gebruiken die zich op dat gebied nog niet bewezen heeft, of helemaal niet als je het niet vertrouwd en voor een (betaald) alternatief kiezen. Of toch juist Open Source gebruiken. Wordt een bug niet gefixt? Het staat je vrij om de code te forken en het zelf te doen. Iets dat bij closed source niet mogelijk is. Moet je het als "hobbyist" natuurlijk wel zelf bijhouden!

[lenwar]

Het staat je vrij om de code te forken en het zelf te doen

Dat vind ik altijd zo’n dooddoener.

Hoeveel gebruikers van PuTTY verwacht jij dat er kan programmeren en tegelijk diepgaande kennis hebben van cryptografie en hoe je dat op de juiste manier moet implementeren.

Heb je voor de gein wel is gekeken naar de broncode van versleutelingssoftware. Ik kan prima code lezen, maar dat soort code lijkt voor mij eerder line noise (bij wijze van).
Ik kan echter niet ‘echt programmeren’, dus ik heb helemaal niets aan de broncode van dit soort applicaties.

[moredruid]

PuTTY gebruikt gewoon de OpenSSL libraries, hun toegevoegde waarde zit in de schil die ze eromheen hebben geschreven.

[ernstoud]

Dat is mijn punt niet. En een flame war open vs. closed source kunnen we beter niet starten.

Stel je loopt je garage binnen en je ziet de monteur Temu gereedschap gebruiken, wat is dan je eerste indruk?

Die eerste indruk heb ik soms tijdens security audits met tools zoals PuTTY. That’s all.

(Laat staan dat de antwoorden op mijn vraag waarom geen OpenSSH gebruikt wordt, vaak vaag zijn. En de vraag naar de licentie van PuTTY in commerciële omgevingen vaak ook niet beantwoord kan worden.)

[PolarBear]

En waarom zou OpenSSH beter zijn dan PuTTY? Waarom vind je de ene opensource tool kennelijk beter dan de andere?

En wat is er mis met de licentie van PuTTY in vergelijking met OpenSSH.

[ernstoud]

Minder features, meer "ogen" in de OpenSSH community dan de community rond PuTTY?

Er is niets mis met beide licenties. Alleen als ik aan een netwerkbeheerder vraag of PuTTY in een zakelijke omgeving gelicenseerd is, dan weet men dat niet. En dan is dat per definitie een tekortkoming. Want dat moet je (of iemand anders, de bedrijfsjurist, legal, management etc.) wel weten!

[rbr320]

Minder features,

Hoezo heeft OpenSSH minder features dan PuTTY? Dat PuTTY nog SSH1 ondersteund is inderdaad wel een nadeel want SSH1 is onveilig. Deze ondersteuning zouden ze eigenlijk moeten verwijderen. Verder zijn ze qua features erg vergelijkbaar. Als je per se OpenSSH met SSH1 functionaliteit nodig hebt leveren de meeste distro's daar nog wel een package voor (openssh-client-ssh1 op Ubuntu).

meer "ogen" in de OpenSSH community dan de community rond PuTTY?

Heb je hier cijfers van? Ik denk namelijk niet dat dit per se waar is, gezien hoe wijdt verspreid PuTTY wordt gebruikt.

Er is niets mis met beide licenties.

Het zou ook vreemd zijn als je wel van mening zou zijn dat er iets mis is met 1 van beide licenties, want ze zijn effectief hetzelfde. Zowel OpenSSH als PuTTY vallen namelijk effectief onder een BSD licentie. Je kunt in de details waarschijnlijk wel wat verschillen vinden, maar die zijn zo klein dat ze voor deze discussie niet veel meerwaarde bieden denk ik.

Alleen als ik aan een netwerkbeheerder vraag of PuTTY in een zakelijke omgeving gelicenseerd is, dan weet men dat niet. En dan is dat per definitie een tekortkoming. Want dat moet je (of iemand anders, de bedrijfsjurist, legal, management etc.) wel weten!

Het klopt dat men op de werkvloer vaak niet weet onder welke licentievoorwaarden de software valt die men gebruikt, met name als het open source software betreft. Ik ben ook niet per se van mening dat men dat zou moeten weten, dat lijkt me meer iets voor legal. Ik ben dus van mening dat men bij interne controles iets meer door zou moeten vragen op dit onderwerp om er achter te komen welke software er nu eigenlijk gebruikt wordt binnen een organisatie. Ik heb dat in de praktijk echter nog nauwelijks meegemaakt, ongeacht of het open source of closed source software betreft. Het lijkt de juristen allemaal ook niet echt te boeien.

[Reactie gewijzigd door rbr320 op 22 juli 2024 19:38]

[ernstoud]

Als je de OpenSSH CLI client vergelijkt met PuTTY dan zijn er natuurlijk door gebrek aan GUI, terminal emulatie, e.d. minder features. Dat bedoelde ik.

[rbr320]

Sure, maar dat zijn nou niet bepaald features die vaak kwetsbaarheden in de beveiliging veroorzaken. Dus hoewel je technisch gezien gelijk hebt, zijn PuTTY en OpenSSH op technisch gebied erg vergelijkbaar.

[morphje]

Stel je dezelfde vraag ook over de OpenSSH licentie?

Het lijkt vooral dat je een hekel hebt aan Putty.

[ernstoud]

Hekel? Nee hoor. Ik gebruik het zelf in mijn LAN. Prima voor dat doel. Al in meerdere posts hierboven gezegd.

En ja, voor alle tools die gebruikt worden in kritische omgevingen, denk aan energiesector, centrales e.d., kan ik dezelfde vraag stellen. Natuurlijk gebeurt dat niet altijd. Want een audit is altijd beperkt in tijd.

[Ludewig]

Er is niets mis met beide licenties. Alleen als ik aan een netwerkbeheerder vraag of PuTTY in een zakelijke omgeving gelicenseerd is, dan weet men dat niet. En dan is dat per definitie een tekortkoming. Want dat moet je (of iemand anders, de bedrijfsjurist, legal, management etc.) wel weten!

Putty is sowieso gelicenseerd, want het is vrij te distribueren en te gebruiken onder de MIT licentie.

Er zijn licenties van gratis software waar de source code al dan niet voor beschikbaar is, waar commercieel gebruik is verboden of een betaalde licentie vereist. Dit is dan echter sowieso geen open source software volgens de definitie van de Open Source Initiative (zie regel 6).

Overigens zijn de risico's van commerciële, closed source software vaak groter, want daar zijn vaak allerlei extra regels over het gebruik, zoals het aantal installaties, waardoor een bedrijf door niet op te letten van legaal gebruik over kan gaan naar illegaal gebruik. Bij software als Putty onder de MIT license kun je qua gebruik zo gek doen als je wilt en is het in principe onmogelijk om illegaal bezig te zijn (tenzij je de code van het product zelf weer gaat distribueren).

[Reactie gewijzigd door Ludewig op 22 juli 2024 19:38]

[ernstoud]

Goede toevoeging. Juist als iemand op mijn vraag over licenties het zo toelicht dan kudo’s. Maar zoals ik zei, soms is het antwoord dat er geen overzicht van al dan niet gelicenseerde software is en dat men de licentie voorwaarden als die er zijn niet kent.

Zo moest ik de developer van mijn ISP router ook wel wijzen op verplichtingen in de GPL.

[Webgnome]

Dat is mijn punt niet. En een flame war open vs. closed source kunnen we beter niet starten.

Dat was ook helemaal niet mijn bedoeling

Stel je loopt je garage binnen en je ziet de monteur Temu gereedschap gebruiken, wat is dan je eerste indruk?

I don't care if it gets the job done?

(Laat staan dat de antwoorden op mijn vraag waarom geen OpenSSH gebruikt wordt, vaak vaag zijn. En de vraag naar de licentie van PuTTY in commerciële omgevingen vaak ook niet beantwoord kan worden.)

Licentie technisch is natuurlijk een ander verhaal en daar zal een bedrijf echt wat mee moeten doen. Aan de andere kant, de ontwikkelaar(s) van Putty weten zelf ook wel dat hun product overal te pas en te onpas gebruikt word en zitten er blijkbaar niet heel erg boven op.

Ik vraag mij wel een beetje af wat je punt wel was. Immers het verbaast je dat het gebruikt word in professionele setting maar het is toch een soort van de defacto standaard? Net als Word overal de defacto standaard is of welk ander product waar, in de ogen van anderen, betere alternatieven voor bestaan

[ernstoud]

Mijn punt was niet meer en niet minder dan dat mij het gebruik van PuTTY verbaast in zeer kritische omgevingen. Klaarblijkelijk raakt dat gezien de reacties een gevoelige snaar. Bijzonder.

Ja, PuTTY en andere tools zijn defacto standaards lijkt het. Maar juist dat verbaast mij als auditor omdat ik op valide vragen over bruikbaarheid, fit-for-purpose, licentie, risico e.d., vaak vage of geen antwoorden krijg.

En zeker als er geen alternatief is dan verwacht ik dat er mitigerende maatregelen getroffen zijn. Dus opslag van keys in een HSM, stepping stone, out-of-band management etc.

[morphje]

Waarom verbaas je je (als auditor) over het opensource karakter van een tool als Putty, maar niet over tools als OpenSSH/OpenSSL?

Allen zijn net zo bruikbaar, fit-for-purpose, hebben een opensource licentie en kennen net zoveel risico's als closed source software. Sterker nog, juist OpenSSL wordt in de meest kritische omgevingen toegepast, juist omdat het zulke stabiele software is.

Dus vertel eens. Wat zijn dat die vragen waar je op vast loopt als auditor? En op welke wijze kan die vraag op een adequate manier beantwoord worden door closed source software? Waarom moet er een alternatief beschikbaar zijn? En wie bepaald of een alternatief het beste is door wederom dezelfde vragen te stellen.

[ernstoud]

Al in andere posts genoemd… maar samengevat: past het gebruik van dit tool bij het risico? Is er dus een risicoanalyse gemaakt. En het gebruik daarna geaccepteerd. Dat is wel het belangrijkste.

Ik heb geen voorkeur of afkeur of mening over closed vs. open source en of alternatieven slechter of beter zijn. Dat is niet mijn taak, challengen van de keuzes wel. Uiteraard zover als dat de gebruikte norm vereist.

[morphje]

Nou beste auditor: Ja. Klaar. Nog andere vragen?
Wil je dat ik een formeel document opstel?

Dit gaat wel heel erg ver, behalve voor de meest kritische omgevingen en zelfs daar volstaat een lijst van software, versie nummer en een acceptatie vinkje in de derde kolom.

Je noemt ergens kerncentrales, maar ik hoop dat je wel iets meer dan 1 klant hebt. En als je voor elke keuze zoveel vragen gaat stellen dan heb je toch echt wel de meeste klanten heel snel in het harnas. Veel van je vragen/opmerkingen wekken een bepaalde suggestie. Hoewel veel mensen je erop wijzen, lijk je dat niet in te zien.

[ernstoud]

Honderden auditklanten in de afgelopen 20 jaar. Maak je geen zorgen.

En ik heb nog nooit een klant in het harnas gejaagd. De certificerende instellingen waar ik voor gewerkt heb, hebben nog nooit een negatief oordeel gehoord.

In tegendeel tot auditors die de werkwijze die jij noemt van formele documenten en afvink lijstjes hanteren. Dat is vrijwel onbelangrijk, belangrijk is risico’s onderkennen en de juiste mitigerende maatregelen treffen.

Welke suggestie maak ik dan volgens jou? Ik ben auditor. Ik stel dat ik verwonderd ben en dan worden er allerlei zaken in de mond gelegd. Ik begrijp die “aanval” niet helemaal. Omdat ik een vraag stel vanuit verwondering? Dat een 0. versie van software gebruikt wordt in soms kritische omgevingen? Zonder risico’s te kennen?

Met die vragen sta ik bij mensen op hun tenen blijkbaar gezien de -1 hier en daar. Wederom verwondering.

[morphje]

Nou de reden dat men negatief reageert is de wijze waarop je PuTTY positioneert en de vragen die je stelt. Terwijl je deze vragen prima kan stellen over elk software pakket en vrijwel altijd hetzelfde antwoord terug krijgt. Maar specifiek pik je PuTTY eruit en ben je overwegend kritisch met je vragen waarmee je de illusie wekt dat je vind dat het niet thuis hoort in een kritische omgeving.

Maar goed. Ik geloof dat ik het doorheb. Je hebt het over een 0.x versie, dat is een beta versie en hoort niet thuis in kritische omgevingen. Maar inmiddels zijn versienummers praktisch zonder betekenis. De meeste browsers hebben versienummers boven de 100, wat is daar dan de betekenis van? Super stabiel? Of net zo gevoelig voor bugs?

Er zijn genoeg andere software pakketten die 0.x versies hebben en net zo stabiel zijn. Uiteindelijk is de vraag niet of het thuis hoort in een kritische omgeving, maar of de software een bewezen historie heeft. En PuTTY heeft die historie.

[ernstoud]

Je hebt volledig gelijk. Als auditor stel ik deze vragen ook over andere tools die gebruikt worden in kritische omgevingen, bijvoorbeeld RDP, WinSCP, OpenSSL, OpenSSH, Teams, Jira etc. etc.

Het ging hier over PuTTY. Vandaar dat ik daar op in ging. Ik heb PuTTY in dit artikel niet er uit gepikt, dat deed de redacteur.

En overwegend kritisch zijn is tegenwoordig een erg goede eigenschap. Te klakkeloos alles aannemen in een wereld beheerst door (a)social media en AI is niet verstandig.

Wel lijkt het in veel reacties hier dat de onrust die na de XZ ellende in de foss wereld is ontstaan - vooral de realisatie dat vertrouwen cruciaal is - nog niet bij iedereen geland is. Ja, (ook) closed source software is vaak krakkemikkig. Maar dat is een raar argument om te gebruiken om vervolgens in de foss wereld niets te doen. Je hersens gebruiken en je wat vaker afvragen of de tools die je gebruikt passen bij het risico. Dan ben je al een heel eind. Of dat nou gaat over PuTTY, Windows of Linux.

[Ludewig]

Mijn punt was niet meer en niet minder dan dat mij het gebruik van PuTTY verbaast in zeer kritische omgevingen. Klaarblijkelijk raakt dat gezien de reacties een gevoelige snaar. Bijzonder.

Ik denk dat er bij veel ontwikkelaars nogal veel frustratie is dat managers vaak blind op commerciële partijen dan wel closed source vertrouwen, ook al is er geen (strikte) SLA en ook al leveren die partijen in de praktijk vaak slechtere software en dienstverlening dan open source software en gratis support.

Ja, PuTTY en andere tools zijn defacto standaards lijkt het. Maar juist dat verbaast mij als auditor omdat ik op valide vragen over bruikbaarheid, fit-for-purpose, licentie, risico e.d., vaak vage of geen antwoorden krijg.

Maar hoeveel heeft dat met de specifieke tools te maken, en hoeveel met het feit dat de meeste bedrijven geen security experts hebben en de ontwikkelaars het er maar bij moeten doen, zonder opleiding of professionele hulp? Voor iemand zonder verstand van zaken is de keuze voor populaire software en hardware over het algemeen een prima heuristiek. De populariteit is op zich al een sterke indicatie wat betreft bruikbaarheid, fit-for-purpose, licentie, risico e.d, zeker als de software ook wordt gebruikt door bedrijven die wel security experts hebben.

En zeker als er geen alternatief is dan verwacht ik dat er mitigerende maatregelen getroffen zijn. Dus opslag van keys in een HSM, stepping stone, out-of-band management etc.

Geen van die zaken heeft ook maar iets te maken met de keuze voor PuTTY of een alternatief. Het zijn extra opties voor de inrichting van je omgeving die je al dan niet kunt toepassen.

Of het qua kosten/baten de moeite is hangt er natuurlijk maar helemaal van af. Gezien je opmerking dat je al die dingen verwacht, lijk je in de modus te staan die ik vaker bij auditors zie: 'alles moet, hoe klein de baten ook en hoe hoog de kosten ook zijn.'

Dat heeft wat mij betreft weinig te maken met een realistische kijk op hoeveel geld/menskracht bedrijven beschikbaar hebben en dergelijke adviezen zullen in de praktijk meestal in de la belanden, waardoor ook de aanpassingen met goede kosten/baten niet uitgevoerd worden.

[ernstoud]

Je voorlaatste alinea ga ik niet in mee. De rest onderschrijf ik.

Die voorlaatste alinea; alles gebaseerd op risico. Als ik een zeer kritisch proces t.o.v. een zeer kritische norm moet toetsen (denk aan de ETSI normen voor certificate authorities) dan ja, dan is dat een 100% toets op alle eisen en kom je niet weg met het benaderen in-band van de HSM met PuTTY als extreem voorbeeld.

We willen geen tweede DigiNotar zeg maar.

Maar beheer je een server die volgens je eigen risicoanalyse niet kritisch is en is de norm bijvoorbeeld 27001? Dan ben ik snel klaar als je in ieder geval nagedacht hebt over wat je aan het doen bent.

[Ludewig]

Als het een extreem kritische omgeving is kun je inderdaad veel verwachten, al denk ik dat de meeste organisaties vooral op de elementaire zaken moeten letten, zoals
- Geen wachtwoorden hergebruiken
- Geen wachtwoorden/keys open en bloot opslaan (in zeker niet in version control)
- Toegang beperken tot de mensen die het echt nodig hebben
- Security patches installeren
etc

Overigens sloeg DigiNotar ook wachtwoorden in tekstbestanden op en deden ze de security patches soms niet.

[ernstoud]

En hing de HSM aan internet. En hadden ze geen antivirus op de clients… na het incident heeft de onderzoeksraad een mooi rapport geschreven. Ik ben daarvoor nog geïnterviewd (https://onderzoeksraad.nl...r_nl_web_def_20062012.pdf).

Met de aanbevelingen in het rapport, met name aanbeveling 2, is weinig gedaan.

[mrdemc]

Putty is over het algemeen een prima tool. In het geval van deze kwetsbaarheid is het bijv. geen probleem als je een hardware key gebruikt om je private key op te slaan, die kan er namelijk niet af. Ik denk daarom ook dat het vooral belangrijk is inzichtelijk te hebben waar eventuele risico’s liggen en wat je ermee doet, verminderen, accepteren, verzekeren of vermijden. Maar dat staat los van het gebruik van PuTTY danwel OpenSSH als client. SSH onder Windows zelf werkt bijv. in de meeste gevallen prima maar is nog steeds niet in staat om de juiste key agent te gebruiken, waardoor hardware keys niet gebruikt kunnen worden bij PGP sleutels (wel via PKCS#12 dacht ik), laat staan via WSL een hardware key te kunnen gebruiken omdat de USB pass through alleen te gebruiken is voor storage devices de laatste keer dat ik keek. En persoonlijk, met bovenstaande info, gebruik ik dan liever PuTTY met een hardware key onder Windows dan een private key file met ssh.exe. Dezelfde master key is dan namelijk met de subkeys voor authentication, certifying, encryption en signature te gebruiken op Windows en Linux systemen voor communicatie, authenticatie (git/ssh) en handtekeningen (commits, mails, etc.)

[Reactie gewijzigd door mrdemc op 22 juli 2024 19:38]

[ernstoud]

Zeker, een HSM of andersoortige opslag van key materiaal is aan te raden. En dat is vaak te veel moeite, omdat netwerkbeheerders denken onfeilbaar te zijn. Niet altijd de beste personen om risico's in te schatten....

[maevian]

Er is helemaal geen probleem met de licentie van PuTTY om deze in een commerciële setting te gebruiken:

In particular, anybody (even companies) can use PuTTY without restriction (even for commercial purposes) and owe nothing to us, or to anybody else. Also, apart from having to maintain the copyright notice and the licence text in derivative products, anybody (even companies) can adapt the PuTTY source code into their own programs and products (even commercial products) and owe nothing to us or anybody else. And, of course, there is no warranty and if PuTTY causes you damage you're on your own, so don't use it if you're unhappy with that.

[ernstoud]

Dat is mijn punt niet. Ik ervaar alleen dat IT'ers in mijn audits software gebruiken waarvan ze de licentie niet kennen. Dat is een risico. En de tekst die je aanhaalt zegt "apart from having to maintain the copyright notice and the licence text in derivative products".

Dat is dan toch wel een vraag waard of er sprake is van "derivative products" bij de auditee. Is een dienst een product? Als de grootbank of service provider diensten ontwikkeld waarin PuTTY een rol speelt? Zoals dus bij Oracle waar PuTTY aangeraden wordt voor benaderen van de cloud?

Is maar een voorbeeld hoor... mijn ervaring is dat die hele licentie teksten door niemand waar dan ook gelezen worden. En dat is link. Zoals een klant jaren geleden ondervond die Windows Defender op zakelijke netwerken gebruikte (dat mocht indertijd alleen tot ik meen 25 PC's). Het is toch gratis, dus dan mag alles?

[moredruid]

Dat is dan toch wel een vraag waard of er sprake is van "derivative products" bij de auditee. Is een dienst een product? Als de grootbank of service provider diensten ontwikkeld waarin PuTTY een rol speelt? Zoals dus bij Oracle waar PuTTY aangeraden wordt voor benaderen van de cloud?

Mijns insziens net het verkeerde voorbeeld. Oracle heeft geen dienst ontwikkeld waarin PuTTY een rol speelt, zij geven aan dat je PuTTY _kunt_ gebruiken om hun infrastructuur te benaderen. Het is niet zo dat er geen alternatief is dat dit niet ook zou kunnen. En omdat PuTTY zich bewezen heeft wordt het vaak als de facto standaard gebruikt.

Ik ben het met je eens dat je je als systeembeheerder bewust moet zijn van de licensing van de tools die je gebruikt. In mijn ervaring zijn veel FLOSS aanhangers zich hier vaak veel bewuster van dan systeembeheerders die een betaald produkt beheren.

[ernstoud]

Het was een voorbeeld. En een voorbeeld vraag die gesteld zou kunnen worden als je software gebruikt voor een dienst. Kan dat volgens die licentie? Ik denk het wel maar een bedrijfsjurist kan dat beter beoordelen.

[Ludewig]

Ik ervaar alleen dat IT'ers in mijn audits software gebruiken waarvan ze de licentie niet kennen.

Maar dat is toch totaal offtopic in dit artikel over een kwetsbaarheid in Putty?

En de tekst die je aanhaalt zegt "apart from having to maintain the copyright notice and the licence text in derivative products".

Dat is dan toch wel een vraag waard of er sprake is van "derivative products" bij de auditee. Is een dienst een product?

Nee, dat is het uiteraard niet. De licentie zelf heeft het ook helemaal niet over derivative products, maar:

"The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software."

Dus als je de software levert aan derden of flinke delen van de code in je eigen product stopt moet je de licentie meeleveren. Dat is allemaal totaal irrelevant als je Putty binnen het bedrijf gebruikt om keys mee te maken en op servers in te loggen.

[ernstoud]

Mooi. Jij kan het onderbouwen dus. Mijn punt was dat veel audities dat niet kunnen.

[ernstoud]

Dat ik Oracle noemde was maar een voorbeeld. Welke vragen rijzen dan bij jou?

[REDSD]

Soms heb je niet meer nodig dan een paar simpele tools. professionele tools zijn niet per definitie veiliger. Vaak zijn ze moeilijker in gebruik, duurder en zijn ze er bij gebaat mogelijk security problemen te verdoezelen omdat er financiële gevolgen aanhangen.

We zijn meer gebaat bij diepgaande kennis waar we mee bezig zijn en ons software landschap zo simpel mogelijk te houden. Maar juist vaak door extra regelgeving is de techniek zoveel complexer geworden waar we mee werken om aan alle eisen te kunnen voldoen. Een probleem wat waarschijnlijk het duidelijkst zichtbaar is bij de overheid en iedereen die er mee te maken heeft.

[ernstoud]

"We zijn meer gebaat bij diepgaande kennis waar we mee bezig zijn en ons software landschap zo simpel mogelijk te houden."

Bingo.

Maar featurerites is een wijd verspreide ziekte.

[wiseger]

Is dat zo? Al decennia zie ik toch echt dat kosten de belangrijkste factor is.

Neem de gedeeltelijke cloud migratie die we momenteel bij heel veel bedrijven zien. Maakt voor een organisatie zijn IT hartstikke complex maar ja, het is wel goedkoper dan alles in eigen data centers houden.

Het zelfde voor outsourcing van de ontwikkelafdeling. Continue nieuwe ontwikkelaars uit een ver land. Hebben nauwelijks enige feeling met de geschiedenis van de codebase en het IT landschap. Maar ja, ze zijn wel goedkoper. En als ze duurder worden, dan ga je toch gewoon over naar weer een andere outsource partner uit een ander exotisch land.

Afschaffen van de test afdeling. Ontwikkelaar kunnen zelf toch ook heel goed testen? Dus waarom geld uitgeven voor een los departement? Laten we gaan SCRUM-en, lekker Agile en elke twee weken een sprint release naar de live omgeving.

Allemaal zaken uit de praktijk. Allemaal kosten gerelateerd.

[blinchik]

Port Knocking heb ik nog nooit gebruikt, gewoon IP blocks op poort 22 en 2factor op SSH logins.

[ernstoud]

Ja knockd is in praktijk niet echt makkelijk. Maar het kan nut hebben bij hoog risico en als je de SSH poort echt stealth wil/moet houden.

[latka]

Omdat de commerciele tools die ik hiervoor heb mogen gebruiken dermate slecht zijn (alleen ondersteuning voor wazige terminal formaten, slechte integratie in de UI op de desktop (crash bij resize van het window bijv). Dan zegt de afdeling inkoop dat we die moeten gebruiken (zonder dat zij overigens in staat zijn te controleren of deze software wel of niet veilig is, maar dat is secundair) dus dan pak je iets wat wel gewoon werkt.

[ernstoud]

Prima. Maar breng dan even de risico's ook in kaart. En zorg dat je die kunt toelichten als er om gevraagd wordt.

[latka]

Maar mijn andere punt: hoe weten we dat commerciele software wel veilig is? Dat weten we nog minder dan voor open-source software. Er staat wellicht iets in de inkoop overeenkomt, maar daar staat zeker niet: "onze software is 100% veilig en bevat geen achterdeuren". Hooguit: onze software is wordt ontwikkeld volgens de hoogste standaarden en we hebben een ISO certificaat. Wat geen waarde heeft en helemaal niet betekent dat de software nu goed is.

[ernstoud]

Dat weten we helaas niet. Dus - bij hoog risico - extra maatregelen treffen.

En dan weer die verwondering… hoe kan het eigenlijk na zeg 50 jaar ICT dat we de veiligheid niet kunnen inschatten?

[latka]

Ah, dat kan ik dan wel academisch onderbouwd beargumenteren.
Enerzijds: ja, dat kunnen we als we de complexiteit van software drastisch verlagen. Anderzijds: dat willen we niet dus moeten we accepteren dat een een beetje software systeem zoveel toestanden kent dat onmogelijk is die allemaal te testen (google 'state space explosion' als je de nitty gritty wilt weten).
We kunnen wel op basis van een aantal regels werken om het aantal mogelijk toestanden te verlagen (garbage collection ipv. manual memory management, typed-languages vs. untyped languages etc.) maar dan nog is het ondoenlijk alles af te testen.
Als je me 5 jaar geleden gevraagd had of log4j veilig was had ik je verbaast aangekeken en gezegd dat het me zeer onwaarschijnlijk lijkt dat daar iets mis in zit. En dat was ook zo: het werkelijke probleem zat in de onderliggende JDK en de jndi code daarin. Dus zelfs als software an sich veilig is kunnen de omstandigheden het onveilig maken. Vergelijkbaar met spectre: de browser an sich is niet onveilig, maar de combinatie van Javascript in een browser en een onveilige CPU maken het totaal onveilig.

[ernstoud]

Die academische onderbouwing is de bottle neck. Ik heb van Edsgar Dijkstra zijn colleges indertijd begrepen dat bewijs van correcte werking van software onmogelijk is.

Dus daar gaan we…

[CyBeR]

Die zijn er wel, maar er is vrijwel geen reden om die te gebruiken boven PuTTY of een andere open source oplossing.

En zoals @Kip ook al zegt, er zijn welgeteld nul omgevingen wereldwijd waarin geen enkele vorm van software voorkomt die op vrijwillige basis (meestal open source) is gemaakt en wordt onderhouden. De commerciele OS'en hebben ook dergelijke software aan boord en als je hardware geavanceerder is dan een opamp zit er firmware op waar waarschijnlijk ook dergelijke software in verwerkt zit.

[downtime]

Verwondert me helemaal niet. Het is in een organisatie vaak zo lastig om budget voor een stukje software te krijgen waarvan de non-techneuten niet snappen wat het doet, dat het heel verleidelijk is om maar gewoon een gratis product te gebruiken. Downloaden en installeren en je kunt weer verder met je werk.

Overigens is onderhoud door hobbyisten natuurlijk niet perse een issue. Dat iemand een stuk software als hobby onderhoudt maakt hem niet minder (of meer) capabel.

[Rolfie]

Want? Andere software wordt niet door developers ontwikkeld?

PuTTY is juist de standaard als applicatie en werkt juist heel effectief.

Wat je wel vaak ziet, is dan men dit soort applicaties nooit update.

Maar op een een steppingstone, PuTTY installeren?

[ernstoud]

Nee. Stepping stone benaderen met PuTTY en vandaar uit out-of-band of via een HSM, of.... oplossingen zat. Uiteraard alleen als het om kritische processen gaat en dit alles uit de kosten/baten analyse verantwoord is.

[beerse]

Zie je verwondering als dat er een protocol is afgesproken (het ssh protocol) Dat heeft met namen onder msWindows (en msDos) heel veel verschillende implementaties. Bijvoorbeeld cygwin, scp, moba-x-term, ssh, winssh, openssh en nog veel meer. Naar mijn idee is putty daar beslist niet de beste in.

Wel is putty door de msWindows beheeerders omarmd omdat ze redelijk voordelig en makkelijk aan de gang gekregen kan worden, ze komt met een eigen terminal-emulator en ze is vooral windows georiënteerd. Een ander voordeel is wel dat ze niet echt geïnstalleerd hoeft te worden.

Ook een gedachte is dat ze nu nog steeds niet in versie 1 is aangeland: download: PuTTY 0.81 geeft aan dat ze onlangs versie 0.8 is gepasseerd.

De linux beheerder in mij is altijd ver van putty gebleven. Deels omdat ze mij veel te veel windows georiënteerd is, deels omdat ze zich niet aan de ssh-client standaarden houdt qua bestand-opslag. En ook voor een deel omdat de terminal-emulator ruimte voor verbetering heeft.

Om het vergelijk met andere techneuten en gereedschappen te maken: Putty is gereedschap waarmee je zou kunnen werken, zoals een hamer, bijtel, schroevendraaier en een zaag. Dat kan ook allemaal met een serieus kamp-mes maar het juiste gereedschap geeft vaak eenvoudiger een beter resultaat.

[Reactie gewijzigd door beerse op 22 juli 2024 19:38]

[magnifor]

Dat iets wordt onderhouden door een hobbyist of een professioneel bedrijf zegt onder de streep weinig over de veiligheid van de software. Fortinet is een miljarden bedrijf maar hun software is de laatste tijd zo lek als een mandje gebleken. Cisco is zogenaamd super veilig en professioneel maar toch hebben ze bewust backdoors ingebouwd in hun software en apparatuur voor uncle sam.

Als ik bijvoorbeeld kijk naar het aantal CVE van Putty dan kom ik uit op op 31 stuks: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=putty
OpenSSH wat zogenaamd een veiliger alternatief zou zijn zit op 144 stuks: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=openssh

Als je beseft dat Putty bestaat vanaf 1998 en maar 31 gerapporteerde CVE's heeft vind ik dat zeer netjes.

[ernstoud]

Zonder te weten wat die 31 CVE’s (eventueel) voor schade hebben berokkend, ga ik er niet in mee of gemiddeld 1 CVE per jaar “netjes” is.

In XZ 14 in 10 jaar. Waarvan de laatste een impact op heel internet had kunnen hebben.

Dus aantal zegt niets.

[Bender]

Dus als ze voor PuTTY geld zouden vragen, waarmee het een commerciële oplossing is dan zou het je niet meer verbazen?

Dat is natuurlijk ook geen logische gedachtegang.
Windows is professionele software met veeeel dure betaalde developers, maar dat geeft ook geen garantie dat het volledig veilig is.

[ernstoud]

Dat zeg ik niet, je legt me woorden in de mond.

Ik zeg alleen dat me e.e.a. verbaast als ik zie bij een grootbank dat systemen waar miljarden per dag doorheen gaan benadert worden met PuTTY.

[Blokker_1999]

Je bent verbaasd omdat mensen een breed gedragen, open source client gebruiken zonder enige garantie vanuit de maker. Je vind dat onprofessioneel overkomen, maar je geeft ook geen alternatieven die je dan wel zou verwachten met als enige uitzondering dat je vindt dat men dan maar bijv. OpenSSH moet gebruiken, maar dat is evenzeer een breed gedragen, open source client waarbij de makers geen enkele garantie geven.

En ja, bij Windows gebruikers zie je wel een steeds betere adoptie van OpenSSH daar het gewoon meegeleverd wordt met het OS dezer dagen en je zelfs gewoon remote PowerShell over SSH kunt doen met die client.

Kom eens af met wat alternatieven en waarom die juist beter zouden zijn volgens jouw. Wat zij als meerwaarde hebben, waarom het ineens professioneler zou zijn als je die tools zou gebruiken.

[XiMMiX]

Misschien moeten men maar Solarwinds Orion installeren, dat is van een groot professioneel software bedrijf. Daar zullen ze nooit "solarwinds123" als wachtwoord gebruiken waardoor een hacker een backdoor in de software kan installeren.

[YoMarK]

Nadat hierboven al 5 mensen je vragen om te beargumenteren waarom geen Putty en welke ssh/terminal client dan wel, is dit je beste antwoord:

Het is mijn taak niet, niet bij klanten en niet hier op Tweakers om aan te geven wat beter is, wat de alternatieven zijn etc.

Inderdaad...."Tjonge"...

[YoMarK]

In plaats van zeggen dat je het bijzonder vind....leg nu gewoon eens uit WAAROM Putty volgens jou dan niet gebruikt zou moeten worden om de PLC die aan de turbine hangt te benaderen?

Ik heb veel ervaring met zowel Siemens programmatuur als wel (geïsoleerde)SCADA omgevingen, en laten we het zo zeggen: Putty gaat daar het probleem niet zijn. Niet als ssh client. Niet als seriele client. Wat dus wel blijkt is dat het net als alle software up to date moet worden gehouden ( maar een klein gedeelte van de users zal getroffen kunnen worden door dit probleem overigens).
Als jij bij ons een audit zou komen doen, dan zou ik voor de AANBEVELING "geen putty gebruiken" daar op z'n een WAAROM naast willen zien met iets anders als "heel bijzonder".

[ernstoud]

Ik zeg helemaal niet dat je PuTTY niet zou mogen gebruiken. Ik zei dat het me verwondert. Dat is wat anders. En daar heb ik op toegelicht dat dan voornamelijk het niet onderkennen en analyseren van risico’s wel de belangrijkste reden voor is, voor die verwondering dus.

En een auditor die aanbeveelt om geen PuTTY te gebruiken moet je de deur wijzen. De auditor kan wel - uiteraard op basis van een norm die dat vereist - vragen of de risico’s bekend zijn. En de afweging, de accordering e.d.

In de Siemens wereld waarin ik rondgelopen heb is elk tool gecertificeerd voor gebruik. En nog maakten we mee dat de monteur malware op de notebook had omdat hij ‘s-avonds de notebook voor parametrisering van scada systemen ook gebruikte voor e-mail en natuurfilms kijken. (Of niet door de alcohol controle aan de poort kwam, maar dat is een ander verhaal.)

[mrdemc]

Als ik jou dan goed begrijp dan had je het misschien beter anders kunnen verwoorden en kunnen aangeven dat je je verwondert dat "mensen" PuTTY gebruiken zonder een risico-analyse.
Persoonlijk zou ik dan verwachten dat jij je zou verwonderen dat "mensen" software gebruiken zonder een risico-analyse en dat je dit vooral bij kleine tooling als PuTTY ziet gebeuren, de schaduw-IT in feite. Klopt dat?
Dat staat uiteraard los van PuTTY en heeft vooral te maken met de manier waarop bepaalde mensen waar je mee te maken hebt dan werken.
Ik denk dat daarom dat hier vooral de discussie aan wordt gegaan omdat je specifiek lijkt te doelen op het gebruik van PuTTY terwijl je eigenlijk mogelijk bedoeld te zeggen wat ik hierboven aangeef.

[ernstoud]

Gezien de vele redelijk negatieve reacties had ik helemaal niet moeten posten.

Ik heb alleen kort gezegd in de opening post dat het gebruik van PuTTY me verwondert. Klaarblijkelijk had ik alle alternatieven moeten opsommen, de discussie open/closed source moeten duiden, aan moeten geven wat alle mitigerende maatregelen dan zijn, wat je moet doen om meer zekerheid te krijgen en een college risicoanalyse hier moeten geven. En dan vergeet ik nogal wat.

Geez…

Op social media en nu zelfs op Tweakers lijkt het zo te zijn dat de reactie op een post vooral polariserend, aanvallend moet zijn.

Als de uitspraak dat het gebruik van PuTTY me verwondert, uitgebreid toegelicht, leidt tot hele polemieken dan zal ik daar het boetekleed maar voor aantrekken dan. Jammer. Ik zal me verder onthouden van commentaar.

[Reactie gewijzigd door ernstoud op 22 juli 2024 19:38]

[mrdemc]

Ik moet wel zeggen dat je er ook wel behoorlijk tegen ingaat zelf, dat werkt polariserende reacties wel in de hand
Volgens mij ben ik redelijk in mijn bewoordingen en probeer ik juist wat duidelijkheid te scheppen, maar toch vind ik jouw reactie nu enigszins overkomen als emotioneel. Is wat mij betreft in ieder geval niet nodig

[ernstoud]

Zoals gezegd. Ik onthoud me verder van commentaar.

[EiT]

Beetje kort door de bocht. Je kan ook stellen dat deze hobbyist het dan snel oppakt en oplost. Er zijn zat grote partijen die maanden nodig hebben om security problemen op te lossen.

Ik zeg overigens niet dat iedereen maar PuTTY moet gebruiken, maar je moet voor elk stuk software de risico’s weten/aanvaarden. Andere zou je ook geen browser meer kunnen gebruiken.

Als je ergens een mening over kan hebben is dat deze software na 25 jaar nog updates ontvangt. Hoeveel bedrijven draaien op legacy rommel en hoe is de kennis van de IT of gebruikers daar? Ik denk dat er grotere problemen zijn dan een organisatie binnenlopen en druk maken dat er PuTTY wordt gebruikt.

[Aidix]

Eigenlijk is de hele Linux kernel ' hobbymatig door developers onderhouden'.
Dat het meestal wel aardig werkt is meer geluk dan wijsheid heb ik soms het idee

[ernstoud]

Na 50 jaar Iin de IT heb ik het idee dat er overal nog veel hobby matig gewerkt wordt. Er is veel verbeterd, maar dezelfde fouten uit die begintijd worden nog steeds gemaakt. Kijk eens naar de OWASP lijst (https://owasp.org/www-project-top-ten/), tussen 2017 en 2021 is injection van plaats 1 naar plaats 3 gegaan. Dan noemen we dan verbetering. In vier jaar tijd niet geleerd hoe die kwetsbaarheid 100% weg te nemen.

Het wordt beter, maar het gaat (te) langzaam.

[Reactie gewijzigd door ernstoud op 22 juli 2024 19:38]

[wiseger]

Na 50 jaar in de IT zou je inmiddels toch wel door moeten hebben dat alles een kwestie van geld is?

Het heeft niks te maken met hobby matig werken, het heeft alles te maken met budgetteringen. Hoeveel geld wil je uittrekken voor de veiligheid? Dat is waar de schoen al heel lang wringt.

Bijna elke kwetsbaarheid kan je wegwerken of voorkomen, echter dat betekend heel veel meer testen, code scannen, code reviewen, werken met vast personeel i.p.v. de eeuwige zoektocht naar de goedkoopste outsourcing. Kortom allemaal extra werk waardoor je extra resources nodig hebt en de kosten op korte termijn aardig toenemen.

Op de korte termijn veel extra kosten maar wel extra veilig op de lange termijn. Zal het senior management er toch voor kiezen?

[witstert]

I apologise for making my ignorance obvious! It will help this aged Person if at the first use of an acronym, e.g. PuTTY or KiTTY, the author of the article or comment were to specify the words that result in the acronym.

[ernstoud]

From the PuTTY FAQ (https://www.chiark.greene...ty/faq.html#faq-meaning):

“It's the name of a popular SSH and Telnet client. Any other meaning is in the eye of the beholder. It's been rumoured that ‘PuTTY’ is the antonym of ‘getty’, or that it's the stuff that makes your Windows useful, or that it's a kind of plutonium Teletype. We couldn't possibly comment on such allegations.”

And KiTTY is a fork, i.e. an enhanced version created by another person or group of persons. I guess that party choose the name KiTTY since PuTTY could also be seen as a pronunciation of “pussy”.

[witstert]

Hmmm! "KiSSY" and "PuSSY", Interesting combination if combined in a line of poetry with mention of that word that incorporates *****lingus from Hair!

Thank you for the explanations.

[tweazer]

Securecrt al eens geprobeerd ?

[ernstoud]

Dank voor de link. Ik ga er naar kijken.

[wiseger]

Open source tools worden door een breed publiek bekeken. Zo kwamen de pogingen om een kwetsbaarheid in XZ te krijgen al heel snel aan het licht juist door de community.

Gesloten source heeft ook gewoon haar zero day lekken en ingebouwde backdoor problemen. Het duurt alleen soms wat langer voordat de backdoor ontdekt is. Maar zoek maar eens op Cisco en backdoor en er gaat een wereld voor je open. En dat is toch echt closed source.

Dus als jij al netwerk auditor braaf alle Cisco apparatuur met Internet-facing IOS XE afvinkt terwijl je beheerders die toegang hebben via Putty als risico markeert, tja dat is dan toch echt voor je eigen rekening.

[wiseger]

Ach hou toch op zeg Je begint zelf met:

Ik begrijp de open source wereld en de kwaliteit is soms ok.,

En daarna begin je met:

De open vs. closed source discussie hebben we gehad. Die stammenstrijd leidt tot niets.

En geen idee wat auditors doen? Man ik heb er continue mee te maken en mij bekruipt al heel lang het gevoel, weten auditors wel waar ze me bezig zijn?

[likewise]

Ik ga ervan uit dat @ernstoud de code van PuTTY leest en de zwakheden pinpoint. Wat heb ik anders aan een auditor?

[jrswgtr]

Tegenwoordig kun je toch gewoon OpenSSH gebruiken in Windows Powershell?

Waarom zou je daar urberhaupt nog een andere tool voor gebruiken?

[cricque]

Omdat jarenlang Putty het enige was wat je eigenlijk kon gebruiken op Windows. En veel mensen zijn dat blijven gebruiken. Ik heb slechts een paar x in mijn leven Powershell gebruikt. Maarja ik werk 99,9% op linux systemen. Dat het nu kan via Windows Powershell wist ik zelfs niet. Maar Putty werkt gewoon en is gewoon een gekende tool. En het doet wat het moet doen, zonder al te veel franjes. En ik zal vast niet de enige zijn die niet weet dat je dit ook kunt via Powershell.

[.oisyn]

Ik snap niet zo goed waarom je PowerShell erbij betrekt. OpenSSH is gewoon een console applicatie, die werkt in elke shell, dus ook onder CMD.

.edit: oh, ik zie het, dat zeg je omdat @jrswgtr dat beweert. Dat klopt dus niet

[Reactie gewijzigd door .oisyn op 22 juli 2024 19:38]

[beerse]

Sinds een paar jaar levert microsoft op het msWindows platform een implementatie van openssh mee. Die is vooral goed bruikbaar vanaf de powershell prompt. Inclusief zaken als de ~/.ssh/ directory met config files, inclusief de ssh-agent en ssh-add commando's en dergelijke.

Voor de echte tweakers was openssh altijd al beschikbaar via cygwin (en mobaXterm en dergelijke).

[.oisyn]

Die is vooral goed bruikbaar vanaf de powershell prompt.

Maar dat is gewoon niet waar. In de gewone CMD prompt doet hij net het zo goed.

Of ben je eigenlijk in de war met Windows Terminal, de nieuwe terminal emulator die het oude conhost vervangt? Een veel voorkomende misvatting is dat CMD gelinkt is aan conhost en PowerShell aan Windows Terminal, en zegt men vaak CMD terwijl men conhost bedoelt. Maar beide shells werken in beide terminals.

Persoonlijk kan ik ook niet wennen aan PS en werk ik gewoon in CMD, maar wel in Windows Terminal. En ik SSH ook vaak naar mijn NAS of mijn router, inclusief standaard keys die in ~/.ssh/ staan, dat heeft verder weinig met PS te maken.

[Reactie gewijzigd door .oisyn op 22 juli 2024 19:38]

[beerse]

Toegegeven, ik was al veel eerder om naar powershell en daarna een keertje ssh aangetroffen. Ik wil nog wel eens de unix/linux commando's gebruiken die het voor een deel (en beperkt) in powershell ook doen.

Over de terminal-emulator die gebruikt wordt, dat is volgens mij allemaal de vt-102 zoals de cmd-prompt (en daarvoor de dos-box) dat ook altijd aanboden. Al kan het zijn dat de windows terminal meer terminals kan emuleren, daar heb ik nog niet naar gezocht/gekeken omdat ik ze nog niet nodig heb gehad.

[.oisyn]

dat is volgens mij allemaal de vt-102 zoals de cmd-prompt (en daarvoor de dos-box) dat ook altijd aanboden.

Dat is dus de misvatting. De command prompt biedt geen terminal emulator aan, dat is gewoon een console applicatie die een shell implementeert.

Een console applicatie draait in een terminal emulator die de textuele output van de app interpreteert en naar een GUI rendert, en de userinput weer doorrouteert naar de applicatie. De legacy emulator heet dus conhost (al is dat vanaf W8 geloof ik, het heeft door de jaren heen meerdere namen gehad maar allemaal doorevoluties van dezelfde codebase). Voor W10 hebben ze de hele backend opnieuw ontworpen waardoor de emulator makkelijker te vervangen is, en je niet meer vastzit aan de oude gelimiteerde console API (zoals volledige utf-8 compatibiliteit en full color ipv louter 16-bits karakters en 16 kleuren).

[beerse]

Hoe je het ook wend of keert, een terminal of console applicaitie heeft een methode om de karakters in beeld te brengen en hoe daar de kleur en het lettertype van in te stellen. Dat kan op vele manieren. De manier waarop de VT102 terminal van Digital Equipment het deed was best goed, al waren in 1990 de vt330 en daarna de vt400 naar mijn idee een veel betere geweest om te gebruiken. Dat zal wel iets met licenties te maken hebben. Natuurlijk hebben ook andere hardware leveranciers in die tijd hun eigen terminals geleverd met eigen instellingen.

Wat ik mij af vraag is hoe ze de instellingen als geheel bij elkaar noemen. In linux termen: Wat is de waarde van de $TERM environment variabele die ik kan doorgeven zodat alle mogelijkheden worden gebruikt. Nu ik er toch maar even zelf naar kijk zie ik dat zowel de powershell als ook de cmd box beide met ssh naar een linux omgeving de $TERM op xterm-256color zetten. Toegegeven: Ik had er al lang niet naar gekeken, ook geen noodzaak toe gehad.

[cyclone]

Omdat Putty gewoon een fijne gui heeft (waarin ik alle hosts in kan opslaan en ook nog b.v. voor seriële communicatie kan gebruiken) en OpenSSH een CLI tool is ?
(en ja ik weet dat Putty ook op de CLI te gebruiken is)

[jrswgtr]

Fijne GUI? Dat is subjectief, ik vind het vreselijk.

Oke, de kwesie van hosts opslaan kan ik me nog voorstellen. Maar in bash ik heb die altijd heel snel ervoor met CTRL+R.

[ernstoud]

Een interface dat in de vorige eeuw thuis hoort. KiTTY is wat beter en ik meen dat er een fork is met tabbladen.

[Thijn41]

Waarom niet? Waarschijnlijk zijn er een hoop windows gebruikers gewent geraakt aan PuTTY.
Vind de UI soms ook wel prettig om bijvoorbeeld tunnels op te zetten.

PuTTY heeft ook ondersteuning voor COM poorten of telnet, dus er zitten meer functionaliteit in dan SSH alleen.

OpenSSH heeft natuurlijk ook kwetsbaarheden (gehad), dus dat is geen argument.

[PolarBear]

Tegenwoordig kun je toch gewoon OpenSSH gebruiken in Windows Powershell?

En OpenSSH is een magische tool die zonder fouten tot stand komt? Nee het is ook een opensource tool met een beperkt aantal contributers

[The Zep Man]

Alleen Ecdsa-keys van 521bit zijn kwetsbaar. Dergelijke keys zijn bovendien alleen kwetsbaar als ze zijn gebruikt via de PuTTY-client of de PuTTY Authentication Agent.

Dit is belangrijk. Je hebt sowieso nergens last van als je RSA of ed25519-gebaseerde sleutels gebruikt.

[Oon]

Ik snap niet waarom mensen tegenwoordig nog RSA keys zouden gebruiken, ED25519 is een stuk efficiënter en met het algoritme dat erachter zit nét iets veiliger dan RSA met 4096 bits.
Ik heb wel eens mijn key moeten overtypen naar een terminal waar ik alleen fysiek bij kon, toen was ik toch heel blij dat ik geen 4096-bit RSA key gebruik

[The Zep Man]

Ik snap niet waarom mensen tegenwoordig nog RSA keys zouden gebruiken,

Verouderde crypto policies, oude (embedded) SSH servers die geen ed25519 ondersteunen...

[Oon]

Maar die zullen dan niet open staan naar het internet, hoop ik

Dan zou dus ook deze kwetsbaarheid in PuTTY niet zo heel relevant zijn, want dan moeten ze eerst door de firewall heen

[The Zep Man]

Maar die zullen dan niet open staan naar het internet, hoop ik

Een oude SSH server kan nog steeds updates ontvangen, ook al voegen die updates geen nieuwe functies toe. RSA op zich is niet onveilig. Hooguit inefficiënt.

En sowieso is een afgeschermde omgeving altijd te verkiezen t.o.v. zaken direct aan het internet hangen.

[Reactie gewijzigd door The Zep Man op 22 juli 2024 19:38]

[beerse]

De meeste zullen rsa keys gebruiken uit efficiëntie: Als je geen opties wilt meegeven als je met keys gaat werken, dan was dat lang de default. Pas de recente ssh implementaties gebruiken standaard ed25519.

En als je dan verbinding zoekt met oude of antieke implementaties, blijkt het niet te werken omdat dergelijk antiek ook vaak niet is bijgewerkt en op haar best rsa ondersteunt....

Het is maar net naar welke efficiëntie je kijkt...

[xorpd]

ECC is niet zozeer veiliger dan RSA. Niemand weet hoe ze elliptische curves moeten terugrekenen, maar dat wil niet zeggen dat het niet kan. Het is wel stukken compacter ja.

[freeco]

Klopt ja, het is meer dan gewoon effe PuTTY (en ook tools als WinSCP, FileZilla, etc) te updaten.
Dat staat vrij duidelijk hier.
Alleen vraag ik me af hoe je kan checken of je keys hebt van dat 521-bit ECDSA type. Ik beheer een Windows jumphost met oa die 3 tools voor de VMware collega's in mijn team, maar gebruik die tools zelf nooit. Dus op dat vlak ben ik weinig onderlegd...
Mocht iemand me in de richting van een artikeltje kunnen sturen met uitleg over key types nakijken, dat zou hard geapprecieerd zijn!

[jvwou123]

521bit? Moet dat niet 512 zijn?

[The Zep Man]

Bron:

In 1999, NIST recommended fifteen elliptic curves. Specifically, FIPS 186-4 has ten recommended finite fields:

• Five prime fields Fp for certain primes p of sizes 192, 224, 256, 384, and 521 bits. For each of the prime fields, one elliptic curve is recommended.

Dat is geen typo.

[Reactie gewijzigd door The Zep Man op 22 juli 2024 19:38]

[jvwou123]

Thanks, weer wat geleerd vandaag!

[Mastakilla]

Als ik naar de laatste versie van WinSCP kijk op https://winscp.net/eng/download.php dan zie ik "SSH core upgraded to PuTTY 0.80. That includes support for HMAC-SHA-512 and mitigation of “Terrapin” vulnerability.".
Dit lijkt mij dan toch steeds de vurnable putty te gebruiken, niet?

[Mounir]

De laatste "officiele" release (6.3.2) van WinSCP heeft inderdaad nog niet de nieuwe PuTTY versie, 6.3.3 (nog niet gereleased) wel:

6.3.3 (not released yet)
2024-04-16
SSH core and SSH private key tools (PuTTYgen and Pageant) upgraded to PuTTY 0.81.
It brings the following change:

Security fix for CVE-2024-31497: NIST P521/ecdsa-sha2-nistp521 signatures are no longer generated with biased values of k. The previous bias compromises private keys. vuln-p521-bias

...

Terrapin is een andere vulnerability.

[Reactie gewijzigd door Mounir op 22 juli 2024 19:38]

[Cageman1984]

Ik gebruikte putty vroeger om vanuit windows mij Pi te benaderen. Tegenwoordig pak ik daar gewoon terminal voor en gebruik ssh (net zoals in linux)

klopt het dat ssh in dit geval hier geen last van heeft?

En waarvoor zou je specifiek putty gebruiken als je ssh kan gebruiken?

(off topic) is termius voor android wel veilig?

[The Zep Man]

klopt het dat ssh in dit geval hier geen last van heeft?

Klopt.

En waarvoor zou je specifiek putty gebruiken als je ssh kan gebruiken?

OpenSSH is niet beschikbaar in elke win32-omgeving. PuTTY is in dergelijke gevallen een stuk lichter.

[Cageman1984]

OpenSSH is niet beschikbaar in elke win32-omgeving. PuTTY is in dergelijke gevallen een stuk lichter.

Oke dat wist ik niet. Ik wist überhaupt niet dat openSSH een 'zware' applicatie was.

[The Zep Man]

OpenSSH zelf is niet zwaar, maar alle afhankelijkheden zijn dat wel. PuTTY heeft veel meer zaken geïntegreerd, zoals een eigen implementatie van het protocol en specifieke win32-ondersteuning. Daardoor is het een stuk lichter.

[beerse]

Via cygwin kan je al sinds msDos gebruik maken van openssh op microsoft platformen.

Maar toegegeven, microsoft heeft niet op alle huidige/courante versies een openssh implementatie beschikbaar. Tel daar bij dat het ook nog eens als optie moet worden aangevinkt.

[The Zep Man]

Via cygwin kan je al sinds msDos gebruik maken van openssh op microsoft platformen.

Cygwin is een niet vanuit Microsoft ondersteunde omweg die inderdaad al heel lang werkt. Maar als je dat gaat installeren, dan kan je net zo goed PuTTY kiezen. OpenSSH in Cygwin is ten opzichte van PuTTY (native win32-applicatie) best wel zwaar qua footprint door de libraries en de POSIX-vertaallaag.

[scsirob]

En waarvoor zou je specifiek putty gebruiken als je ssh kan gebruiken?

Voor mij is het een uitkomst dat PuTTY instellingen per server kan opslaan. Bijvoorbeeld wel of geen bell, wel of geen x11 forwarding, enz. Misschien kan dat met ssh ook, maar dan moet ik het zelf onthouden.

[JoHnnY-Btm]

zat ik nou net te denken om deze tool eens te gaan in zien... laat maar zitten

[ernstoud]

Zoals bij alles; ken het risico. PuTTY is prima voor gebruik in je LAN of voor minder kritische systemen. Gewoon nadenken bij wat je doet.

[Klauwhamer]

Maar waarom is het dan niet prima voor kritische systemen? Waarom denk je niet na als je PuTTY gebruikt voor een kritisch systeem? Dat is namelijk wat je bijna expliciet zegt. En het bestaan van kwestbaarheden an sich kan nooit een reden zijn voor deze statements, ook niet als auditor.

[ernstoud]

Je tweede zin… dat is niet wat ik zeg. Juist bij kritische systemen moet je (meer) nadenken. Analyseren, toetsen, maatregelen bedenken.

[Klauwhamer]

Maar wat zeg je dan wél (en aanpalend is het storend dat je zelf ambigu at best schrijft om vervolgens niet verder te gaan dan 'dat zeg ik helemaal niet') en wat bedoel je daar allemaal precies mee? Maak het eens concreet. Waarover moet men precies nadenken, wat moet geanalyseerd worden, wat moet getoetst worden, en welke mitigerende maatregelen moeten bedacht worden inzake deze kwetsbaarheid? Het punt is vooral dat er áltijd restrisico is op kwetsbaarheden, ongeacht de kwaliteit van je RA en RTP.

[ernstoud]

Kom op zeg, ik ga hier geen leergang security management neerpennen!

Ik hoef niets concreet te maken, dat doen de normen waar ik tegen toets, dus bijvoorbeeld 9001, 27001, 22301, 7510, ETSI 44x serie etc.

Die normen definiëren de scope en diepgang. In clause 6 van 27001 staat het risico analyse proces beschreven. In iets van 35 eisen. Dat gaan we hier toch niet bespreken?

[Klauwhamer]

Ik zou niet weten waarom niet. Ik ben wel benieuwd naar jouw auditor-visie hier op inzake deze kwetsbaarheid in PuTTY, daarom vroeg ik daar ook naar. Wel leuk trouwens dat jij vindt niets concreet of concreter te hoeven maken op een forum met een open discussie terwijl NOREA geregeld handreikingen en duidingen biedt op de normen die beschreven staan (DigiD), en bijvoorbeeld Cees van der Wens een aardige grijpstuiver pakt op duiden van de geschreven norm. Terug naar PuTTY: waarom vind jij het niet prima voor kritische systemen en ben je het oneens met het altijd bestaan van restrisico?

[Reactie gewijzigd door Klauwhamer op 22 juli 2024 19:38]

[ernstoud]

Ik wil je met alle plezier alles vertellen over een norm, de eisen daarin etc. Maar de cursus die ik gaf daarover duurt 3 dagen. Dus om dat nu hier te gaan doen? Nee dus.

Ken je 27001 niet? Dan NEN7510 gratis “kopen” bij NEN. Clausules 4 t/m 10 zijn identiek. Veel leesplezier.

Ik heb dat duiden in 2002 ook gedaan (Praktijkgids Code voor Informatiebeveiliging) bij Kluwer. En ik kan je vertellen, voor de verdiensten hoef je het niet te doen. Een druk is een paar duizend boeken, de markt is klein en de opbrengst zit in de orde van een euro per verkocht exemplaar.

En ja, Cees van der Wens is heel erg van het “duiden”. Ik ben meer van het “leg eens uit waarom je het zo doet”.

Antwoord op je concrete vraag aan het einde: onderbouw bij een beetje kritisch systeem het gebruik zelf maar, passend bij het restrisico dat je wil. Zie daar; een auditor heeft heel makkelijk werk. Vanuit interesse in het proces en de eisen in de norm vragen stellen aan de auditee.

Dus: wat vind je zelf? Gebruik je PuTTY? En in dat proces? Past dat?

(En dan moet je antwoord dus passen bij de norm, bijvoorbeeld 27001::dreigingen bekend, kansen en impact bepaald, restrisico duidelijk, geaccepteerd of gemitigeerd en in dat laatste geval passende maatregelen gekozen en geïmplementeerd uit Annex A.?)

[Klauwhamer]

Prima, dan geef je geen antwoord maar nu met nog meer letters. Ik moest wel lachen om het negeren van NOREA en je backhanded compliment richting Van Der Wens. Typisch

[ernstoud]

Dat ik NOREA vergat te noemen was geheel per ongeluk.

Mijn persoonlijke mening (die ik wel in het veld hoor) is dat NOREA in de vele jaren dat ze bestaan aan het security werkveld weinig tot niets hebben toegevoegd.

En ik heb je antwoord gegeven… als je wilt weten hoe een risicoanalyse moet en de eisen, koop NEN7510. Of verwacht je nu echt dat ik die 10 pagina’s copyrighted tekst hier ga dumpen?

[Reactie gewijzigd door ernstoud op 22 juli 2024 19:38]

[Keyb]

Ja? En wat heb je als alternatief waar geen security issues in bestaan?

[downtime]

en er zijn in het algemeen relatief genoeg apps / software waar geen security issues zijn.

Nee, die zijn er niet, er zijn wel een heleboel apps waar de security issues nog niet gevonden zijn.

[JoHnnY-Btm]

dat is zeker mogelijk zonder enige twijfel.. maar daar hebben we weer pegasus voor LOL

[pbeyens]

Inderdaad, als we alle software moeten vermijden waar nog geen vulnerability in gevonden is, dan gaan we beter terug naar pen en papier.
Ik heb in mijn 25 jarige carière al héél veel dure software pakketten beheerd, en daar worden/werden om de paar weken wel vulnerabilities in gevonden. Het is een continue kat en muis spel tussen development/integratie en hackers. Dit gaat niet veranderen door wat extra te betalen aan een softwareontwikkelaar.

[dakka]

als je echt diep wilt gaan, als je op papier op een ietwat zachte ondergrond wat schrijft, kan dat ook achterhaald worden, de surface cache eigenschap van het materiaal zeg maar, is in plain text uit te lezen door iedereen

[anboni]

en er zijn in het algemeen relatief genoeg apps / software waar geen security issues in gevonden zijn

FTFY

[dasiro]

Met de gestolen keys kunnen aanvallers vervolgens valse signatures maken en zich toegang verschaffen tot servers waarop de betreffende key is gebruikt

ik kan me vergissen, maar is die key niet enkel om de verbinding te beveiligen en niet specifiek om toegang te krijgen tot de remote host? Als de credentials veranderen, dan verandert de key toch niet mee

[beerse]

Bedenk dat het beveiligen van de verbinding pas gebeurt als je toegang zoekt tot de remote host. Ze horen bij elkaar. Als je zoals de meesten gebruik maakt van public-private key inloggen zoals zo velen dan gebruik je geen andere credentials meer dan deze key-set.

[dasiro]

als ik er verbindingen mee leg, dan vraagt hij toch eerst achter de encryption key, waarna ik pas een login-prompt krijg. Geen juiste key = gewoon geen verbinding of inlogpoging.

[beerse]

Een beetje afhankelijk van de instellingen maar in de regel zet ik het zo dat ze helemaal niet meer om een wachtwoord vragen. Meestal zet ik de private-public key methode op. Dat dan weer wel met een passphrase en dus ook de ssh-agent zodat ik die ook niet te vaak hoef in te tikken.

[DJ]

Toevallig vanochtend mijn PuTTY versie bijgewerkt naar 0.81 :-)

[robin1301]

Ook diensten als FileZilla, WinSCP, TortoiseGit en TortoiseSVN zijn kwetsbaar. De recentste versies van die software hebben het probleem ook verholpen.

Op de download-pagina van WinSCP.net staat: SSH core upgraded to PuTTY 0.80 ...

[freeco]

Even geduld voor 6.3.3... Die staat al aangekondigd, maar is nog niet released: https://winscp.net/eng/docs/history#6.3.3