Hackers stelen keys door JavaScript-library van Solana-apps over te nemen

Hackers hebben de veelgebruikte JavaScript-library @solana/web3.js geïnfecteerd met malware en die via de npm-registry verspreid. Daarmee proberen de aanvallers gegevens van cryptovalutagebruikers te stelen.

De ontwikkelaars van Solana waarschuwen in een advisory voor de geïnfecteerde package. De kwetsbaarheid wordt getrackt als CVE-2024-54134. Volgens de ontwikkelaars is er eerder deze week een account overgenomen dat publiceertoegang had tot @solana/web3.js, een veelgebruikte JavaScript-library voor de Solana-blockchain. Die wordt veel gebruikt in Web3-apps waarin Solana is geïntegreerd. In de praktijk zijn dat veel cryptovaluta-apps. De makers benadrukken dat het niet gaat om een bug in Solana zelf, maar in gedecentraliseerde apps die daarop inhaken. Aanvallers konden met de geïnfecteerde library privésleutels stelen uit apps.

Na het overnemen van het account wisten de aanvallers die library via npm te verspreiden. Het is niet duidelijk hoe vaak de geïnfecteerde library is gedownload; volgens Solana-appontwikkelaar Helius Labs is er in die tijd zo'n 130.000 dollar van gebruikers gestolen, zegt ceo Mert Mumtaz. Volgens de ontwikkelaars waren versies 1.95.6 en 1.95.7 kwetsbaar. Die versies waren ongeveer vier uur te downloaden.

Inmiddels is versie 1.95.8 van de library uit. De hoofdontwikkelaars roepen andere ontwikkelaars op naar die versie te upgraden. Ontwikkelaars die vermoeden dat ze een kwetsbare versie hebben gedownload, zouden hun keys moeten roteren.

Reacties (96)

[bzuidgeest]

Dit toont maar weer waarom ik toch wel vraagtekens heb bij crypto. Het algoritme kan nog zo "Secure" zijn, met zoiets als dit jatten ze toch maar mooi je geld. En waar een traditionele bank dat terug kan draaien of herstelt uit de grote verzekering pot of zo is dat met crypto een stuk moeilijker zo niet onmogelijk. En zelfs als het kan, wie vergoed het je?

Er zullen vast wel allerlei tegenargumenten komen op deze observatie, maar wat gebeurt er als iemand de bitcoin chain kraakt? Het is altijd onmogelijk tot iemand het doet. Wat gebeurt er dan. Wellicht is de kans klein, maar de moeite van het overdenken waard. Er word niet voor niets tijd gestoken in quantum secure encryption e.d.

[GertMenkel]

Dit probleem speelt niet alleen bij crypto, banken hebben hier ook mee te maken. Als een crimineel tien ruggen overmaakt naar het buitenland zul je met de bank moeten vechten om je geld terug te krijgen, en die buitenlandse bank gaat dat geld echt niet zomaar teruggeven. Hetzelfde geldt ook als een bankapp gemaakt door een derde partij je bankrekening leeg haalt, dat geld zul je moeten verhalen bij de app die je gedownload hebt.

Bij cryptocurrency ben je je eigen bank, dus is het je eigen verantwoordelijkheid. Dat scheelt maandelijks voor je rekening moeten betalen en alle analyse die banken doen op je betaalverkeer ben je ook kwijt. Aan de andere kant zit je wel met de digitale equivalent van een matras vol geld, één inbraak en je ziet je vermogen nooit meer terug.

Zodra iemand een quantumcomputer heeft die deze cryptografie kan verslaan is Bitcoin wel de minste van onze zorgen. Zulke computers kosten miljoenen tot miljarden, overheden zullen zich moeten verantwoorden als ze hun computers daarvoor gebruiken. Ze zullen die technologie eerder gaan inzetten om opgeslagen internetverkeer te ontsleutelen, de Bitcoin komt later wel.

We kunnen er in elk geval van uitgaan dat de huidige Bitcoin in één klap waardeloos zal zijn. Men zal waarschijnlijk een versie van de keten pakken waarvan bekend is dat er geen inmenging is geweest en op basis daarvan een nieuwe keten gebouwd met een post-quantum hash opbouwen zodat de waarde niet echt volledig verdwijnt.

[bzuidgeest]

banken hebben hier ook mee te maken. Als een crimineel tien ruggen overmaakt naar het buitenland zul je met de bank moeten vechten om je geld terug te krijgen,

Nietemin doen veel banken dat bij oplichting wel. Kijk naar de storm die kwam toen bunq wat terughoudend was.... Die corrigeren nu vlugger. Of ze het geld werkelijk terughalen of dat het uit een soort verzekering pot komt of wat dan ook maakt niet uit. Zolang de gebruiker het terugkrijgt (en dat gebeurt vaak) dan is het goed voor mij.

Zulke computers kosten miljoenen tot miljarden,

Dat loopt hard terug en er zijn steeds meer quantum algo's die ze ook op klassieke computers gedaan krijgen. Bitcoin is wellicht niet het eerste doel, maar denk je dat het een land als Rusland of China wat uitmaakt? Die zouden bitcoin onderuit kunnen rukken als ze destabilisatie nodig achten. En die hebben hte geld wel. Ik verwacht niet dat het morgen gebeurd. Maar als het gebeurd, wat dan?

We kunnen er in elk geval van uitgaan dat de huidige Bitcoin in één klap waardeloos zal zijn. Men zal waarschijnlijk een versie van de keten pakken waarvan bekend is dat er geen inmenging is geweest en op basis daarvan een nieuwe keten gebouwd met een post-quantum hash opbouwen zodat de waarde niet echt volledig verdwijnt.

De schade komt ook van een wereld die schrikt, zelfs al fixen ze het. Ik denk dat veel mensen zich achter de oren krabben.

Het is natuurlijk allemaal voor nu hypothetisch, maar rijke investeerders die het erbij doen overleven wel, maar jan met de pet die zijn "pensioen" ziet verdwijnen of het studiegeld van zijn kinderen... dat is de echte pijn. Misschien maar en paar keer 10k per persoon, maar wel bij de zwakste groep natuurlijk.

[TechSupreme]

Nietemin doen veel banken dat bij oplichting wel. Kijk naar de storm die kwam toen bunq wat terughoudend was.... Die corrigeren nu vlugger. Of ze het geld werkelijk terughalen of dat het uit een soort verzekering pot komt of wat dan ook maakt niet uit. Zolang de gebruiker het terugkrijgt (en dat gebeurt vaak) dan is het goed voor mij.

Dat deden ze in eerste instantie niet, pas toen er een nieuwscampagne op gang kwam kozen ze ervoor om sommige mensen uit eigen zak te vergoeden. Dat moesten ze volgens de wet niet, want volgens de wet hadden ze niks verkeerd gedaan.

Een vergelijkbare situatie is ook voorgekomen met crypto exchanges.

[bzuidgeest]

Bunq deed het niet, maar heel van andere banken gaven aan dat wel te doen en dus moest bunq ook wel.

Je kan er over discuseieren en je hebt gelijk dat het strikt volgens de wet niet hoeft. Zeker niet in het geval van babbeltrucs. Maar tegelijk heeft een bank een zorgplicht. En daar (ongetest weliswaar) kan je daar veel onder kwijt. Een bank moet klanten continue informeren, waarschuwen, beschermen. Letten op fake apps kan daar onder vallen en nog veel meer.


Als het fout gaat bij en bank kan je iemand aanspreken, dat kan ook bij een exchange. Maar bij fouten in een app? fouten in een protocol of algoritme?
Je neemt een risico met crypto natuurlijk, maar ik denk dat veel te veel mensen dat niet beseffen. Banken en tegenwoordig exchanges moeten aan regels voldoen. De kwaliteit moet geborgd zijn, banken zijn verantwoordelijk voor hun apps en fouten daarin. Maar voor de rest... Dat wilde westen heeft voor en nadelen.

[TechSupreme]

Laat mij eens een wetsartikel of een algemene voorwaarden zien waarin dat staat.

Je zal wel ergens een artikel hebben gezien waar er rare claims in worden gemaakt, maar zolang het niet op papier staat heb je er niks aan.

Nou laat maar zien.

[wooha]

De praktijk bij oplichting via de bank wordt bijvoorbeeld uitgelegd in https://berntsenmulderadv...et-bank-schade-vergoeden/ . Dat is deels gebaseerd op rechtspraak en deels op toezeggingen van banken. Daar heb je iets aan, ook al heb je nog steeds een (beperktere) eigen verantwoordelijkheid.

Wat is de praktijk bij fouten of kwetsbaarheden in een crypto app, protocol of algoritme voor transacties die niet zijn afgehandeld via een crypto Exchange met software die goedgekeurd is door die Exchange? Wie heeft de plicht, de wil of het belang, en de reserves om de gevolgschade te vergoeden? In hoeverre neem je hier zelf bewust de verantwoordelijkheid voor risico's?

[TechSupreme]

Hoezo? Jij maakt een claim dat er banken zijn die zeggen...... Dan kan die bank dat beleid toch ook opnemen in zijn algemene voorwaarden? Zolang het niet in de wet of in de voorwaarden staat heb je er 0,0 aan.

Zodra er bewijs wordt gevraagd, kan dat niet?

[Reactie gewijzigd door TechSupreme op 6 december 2024 13:15]

[GertMenkel]

Bunq moest niet, Bunq koos ervoor om niet nog meer klanten kwijt te raken. Banken geven vergoedingen omdat het goed staat en omdat ze de slechtste nog niet zijn. Echter, zolang jij zelf je geld kwijt maakt door scammers (babbeltrucs, QR codes scannen en "ik wil inloggen" aanklikken, browserplugins installeren) of oneigenlijk gebruik van je telefoon (oude software, geroote telefoon, etcetera, zie voorwaarden van je bank) kun je naar je geld fluiten als de bank je niet aan staat.

Je kunt compensatie claimen als je kunt aantonen dat het niet jouw schuld was, maar zelfs bij afpersing krijg je lang niet altijd alles terug.

In de praktijk zullen de meeste banken in de meeste gevallen coulant zijn voor de meeste mensen, maar dat is geen recht waar je van uit mag gaan, en je kunt ook niet verwachten dat je al je geld terug krijgt zelfs als de bank coulant is. Wil je van een dief al je geld terug, dan moet je dat via de rechtbank spelen, want die is degene die daadwerkelijk schuld heeft.

[bzuidgeest]

Bunq moest niet, Bunq koos ervoor om niet nog meer klanten kwijt te raken

Dus ze moesten vanwege publieke opinie. Moeten is moeten ongeacht de reden.

In de praktijk zullen de meeste banken in de meeste gevallen coulant zijn voor de meeste mensen, maar dat is geen recht waar je van uit mag gaan,

correct, maar het meer dan ik in de crypto wereld verwacht aan te treffen. Banken trekken zich nog iets aan van publieke opinie. En ze willen al helemaal niet dat de burger stemt voor een partij die het een wet zou maken...

Mensen denken negatief over banken, maar uiteindelijk kan daar nog wat gedaan worden. Maar in crypto? daar zitten makkelijke winst figuren met nog minder moreel kompas dan een bankdirecteur en niemand kan ze echt wat maken. Je weet niet eens wie ze zijn. Ik vind dat nog wel een verschil. Sommigen vinden dat een goed ding, ik niet noodzakelijk.

[GertMenkel]

Ja, met crypto ben je helemaal klaar zodra je bestolen bent. Dat geld krijg je nooit meer terug, het is niet alsof je het ministerie van ethereum kunt bellen om je afschrijving te storneren. Sterker nog, zelfs als je het geld terug krijgt, gaan er duizenden euro's aan transactiekosten overheen om dat deze eeuw nog terug te krijgen op je account.

Toch vind ik dat te veel mensen denken dat ze hun geld toch wel terugkrijgen van de bank nadat ze wat doms doen. Iets is beter dan niets, maar voorkomen is beter dan genezen en op basis van de verhalen die je in programma's als Radar voorbij hoort komen lijken nog steeds veel mensen de illusie te hebben dat de bank je altijd schadevrij stelt, tot op het punt dat mensen boos worden op hun bank dat ze hun geld niet terugkrijgen nadat ze gescamd zijn.

[bzuidgeest]

De kans dat je wat terugkrijgt is hoger bij de bank dan bij crypto.

Tuurlijk er is zoiets als eigen verantwoording, maar ik betaal een bank om mij en mijn geld te beschermen en dat hoort een fout maken ofwel een domme actie ook bij.

Ik vind een slechte investering bijvoorbeeld heel anders dan bedrogen worden.

Met woeker hypotheken was wet technisch ook niets mis, maar de banken werden wel aangesproken.

Mensen die gescammed zijn moeten ook boos zijn op zichzelf. Maar als een bank nep apps laat staan in stores of herhaalde vreemde transacties naar een scam rekening niet herkend dan doet een bank wat niet goed. Hun taak is geld bewaken. Als ze dat niet kunnen met de huidige feature set, dan verkleinen ze die set maar. Hun keuze. Net als betalen zonder pin verificatie.

[Reactie gewijzigd door bzuidgeest op 7 december 2024 12:25]

[sympa]

Kleine bedragen zonder PIN verkleint juist het risico op grote fraude.
Uiteindelijk is een PIN een wachtwoord dat maar zelden wordt gewijzigd. En hoe vaker je die intoetst, hoe groter het risico dat die wordt afgekeken.
Daarmee vergeleken is die 50 euro klein bier. Plus dat het afrekenen van een paar tientjes met een gestolen pas een best groot risico is voor wat het oplevert.

[bzuidgeest]

Misschien, maar toch vind ik het niet prettig. Met een afgekeken pin kunnen ze nog niet zo veel zonder de pas zelf. Die is ook niet onmogelijk om te jatten, maar goed, het is wellicht meer een emotioneel iets dan een zinnig iets dat zonder pin niet goed voelt. Pin is er jaren ingeramd door diezelfde banken.

Net als eerst alle electrische tandenborstels een ronde kop hadden omdat het beter was en nu ineens philips weer voor een rechthoekige klassieke vorm gaat die ook weer beter is... Wat moet je nou verdorie geloven?

[ronaldvr]

Banken geven vergoedingen omdat het goed staat en omdat ze de slechtste nog niet zijn. Echter, zolang jij zelf je geld kwijt maakt door scammers (babbeltrucs, QR codes scannen en "ik wil inloggen" aanklikken, browserplugins installeren) of oneigenlijk gebruik van je telefoon (oude software, geroote telefoon, etcetera, zie voorwaarden van je bank) kun je naar je geld fluiten als de bank je niet aan staat.

Falikante nonsens: Banken hebben veel geld bespaard en besparen nog steed gigantisch veel door klanten *hun werk* te laten doen. Van origine ging je met je geld naar een bank *omdat je geld daar veilig was*.
Een dief kon niet zomaar bij het geld van de bank en dus ook niet bij jouw geld. Je kon naar een kantoor om geld op te nemen en daar zat een mens (die jou vaak van gezicht kende) die voorkwam dat er rare dingen gebeurden.
En als klap op de vuurpijl was bankieren gratis

Nu hebben banken die 'verantwoordelijkheid' weer terug gelegd bij de 'klant' (die dus eigenlijk nog 0 voordeel heeft van die 'dienst' en daarnaast vaak volkomen niet oordeelkundig genoeg is om zich te beveiligen op het niveau van een bank terwijl dat dus wel nu nodig is. Bankkantoren zijn massaal gesloten personeel ontslagen en dus een gigantische kostenbesparing
En als klap op de vuurpijl moet je er nog voor betalen ook.

Dus: Als een bank *niet* zijn echte verantwoordelijkheid zou nemen, zou het gerechtvaardigd zijn om banken daartoe te dwingen gezien de totaal niet bestaande 'dienstverlening'. En om dat nu te voorkomen doen ze alsof ze ruimhartig zijn, maar de 'schade' die ze oplopen daardoor is vele malen lager dan de kosten die ze hebben bespaard.

[Reactie gewijzigd door ronaldvr op 6 december 2024 17:39]

[Jerie]

Yep, bunq is kut, hoop bullshit en gebakken lucht en hete brei. Ik ben klant, gebruik het dagelijks, ik kan het weten

[Jim80]

Wat betreft Bitcoin, SHA-256 valt niet te kraken door quantum computers. Er is enkel een risico als je oude adressen hergebruikt, omdat dan je public key bekend is, en die wordt niet door SHA-256 berekend.

[Alex3]

Hetzelfde geldt ook als een bankapp gemaakt door een derde partij je bankrekening leeg haalt, dat geld zul je moeten verhalen bij de app die je gedownload hebt.

Dat is dan wel heel slecht geregeld. De beveiliging hoort in de server te zitten, niet in de app.

[bzuidgeest]

als de server geldige antwoorden krijgt ziet het verkeer van een malafide app er hetzelfde uit als een echte. Een server kan niet zien of een dief het invoert de eigenaar.

Beveiliging implementeer je op de server is de regel, maar dat doet niets tegen gestolen sleutels of gecompromitteerde (thirdparty) apps.

Voor bankzaken zou ik geen thirdparty app gebruiken, maar ik kan mij wel voorstellen dat de eigen app van de bank gecompromitteerd raakt of zoiets. Noem mij ouderwets, maar ik heb iets tegen bank apps op telefoons. De lading security issues is enorm. En missers in de playstore komen ook voor.

[GertMenkel]

Als ik de Alex3SuperDuperBankapp.apk van Github downloadt, bankrekeningnummer invul, een kopie van mijn bankpas scan, QR-codes scan, 2FA-sms-codes invul, en er na een week achter kom dat al mijn geld is overgemaakt, dan heb ik een probleem. Je bank kan het moeilijk maken maar nooit voorkomen dat iemand alternatieve clients schrijft.

Daarom moet je ook niet zomaar je gebruikersnaam, wachtwoord, en tweefactorgegevens met derden delen natuurlijk. Als je dat doet, ben je nu eenmaal de pineut.

Als iemand zonder die gegevens geld van je rekening weet te plukken wordt het verhaal natuurlijk anders.

[sympa]

Vooral omdat die SuperDuperBankapp helemaal geen bankapp hoeft te zijn. Maar alleen een proxy naar een backend waar de oplichter de echte bankapp draait, en de gegevens van de proxy invult.

[Jerie]

Vooropgesteld: supply chain aanval gaan we vaker zien, en is lastig te voorkomen.

Banken hebben er baat bij dat hun bedrijf een goede naam behoud. Degenen die een cryptocurrency hebben gebouwd hebben dat niet, enkel degenen die cryptocurrencies in bezit hebben. Maar degenen die het hebben gebouwd, die zijn binnen, want men heeft de snakeoil aangeschaft (ICO = binnen).

Verder is er geen enkele reden dat een bank Web 3.0 nodig heeft, of Web 2.0, met allerlei third party frameworks. Bloat is vragen om problemen. Je kunt het ook KISS houden.

Aan de andere kant zit je wel met de digitale equivalent van een matras vol geld, één inbraak en

..je bent een deel van je vermogen kwijt, want je ging natuurlijk niet op een enkel paard wedden.

[Timmmeeehhh]

Dat is waarom Bitcoin langzaam ontwikkeld en security op #1 zet. Bij Bitcoin is er al sinds 2013 geen echt significante bug of exploit meer geweest. De kans dat iemand de Bitcoin blockchain “kraakt” is dan ook vrijwel nihil.

Quantum secure is bij Bitcoin inderdaad nog wel een dingetje, want als je al ziet hoe lang het duurde om updates als taproot er door te krijgen zal het mij benieuwen hoe het zou gaan met een update naar quantum secure crytography, waar waarschijnlijk een hardfork voor nodig zal zijn terwijl verder practisch alle grote bitcoin updates met softforks gedaan worden. Ik zit dit nog wel een probleem worden met mogelijk een nieuwe fork (net als in 2017 de blocksize wars)

[bzuidgeest]

vrijwel nihil.... famous last words...:)

Maar je danst eigenlijk om de echte vraag heen. Wie fixed het als er wel een probleem is? En in dit geval was er geen probleem met de SOL crypto, er was een probleem met een library die toegang jat. Dus wie gaat die 130.000 dollar compenseren of corrigeren?

[Timmmeeehhh]

Er staat 3.000 miljard op het spel en er is sinds 2013 geen significante bug gevonden. Die in 2013 was ook binnen enkele uren opgelost.
Dus wie het fixt? De developers en dan wordt er een fix gepushed die waarschijnlijk de meeste node operators zo snel mogelijk zullen installeren als het daadwerkelijk echt een probleem oplevert.

[bzuidgeest]

Maar dat is geen antwoord op de vraag en betreft alleen bitcoin. En je negeert de sol situatie die we nu hebben, waar sleutels gejat zijn, geen probleem in het algoritme, maar niettemin zijn mensen geld kwijt.

Als een bank een app versie uitrolt met een gecompromitteerde library, dan fixen ze het niet alleen, ze maken ook de schade ongedaan. Wie doet dat bij crypto?

[Timmmeeehhh]

Solana heeft echt gigantisch veel problemen, het netwerk ligt er heel vaak uit en er worden vaak bugs gevonden. Dit weet iedereen, en als je veel geld er in steekt dan neem je in dit geval op solana dus ook gewoon een risico.
Waarom zou iemand deze schade moeten vergoeden? Als solana developers dat willen doen kunnen ze dat doen uit goodwill, maar ik zie niet in waarom dit per definitie zou moeten gebeuren.

Je gooit nu alles in crypto echt op 1 hoop. Solana is al jaren een shitzooi

[Reactie gewijzigd door Timmmeeehhh op 6 december 2024 12:29]

[bzuidgeest]

Het maakt niet uit wat jij (of ik) van solana vind. Mensen gooien er geld in al dan niet omdat ze gouden bergen word beloofd of wat voor reden dan ook. Ik vind het te makkelijk om het maar even af te doen als een risico.

Je vertrouwd op een app om werk te doen, als deze dat niet goed doet, zeker bij financiële transacties vind ik dat er iemand verantwoordelijk zou zijn. Bij een gecompromitteerde (officiële) bank app met een bug of hack die geld overmaakt naar waar het niet hoort is duidelijk dat de bank moet vergoeden. Daar kan de bank niet vanaf "met mijn product is shit". Ik zie geen reden om een crypto dat niet ook van te eisen.

Je gooit nu alles in crypto echt op 1 hoop. Solana is al jaren een shitzooi

Ik stel een algemene observatie over crypto. Nu is het sol, morgen kan het bitcoin zijn met een probleem. Resultaten uit het verleden zijn geen garantie voor de toekomst.

Ik hou je niet tegen om te doen met crypto wat je wil, maar het lijkt wel alsof crypto-fans boos worden van elk twijfelpuntje of vraag. Meestal vaak wanneer ze geen goed antwoord hebben of hun houding tegen andere mensen/slachtoffers als aso kan worden gelezen.

[Timmmeeehhh]

Dit is een probleem met de architectuur van solana. Dit is nu een beetje als zeuren over memory leaks omdat iemand c++ gebruikt, maar er bestaat ook rust. Er bestaan ook netwerken die meer security checks hebben waar dit soort dingen minder makkelijk kunnen gebeuren.

Solana is geen geld, het is een netwerk. In traditionele infrastructuur ben je soms ook gigantische flaters die heel veel geld kosten. Daar moet je het mee vergelijken. Overigens is het natuurlijk niet heel moeilijk om te bedenken dat bedrijven ook gewoon verzekeren tegen dingen of zelf geld apart zetten om dit soort dingen goed te zetten. Ligt er echt net aan wat voor service je wil leveren.

[.oisyn]

waar waarschijnlijk een hardfork voor nodig zal zijn

Dat hoeft niet, maar het probleem zit in een andere hoek. Bestaande wallets kun je met een update namelijk sowieso niet beschermen; iedereen moet zijn coins overmaken naar een post-quantum crypto adres om veilig te zijn. Het enige wat je kunt doen bij oude adressen is op een gegeven moment transacties niet meer toestaan. Als je dan nog eigenaar bent van die utxo's ben je je coins sowieso kwijt. Het voorkomt vooral dat ze niet in andere handen vallen.

[Timmmeeehhh]

Dat is op zichzelf natuurlijk alsnog een heel groot probleem. Alleen de satoshi wallet heeft al 1 miljoen bitcoin en die is dan sowieso up for grabs. Ik vraag me dan ook af hoe dit opgelost gaat worden.

[sympa]

Punt is denk ik dat je bij een bank ook best veilig bent wat betreft aanvallen op de backend zelf. En mocht de bank zelf overvallen worden en verdwijnen, dan is er altijd nog het depositogarantiestelsel. Maar uiteindelijk "staat het geld van de bank" niet ergens op een rekening - het is alleen maar een administratie. Leningen, spaarsaldo, als iemand die administratie verandert kan je een backup terugzetten.

[Timmmeeehhh]

Het depositogarantiestelsel is in mijn optiek juist een probleem. Het zorgt voor moral hazard bij banken waardoor ze te grote risico’s gaan nemen (er is immers toch een bailout beschikbaar)
Plus dat fonds is te klein om grootbanken op te vangen als die omvallen dus als er een keer echt een probleem is dan wordt er toch wel weer belasting geld voor gebruikt.
Het verplichte van het meedoen aan depositogarantiestelsel maakt het ook onmogelijk om een bank te maken die volledig gebacked is in plaats van fractioneel. Paul Buitink heeft dit ooit geprobeerd op te zetten en had alleen toestemming als hij ook mee zou doet met het depositogarantiestelsel, maar dan betaal je dus voor het risico wat andere banken nemen terwijl jij dit niet doet en maakt jet onmogelijk om dit rendabel aan te bieden.
Er zijn hier toen ook kamervragen over gesteld en mahir alkaya van de sp is hier ook al vaker kritisch op geweest, maar er is uiteindelijk nooit echt meer iets mee gedaan.

Los daarvan, een service die iets aanbied op een crypto netwerk kan natuurlijk alsnog gewoon een garant stelsel aanbieden als ze dat willen, of op het onderliggende netwerk de transacties permanent zijn heeft hier niks mee te maken. Je kan prima binnen je service transactiekosten rekenen en dat daarmee dekken. Of er voor verzekeren.

[TechSupreme]

En waar een traditionele bank dat terug kan draaien of herstelt uit de grote verzekering pot

Dit is niet waar. Bankverkeer is permanent, het kan in geen enkel geval teruggedraaid worden. Als je bent gehackt of opgelicht moet je wachten tot de politie de daders heeft opgepakt en ze door justitie zijn veroordeeld, dan pas kan je hopen dat er nog wat in beslag is genomen of je aanspraak kan maken op het slachtoffer fonds. Als jezelf per ongeluk een foute transactie invoert moet je de ontvanger vragen/hopen of ze het geld terug willen boeken en anders naar de rechter stappen voor een uitspraak.

Ditzelfde is ook van toepassing op crypto's, hopen dat justitie of de rechter het terug kan halen.

In sommige gevallen, zoals met automatisch incasso's, hebben banken onderling afspraken dat de ontvangende bank het terugboekt, maar dat is een afspraak tussen Nederlandse banken.

Waarom denk je dat ze in geval van een hack of oplichting ze niet gewoon het geld terugboeken?

Dat er een verzekering is, klopt ook niet, volgens de wet moet de bank zelf garant staan en tot een x bedrag staat de overheid garant in geval van faillissement. Sommige exchanges claimen dat ze een zelfde soort bankgarantie bieden. Er zijn zelfs exchanges die door een officiele instanties zijn erkend en gescreend waardoor ze dezelfde garantie bieden als een bank.

De officiele status van een bank is inderdaad wel een argument om het bij fiat valuta te houden, maar er moet wel bij gezed worden dat:
1. Bankgaranties alleen van toepassing zijn tot een x bedrag, alles daar boven is vogelvrij.
2. Als je fiat valuta met crypto gaat vergelijken dan heb je niet goed opgelet tijdens de les. Er is een argument voor beide.

Wat gebeurt er dan. Wellicht is de kans klein, maar de moeite van het overdenken waard.

De kans is klein? Het is gebeurd! De developers kunnen ervoor kiezen om de blockchain terug te draaien. Alleen dat zullen ze natuurlijk niet 1, 2, 3 doen. Het resultaat is een chain split. Waarom denk je dat er een Ethereum en een Ethereum Classic bestaat?

Zowel banktransacties als crypto transacties zijn non-reversible voor een hele goede reden.

[Reactie gewijzigd door TechSupreme op 6 december 2024 12:28]

[bzuidgeest]

Als je fiat valuta met crypto gaat vergelijken dan heb je niet goed opgelet tijdens de les. Er is een argument voor beide.

Er is een argument voor alles, ik vergelijk op dit moment specifieke eigenschappen van beide.

Ik weet even niet hoe banken het noemen, daarom suggereerde ik een paar opties, maar hoe het ook heet je kan overal gevallen vinden waar de bank "corrigeerde". Hoe dat gebeurd maakt niet uit. Zolang de gebruiker zijn geld maar krijgt. De banken hebben een zorgplicht. Laatste voorbeelden waren rond bunq en oplichting van zijn gebruikers.

De kans is klein? Het is gebeurd! De developers kunnen ervoor kiezen om de blockchain terug te draaien. Alleen dat zullen ze natuurlijk niet 1, 2, 3 doen. Het resultaat is een chain split. Waarom denk je dat er een Ethereum en een Ethereum Classic bestaat?

en wie vergoed dan de verliezen van zo een split? Welke winst van aankopen en verkopen en speculatie vaag je uit?
Als de bank app gecompromitteerd (bv bug bevat) is dan doet een bank dat. Maar wie doet het bij crypto?

[Reactie gewijzigd door bzuidgeest op 6 december 2024 12:44]

[TechSupreme]

Volgens mij snap jij niet zo goed wat er aan de hand is.

De blockchain is niet de bank, dat is de exchange. Dan moet je wel juiste vergelijkingen maken.

Wat jij zegt is dat er fundamentele fouten zijn in het betaalmiddel. Dat kan, dat is met fiat valuta ook gebeurt. Alleen het probleem met fiat valuta is dat het een recessie als gevolg heeft en dan ben je ook genaaid.

Dat een individuele bank wordt gehackt is jammer en is afhankelijk van die bank wat ermee gebeurt.

Er is een argument voor alles, ik vergelijk op dit moment specifieke eigenschappen van beide.

Je snapt het weer niet. Crypto en fiat zijn tegenpolen van elkaar, crypto is juist opgericht als een alternatief op fiat.

[bzuidgeest]

We stoppen er maar mee, want ik heb dezelfde mening over jou stelling. Komen we niet aan uit.

[TechSupreme]

Het is geen mening het is een feit. Jij stelt dat bankverkeer reversible is, dat is het niet en dat is het ook nooit geweest. Daarna haal jij allerlei randzaken aan waardoor jij denkt dat bank verkeer reversible is, maar dat is het nog steeds niet. Ik zeg tegen jou dat er exchanges zijn die hetzelfde bieden.

[bzuidgeest]

Jij stelt dat bankverkeer reversible is

Ik stelde dat het effectief reversible is in het feit dat de klant zijn probleem verdwijnt. Hoe ze dat op de achtergrond werkelijk doen, maakt niet uit voor de klant of het eindresultaat dat mensen hun geld weer hebben.

k zeg tegen jou dat er exchanges zijn die hetzelfde bieden.

top als dat zo is, maar er is meer aan crypto dan exchanges.

[.oisyn]

Waarom denk je dat er een Ethereum en een Ethereum Classic bestaat?

Door de The DAO hack van in totaal $50 miljoen in ETH op dat moment die redelijk snel ontdekt werd, maar dat was toen Ethereum nog net geen jaar bestond. Bij de vulnerabilities in de Parity wallet een jaar later in 2017 is uiteindelijk iets van $300M aan ether kwijtgeraakt: een (klein) deel gestolen, en een (groot) deel bevroren door een contractfout. Daar is uiteindelijk nooit iets mee gedaan, omdat een rollback van de chain inmiddels verregaande gevolgen heeft (zoals @bzuidgeest ook al aangeeft), ook al werd daar wel heel erg voor gepushed door de slachtoffers en Parity zelf.

Bitcoin heeft overigens ook een kleine rollback gehad, in 2010, toen er 184 miljard btc uit het niets werd bijgemaakt door een overflow bug.

Bij een rollback door een bug in het protocol of een ontdekte security vulnerability in een van de cryptografische algoritmes is natuurlijk wel wat waarschijnlijker dan een rollback door een third party fuckup (zoals het Parity debakel).

[Reactie gewijzigd door .oisyn op 6 december 2024 13:30]

[aikebah]

[...]
Dit is niet waar. Bankverkeer is permanent, het kan in geen enkel geval teruggedraaid worden..

Nee hoor, daar heeft de SEPA gewoon een standaard message formaat voor

https://www.ecb.europa.eu...URD_Annex_2.en.pdf#page49

dat er vrij harde restricties aan hangen en dat klanten eerst 1000x hoog en laag moeten springen voor de bank de moeite gaat nemen om het pad te bewandelen (en dan nog altijd afhankelijk is van de medewerking van de bank aan de andere kant) betekent niet dat het niet kan.

[TechSupreme]

FI-to-FI

[aikebah]

Yup.. bank naar bank.... en een van de redenen is 'FRAD' - frauduleuze transactie

[TechSupreme]

Nogmaals FI-to-FI... je zegt het zelf.

[aikebah]

Dat is het bericht dat de bank stuurt zodra jij ze mee hebt gekregen in 'terughalen wegens frauduleus'. Terugdraaien van een bankoverschrijving kan dus wel degelijk. Daar ging dit draadje over.

[TechSupreme]

Vriend luister, vertel even het hele verhaal. Dat is bank naar bank, niet klant naar klant.

[sympa]

Het kan dus teruggedraaid. Dat het niet snel gebeurt bij klanten is ook weer logisch, want dat opent andere mogelijkheden tot fraude.
Als ik een auto van jou koop en cash betaal kunnen we gelijk oversteken.
Als ik geld naar jou overmaak, de auto meeneem, en de volgende dag bij mijn bank aanklop met "het was fraude", dan zou ik zelf fraude plegen.
Ik die wereld zou je overboekingen niet accepteren als betaalmiddel.

[TechSupreme]

Zucht... Dat is voor transacties die banken onderlingen uitvoeren niet voor transacties die een klant uitvoert... Dat is voor acties die banken uitvoeren om onderlinge rekeningen te vereffenen en in geval een medewerker iets doet of de bank is gehacked. Daar maken banken onderling afspraken over, als een bank zomaar naar een onbekende bank dat stuurt wordt het sowieso afgewezen zonder dat er een contract is.

Je kan nou wel door gaan op de halve informatie van eerder, maar dat maakt jouw verhaal nog grotere onzin.

Het is niet reversible, klaar! Een bank zal jouw geld nooit terug halen!

[Reactie gewijzigd door TechSupreme op 8 december 2024 13:55]

[sympa]

Het is niet omkeerbaar voor een klant. Omdat je bedacht dat je dat huis nu wel hebt maar je het liever niet betaald zou hebben.
Dat is wat anders dan dat het niet zou kunnen, indien daar een heel goedenreden voor is.

[TechSupreme]

Kijk, als 2 banken, onderling afspraken maken over het hoe en waarom. Als de ene bank netjes vraagt aan de andere bank of hij dat geld terug wil boeken en er zijn afspraken over. Dat wil niet zeggen dat het reversible is, het wil alleen zeggen dat die twee hebben afgesproken dat ze het zo gaan doen.

Dat is toch echt heel wat anders als een geautomatiseerd proces waarmee het geld terugkomt, want dan kan je zeggen dat het reversible is.

Wat jij zegt is dat je het geld terug kan halen want als ik jij geld naar mij boekt en ik boek het weer terug, dan is het geld weer terug waar het was dus is het reversible.

Nee, de ontvanger boekt het vrijwillig terug omdat erom wordt gevraagd en omdat er afspraken zijn gemaakt!

[Reactie gewijzigd door TechSupreme op 9 december 2024 00:52]

[Quacko]

Er zijn wel effectief verzekeringen te nemen voor zulke dingen trouwens. Maar misschien zijn die er voor crypto ook wel, ben er niet van op de hoogte...

[David77]

"En waar een traditionele bank dat terug kan draaien of herstelt uit de grote verzekering pot of zo is dat met crypto een stuk moeilijker zo niet onmogelijk."

Ja, vergeet het maar! Een bank doet juist niks. Een bank schrijft zotte bedragen over naar louche rekeningen in het verre buitenland. Terwijl madammeke Greet of meneertje Lowie dat nog nooit gedaan had. Blacklisten van buitenlandse rekeningen? Controleren of de rekening hoort bij een betrouwbare firma? Automatische meldingen bij verdachte overschrijving waarbij wordt benadrukt dat ze het geld echt kwijt zijn eens overgeschreven? Een transactie terugdraaien? Vergeet het! vergeet het! vergeet het!

Onbegrijpelijk vind ik dat. Ze zouden zo gemakkelijk systemen kunnen opzetten die controles doen of bij bepaalde soort zaken alles terugdraaien zoveel dagen lang.

[bzuidgeest]

Tja, je word door de realiteit tegengesproken. Zie het gedoe met bunq die moeilijk deden bij oplichting waar andere banken gewoon vergoeden. En bunq heeft zijn beleid aangepast na de media storm.

Dus dat een bank niks doet slaat nergens op denk ik. Het is anekdotisch natuurlijk maar mijn zusje was geskimmed, de bank belde eerder met de melding dat het gecorrigeerd was dan ze door had dat er geld weg was....

Controle systemen zijn er gewoon en je kan bijvoorbeeld pas gebruik buiten de EU e.d. vaak uitzetten in je bank app. Het is niet perfect. Niet de controles en niet het gemak van correctie door de banken. Maar jou rant slaat wat mij betreft nergens op.

[Reactie gewijzigd door bzuidgeest op 6 december 2024 12:19]

[CamelKnight]

Ik vraag me af welke bank jou pijn heeft gedaan. Alle nieuwsartikelen en ervaringen die ik lees (in NL) geven aan dat banken juist enorm voortvarend zijn in het herstellen van schade en voorkomen van fraude. Je zou zelfs kunnen stellen dat ze daarin te ver gaan volgens sommige mensen.
Persoonlijk heb ik meer vertrouwen in mijn bank dan in de overheid.

[Quacko]

Bij grote transacties gebeurt bijvoorbeeld automatisch een check rond witwassen en ook andere zaken.
Toen een website gehackt was waar blijkbaar creditcard gegevens van mij stonden, kreeg ik een telefoontje dat mij creditcard in VS was gebruikt, wat wat vlaggen had doen opgaan. Ik was het dus niet, alles automatisch geblokkeerd en transacties ongeldig gemaakt zonder verlies voor mij. Het gebeurt wel degelijk hoor...
Maar misschien niet alles wat men kan doen, echter ga je dan ook false positives krijgen waarbij je gaat zeuren dat iets niet automatisch doorgaat terwijl je dat wel verwacht.

[Mr. Jinx]

Er zullen vast wel allerlei tegenargumenten komen op deze observatie, maar wat gebeurt er als iemand de bitcoin chain kraakt? Het is altijd onmogelijk tot iemand het doet. Wat gebeurt er dan.

Dat is in het verleden ook al eens gebeurd. Tenminste, niet echt 'gekraakt', maar wel zeer ernstige bugs. Bijvoorbeeld eentje waarbij iemand 184 miljard bitcoins kon minen in 1 block. Deze fout is toen vrij snel verholpen.
Dit soort fouten hebben de blockchain tot nu toe niet omver weten te gooien. Als zoiets nu zou gebeuren, dan zou het vertrouwen wel een flinke deuk oplopen en de koers waarschijnlijk (tijdelijk) instorten.
Maar uiteindelijk is en blijft het software en is er altijd wel een fix voor te vinden. In het ergste geval door een hardfork. Dat is lastig maar daar zal iedereen mee instemmen want wie wil er nou op chain zitten die vulnerable is.

Maar je hebt wel een punt wat betreft de risico's van eigen beheer. Als je iets fout doet of slachtoffer bent van een hack dan kun je nergens aankloppen.

[Memori]

maar wat gebeurt er als iemand de bitcoin chain kraakt?

Dan wordt er een fix geschreven door de Bitcoin Core developers en uitgerold in samenwerking met de node operators. Als de omvang zeer groot is dan zal er een roll-back plaatsvinden, en anders zullen de wallets worden geblacklisted. Tijdens dit soort noodgevallen zal de gehele Bitcoin community zich verenigen, zie bijv. de GHash.io 51% dreiging uit 2014.

[bzuidgeest]

Ik weet niet of ik die link een goed voorbeeld van je punt vind. Eerder het teegenovergestelde.

Tenzij je ddos aanvallen op een partij als een praktische oplossing ziet?

En laat zeggen dat jij net lekker dikke winst hebt op een verkoop na een stijging of daling in waarde.... Dan draaien ze even alles terug. En is je winst poef weg.....En dezelfde omstandigheden voor die winst (marktbeweging) treden niet noodzakelijk weer op.

Wie vergoed dat? de community?

Die community valt uit elkaar of word een vechtkamp als er echt wat mis gaat. Ieder voor zich. Zeker de grootinvesteerders van tegenwoordig zijn net als banken die ze claimen te haten. "Fuck the little people" is het met die gasten. Het "sociale" aspect was leuk in het begin, maar nu is het gewoon een banken systeem met nieuwe spelers, met dezelfde (on) menselijke negatieve trekjes.

[Memori]

Er staat inderdaad niet in wat ik gehoopt had, dus hier een tweede linkje. Het speelde in die tijd enorm: al maanden daarvoren waren er geluiden dat dit eraan zat te komen en hoe gevaarlijk het was dat één partij meer dan 50% hashrate had.

Het scenario dat ik omschrijf is iets dat binnen een paar block intervals moet plaatsvinden, zoals het ook in 2010 gebeurde tijdens een integer overflow bug. Binnen vijf uur was er een soft-fork van voor de bug, en alle transacties erna bestonden dus niet meer. Hedendaags zal het sneller gebeuren dan in 2010. Dit is ook een scenario waar alle reputabele Bitcoin Exchanges op zijn voorbereidt.

Dus of je winst weg is of niet is afhankelijk van hoe de exchange opereert. De kans is groot dat alles dat je op de exchange hebt gedaan off-chain is, dus zal het geen invloed hebben.

[bzuidgeest]

De toekomst zal het uitwijzen.

[Memori]

Hopelijk niet!

[sympa]

Punt is dat er meer is aan crypto dan de blockchain. Die stabiliteit die je omschrijft is er namelijk ook voor bijvoorbeeld goud.
Maar dat maakt goud als betaalmiddel niet automatisch veilig.

[yevgeny]

Het probleem is niet de crypto, het probleem is app developers die blind vertrouwen op externe libraries en daar hun app omheen bouwen.

[bzuidgeest]

Ooit van indirecte gevolgen gehoord?
Ook externe problemen zijn uiteindelijk een probleem voor crypto. Externe lib gebruiken is nu eenmaal een feit van dit leven. Als je een oude versie gebruikt mis je security fixes, als je altijd de nieuwste gebruikt krijg je dit. Ga je alles zelf maken ben je dubbel werk aan het doen en maak je eigen nieuwe fouten.

[Ramoncito]

En zelfs als het kan, wie vergoed het je?

Een goed punt. Maar ik zag dat mijn verzekering nu een of andere clausule heeft die dit (cybercrime, accountdiefstal etc) mogelijk opvangt. Daar zullen wel haken en ogen aan zitten denk ik, ik heb me daarin niet verdiept.

[bzuidgeest]

Wellicht een goed bij de tijd verzekering dan. Zou een goede ontwikkeling zijn.

[Toerq]

"zo is dat met crypto een stuk moeilijker zo niet onmogelijk"

Onmogelijk is het niet, mijn wallet ($NRG) is ooit eens leeggeroofd en heb alles terug gekregen na onderzoek van ebi. https://energi.world/energi-defense/

[bzuidgeest]

Maar dat betekent dat je bij die chain en paar van de zogenaamde voordelen van een blockchain mist. Er is namelijk een autoriteit die schade ongedaan kan maken. Dus controle heeft over de transacties

Klinkt mij als een goed plan, maar niet echt gebruikelijk en tegen de principes van veel crypto gebruikers.

[Slonzo]

Another day, another supply chain attack... Wat ik wel gek vind, is dat er in de 4 uur dat de packages beschikbaar waren, een aantal upstream applicaties die packages al geimplementeerd hebben + doorgepushed naar productie + gebruikers die ze al gebruikt en/of geinstalleerd hebben + dat dat genoeg was om $USD 130k aan crypto te stelen?

[Reactie gewijzigd door Slonzo op 6 december 2024 10:57]

[thomasv]

Automatische builds die packages bij versie bumps upgraden en CI/CD toepassen. Wat dus een groot risico blijkt te zijn zonder toezicht op de bron.

[Slonzo]

Klinkt als volautomagische CI/CD zonder enige controle inderdaad, welke gek bedenkt zoiets?
Dit is dus waarom je version pinning doet en niet zomaar alles hersenloos laat upgraden.

[wanjakrah]

Een minor version upgrade is meestal een kleine patch of een security update. Vooral vanwege dat laatste wil je die meestal wel snel toepassen. Zeker als je met financiële gegevens werkt. Tevens kun je ook niet voor elke dependency de source-code gaan controleren om te kijken of er niets raars in zit. Dat is simpelweg niet te doen.
Dus als er een minor version upgrade komt en je testen blijven groen, snap ik wel dat dat gelijk door naar productie wordt gedrukt.
Misschien zou je er een vertraging van een dag op moeten zetten, maar als iedereen dat doet is het maar de vraag of er dan wel op tijd iets wordt opgemerkt.

[Triblade_8472]

of een security update. Vooral vanwege dat laatste wil je die meestal wel snel toepassen.

Nou, nee.

Meestal is je omgeving dusdanig beveiligd dat het geen giga schade aan kan richten. En de ervaring leert dat je altijd een week ofzo moet wachten, ongeacht het type update.

Alleen criticals met een hele hoge score moet je even goed nalezen of dit voor jouw omgeving belangrijk is. En zo wel, dan moet je een weloverwogen keuze maken wat je belangrijker vindt. De update, of potentiële fouten hierin.

[bzuidgeest]

Het idee achter CI/CD is natuurlijk wel de C van continuous.....

Als developer klakkeloos de laatste versie van alles gebruiken is waar je eventueel vragen bij kan zetten...
Maar als je kijkt hoeveel builds er links en rechts continue security issues fixen... en je wil secure zijn... Elk voordeel heeft een nadeel.

Dan denk ik ook wel dat er veel figuren zijn op bijvoorbeeld github die hun stinkende best doen om hun harde werk met iedereen te delen. Dat ze dan het gemak van CI/CD gebruiken vind ik niet meer dan normaal. Het is wel hun "vrije" tijd die ze vaak besteden om anderen hun leven makkelijker te maken.
Of dat hier van toepassing is maakt mij niet veel uit. Het is in het algemeen waar. Dus gewoon niet te vlug "gek" of zo gaan roepen.

[Jens VD]

De laatste patch per direct doorvoeren is nu ook niet bepaald 'secure'. Je gaat dan software gebruiken die eigenlijk nog onvoldoende is doorgetest. Mogelijk worden er nieuwe bugs ontdekt vlak na de release van de patch.
Het patchen van de dependencies zou niet moeten gebeuren bij het uitrollen van je eigen nieuwe features, dat zou een patch op zichzelf moeten zijn die ook niets meer doet dan dat. Dat kan in een apart proces gebeuren waar het toegelaten is, terwijl het in de andere jobs niet zou worden toegelaten. Grote bedrijven gebruiken hiervoor platformen zoals Sona, Aquasec,...

[bzuidgeest]

Er is en balans te vinden tussen de uitersten en iedereen maakt zelf die evaluatie waar die ligt. Het gaat nooit perfect zijn. Als je een patch ophoud met je eigen evaluatie dan krijg je shit van gebruikers. Voer je hem meteen door en is er een manco krijg je shit van gebruikers.

Samengevat men moet niet zo vlug mensen stom noemen als ze de balans anders kiezen dan je wil. En al helemaal niet mocht het "vrijwilligers" betreffen waar je spul van gebruikt.

[NutKees]

Klinkt als volautomagische CI/CD zonder enige controle inderdaad, welke gek bedenkt zoiets?

Hier spreekt zo'n gekkie.

Ik heb CI/CD pipelines opgeleverd die volledig automatisch uitrollen naar productie n.a.v. een PR of update van een dependency. Voorwaarde van een dergelijke pipeline is dat alle processen die nodig zijn voor het garanderen van een succesvolle uitrol naar productie volledig geautomatiseerd zijn.
Deze pipelines zijn van een niveau dat er geen enkele handmatige controle/actie nog iets gaat toevoegen.

In dit specifiek geval zouden verschillende vulnerability scans deze hack niet opgepikt hebben. Wat zou jij dan persoonlijk nog hebben kunnen doen om deze hack te kunnen detecteren? De hele broncode doorspitten?

Persoonlijk denk ik dat het veiliger is om snel te security fixes toe te passen, ipv versies vast te gaan pinnen. Vaak worden belangrijke updates dan gemist, omdat het weer handwerk wordt.

[YopY]

Dit is een van de grote problemen imo bij het NodeJS ecosysteem, en het heeft meerdere dimensies.

1. Security releases; als er een security vulnerability in een package zit dan moet die zo snel mogelijk opgelost worden, zoals ook deze. Omdat er zoveel Node packages zijn, is het onredelijk om alle security advisories en patches continu in de gaten te houden, dus worden ze geautomatiseerd door bijvoorbeeld Github's Dependabot en andere tools. Ook toen Node eerst uit kwam waren dependencies by default ook al met een "losjes" versienummer opgeslagen, zodat als je "npm install" doet, je altijd de nieuwste patch versie krijgt.

2. Migraties. Omdat veel van deze packages via github en co gebouwd worden, en ze veel contributies krijgen, èn ze automatisch gedeployed worden omdat het anders ook teveel werk is, komen er veel nieuwe versies van zo'n library uit. Een deel van die wijzigingen heeft werk nodig aan de kant van de developer. Sommige van die wijzigingen zijn ingrijpend, maar vaak is er wel een migratiepad, mits je mee blijft gaan met de regelmatige releases. Als je van een v1 naar v2 van een library wilt upgraden, maar je bent niet meegegaan met v1.1, 1.2, 1.3 etc, dan zal die upgrade een enorme klus zijn. Maar je kunt ook niet bij v1 blijven ivm security issues.

Lang verhaal kort, mensen hebben op de moeilijke manier geleerd dat je zoveel en zo snel mogelijk bij moet blijven met releases, maar doordat het zo snel en zo veel gebeurt is er geen ruimte meer om van alles met de hand na te kijken.

Dat gezegd hebbende, ik vind ook dat NPM hier een rol in zou moeten spelen. Het publiceren van een nieuwe versie kan nu met 1 account vanaf de commandline, elke commandline. Ze zouden twee dingen moeten doen:

1. Review / publicatie stap; dat zou verplicht door een andere persoon gedaan moeten worden dan degene die de release maakt, en die andere persoon moet two-factor authenticatie en dergelijke hebben.

2. "Veilige" of "geverifieerde" versies van libraries, een set libraries of versies daarvan (denk LTS releases) die gevalideerd worden door mensen van NPM zelf of onafhankelijke en geverifieerde onderzoekers. Daar kan een verdienmodel achter zitten, want het zullen vooral bedrijven zijn die hier interesse in hebben.

[Reactie gewijzigd door YopY op 6 december 2024 13:45]

[Loller1]

Want? Wat is het alternatief hier? Een mens ziet met zijn "npm outdated" command dat er een update is, gaat kijken naar de changelog, ziet dat het een kleine bugfix is (want laten we veronderstellen dat de hackers niet in de changelog hebben gezet dat ze je keys stelen) en voert die patch door aan zijn eigen implementatie want niemand gaat in de code duiken van dit soort updates om te kijken of er niks bizar in gedaan wordt.

Het enige verschil hier is dat een mens op knoppen had moeten drukken, maar het eindresultaat is nog altijd hetzelfde. Het "probleem" in deze flow is dat de code van de dependency niet is gecontrolleerd, maar dat gebeurd in een flow met mensen ook niet.

[thomasv]

Genoeg, kijk maar op Github

[GertMenkel]

Als je vertrouwen hebt in je dependencies is dat niet zo'n probleem, normaal. Het is niet alsof de meeste projecten de duizenden node packages in hun dependency chain gaat code reviewen elke keer als ze updaten, ze hebben wel wat beters te doen met hun vrije tijd.

Normaal is de impact iets van "er zijn cookies gestolen en we moeten onze database herstellen uit een back-up" dus valt het wel mee met de risico's.

Dat iemand volledig automatisch CI/CD met dependencies doet bij een financieel stuk software is wel verbijsterend. Aan de andere kant weer ik ook niet of ik veel beter zou verwachten bij cryptocurrencymensen.

Overigens is het maar de vraag of dit CI/CD was. Als ik een hacker was zou ik proberen te achterhalen wanneer grote projecten hun software builds uitvoeren en zo'n takeover vlak op het allerlaatste moment doen in de hoop dat niemand version pinning gebruikt. Veel projecten op Github doen moet aan pinning of specificeren alleen de major en minor, dus een update van 1.95.5 naar 1.95.6 komt vaak automatisch mee. Sterker nog, Github heeft een bot die automatisch pull requests voor je opent met de nieuwe versie zodra er dependency updates zijn zelfs als je je versies pint.

Ook is het natuurlijk mogelijk dat dit gewoon fraude is, geld stelen onder het mom van "een project van derden was gehackt".

[Robin94]

Het niet updaten is minstens een zo groot risico.

[thomasv]

Klopt, maar daarom had ik het ook over blind updaten zonder toezicht. Niet over totaal niet updaten.

[jaenster]

Tja wat moet je doen? Naar de getranspilde typescript brei kijken en zien wat er daadwerkelijk veranderd is ten opzichte van de vorige versie?

Ben het er niet mee oneens, maar wat moet je dan doen met de deps van de deps? Op mijn werk zijn we redelijk voorzichtig met npm packages gebruiken, toch kom je uit op een kleine 1000 packages als je alle dep's van de dep's mee neemt. Hoe ga je dit doen.

Ik ben er prima voorstander van om alles zelf te maken en te doen, maar helaas wil mijn werkgever dan niet meer betalen voor alle uren die ik moet maken

Het is absoluut een probleem, maar de oplossing zie ik niet snel voor ogen

[thomasv]

Nee ik ook niet, ik heb zelf over de jaren een behoorlijke afkeer gekregen van de hoeveelheid dependencies die een willekeurig nodejs/ts project op den duur krijgt maar helaas zonder afdoende oplossing.

Vooral wat je zelf al beschrijft, afwegen en voorzichtig zijn in plaats van willekeurig packages gebruiken.

[jaenster]

Ik weet dat het een soort meme is van hoe veel packages er zijn in typescript development, maar dit is natuurlijk waar in bijna elke taal. Kijk naar een c++ waar je een header file krijgt en een compiled blob als lib. Dat is al helemaal niet meer na te gaan. Niet dat dat een excuus is voor npm om het ook maar slecht te doen, het is meer dat het overal een probleem is.

De packages in node zijn vooral een stuk kleiner over het algemeen, wat als nadeel heeft dat je veel meer packages krijgt, maar tegelijkertijd valt een kleine subtiele supply chain attack change wel sneller op, omdat een kleine package veel duidelijker is wat die doet (en niet moet doen). Tegelijkertijd heb je door veel meer kleine packages wel veel meer targets.

[YopY]

"bijna" idd; de Go taal, SDK en vooral de community is een goed tegenargument, waar de SDK je al het merendeel van de tools geeft, en er een afkeer is voor veel of grote dependencies, libraries, of abstractielagen. Maar ook, de dependencies worden als (leesbare) source binnengehaald, dus als een bedrijf of organisatie strengere beveiligingseisen heeft kunnen ze ervoor kiezen om dependencies te vendoren (dat de dependency code in je eigen code repository komt) en alles eerst te auditen voordat ze een update doorsturen naar productie.

[YopY]

Naar de getranspilde typescript brei kijken en zien wat er daadwerkelijk veranderd is ten opzichte van de vorige versie?

Hier is zeker verbetering in mogelijk, bijvoorbeeld dat je verplicht de source moet uploaden en door NPM en co laat transpilen indien nodig, of nog beter, dat alles als source gedistribueerd wordt - dit is hoe Go het doet, zo kan namelijk de compiler ook de code uit de libraries optimaliseren en / of verwijderen indien niet gebruikt. In het JS landschap zou dan de compressie ook beter uit de verf komen.

Maar je hebt wel gelijk, er is geen snelle oplossing. Dit zijn grote problemen die diepgaande wijzigingen in het nodejs (en "by extension" het open source development) ecosysteem nodig hebben.

[vargo]

Dat is een lastige en zal ook afhankelijk zijn van de use case die je implementeert. Toch zijn er wel practices die je kan hanteren.

Om te beginnen OWASP guidelines volgen: https://cheatsheetseries....Security_Cheat_Sheet.html

Even uit mijn hoofd, andere maatregelen die ik (/'we') in organisaties hanteerden:
- soms, bij kritische applicaties, inderdaad per package beslissen of het risico geaccepteerd kan worden (waarom hebben dit nodig en welk risico, wie ontwikkelt dit, wordt het nog actief onderhouden etc)
- bewustwording bij devs over security risks bij gebruik externe libraries
- afspraken met dev teams over hoe snel problemen moeten worden opgelost (afhankelijk van severity level)
- actief tracken & tracen welke packages een security probleem hebben (en dus gefixt moeten worden)
- ...mn ook van wat er in productie, en indien nodig 'expedited security patch' releasen.
- package dependencies declareren (niet latest)
- automatisch dependencies bijwerken mbv renovate bot
- risico analyse en bijbehorende actie (patchen, mitigerende maatregelen, uitzondering/uitstel met einddatum)
- lokale NPM repo proxy (ook in OWASP) en daarop security scans
- attack surface verkleinen door de release op te schonen (geen onnodige libraries/tools)
- juiste `.npmrc` per project

Vergelijkbare maatregelen overigens ook voor andere technologie (docker).

[Justevo]

Banken werden vroeger toen ze er net waren ook een stuk vaker beroofd dan nu.

[ernstoud]

“Volgens de ontwikkelaars is er eerder deze week een account overgenomen dat publiceertoegang had …”

Juist ja. Ik hoop dat goed nagedacht wordt hoe dat te verbeteren. Twee of meer factor authenticatie, vier ogen principe, betere checks op het proces, meer codecreview voor release etc.

[thalx]

Redelijk oud nieuws ondertussen, al dagen bekend.

Maargoed, ook fijn om te vermelden dat de veelgebruikte Phantom wallet hier geen last van had.

[Hatseflats]

Wat wel goed naar voren komt is dat het er alle schijn van heeft dat de gebruikte cryptografie niet te kraken is.