`@bsv/wallet-toolbox` / `-client` / `-mobile` don't verify storage-supplied recipient output scripts against caller-requested outputs in createAction
Exploiteerbaarheid: geen exploit bekend. Blootstelling: niet internet-facing / geen bekende blootstelling. Gemeentelijke relevantie: geen match met de gemeentelijke context. Impact: burgerdienstverlening kan geraakt worden. Bronvertrouwen: middel.
Scorecomponenten
geen exploit bekend
niet internet-facing / geen bekende blootstelling
geen match met de gemeentelijke context
burgerdienstverlening kan geraakt worden
beperkt bevestigd
geen mitigatie bekend
Geen automatische bestuurlijke escalatie — operationeel op te volgen.
Prioriteit: monitoren
Aanbevolen reactietijd: monitoren
Monitoren (48/100) — monitoren. Bepalend: technische ernst (65/100) en gemeentelijke relevantie (47/100). Houd dit in de gaten; directe actie is nu niet nodig. Deze prioritering is regelgebaseerd en navolgbaar; weeg de aannames en onzekerheden mee voor de eigen gemeentelijke omgeving.
verhoogd — De technische ernst is gemiddeld: impact is mogelijk, maar niet vanzelfsprekend ernstig.
midden — Misbruik is denkbaar maar nog niet onafhankelijk bevestigd.
midden — Dit kan gemeenten raken, afhankelijk van de eigen omgeving en leveranciers.
midden — Plan beoordeling en opvolging in; directe actie is nu niet vereist.
Positieve factoren
De dreiging raakt een leverancier of de toeleveringsketen; gemeenten zijn sterk afhankelijk van externe leveranciers.
Bron: Technologieherkenning in titel, samenvatting en labels
Negatieve factoren
Een exploit wordt geclaimd (community/onbevestigd) maar is niet onafhankelijk geverifieerd.
Bron: Tekstanalyse van titel en samenvatting
De zekerheid is 'likely'; een onbevestigd signaal verlaagt de urgentie tot het is geverifieerd.
Bron: Zekerheidsinschatting van de radar
Aannames
Onzekerheden
Deze prioritering is regelgebaseerd en navolgbaar. Een CISO kan deze onderbouwing gebruiken richting directie of ICT-management; stem de opvolging af op de eigen gemeentelijke omgeving.
9 concrete acties verdeeld over 6 rol(len). Aanbevolen reactietijd: monitoren.
Taken voor CISO
Laat vaststellen of de getroffen component of het proces binnen de gemeente in gebruik is.
Bewijs vereist: Bevestiging in/uit gebruik door ICT-beheer.
Wijs per actie een eigenaar en deadline toe en bewaak dat de acties worden afgerond.
Beoordeel hoe kritiek de getroffen leverancier is voor de gemeentelijke processen.
CISO
Laat vaststellen of de getroffen component of het proces binnen de gemeente in gebruik is.
Bewijs vereist: Bevestiging in/uit gebruik door ICT-beheer.
Wijs per actie een eigenaar en deadline toe en bewaak dat de acties worden afgerond.
Beoordeel hoe kritiek de getroffen leverancier is voor de gemeentelijke processen.
ISO / patchmanagement
Controleer of een patch of mitigatie beschikbaar is en bepaal de deadline voor opvolging.
Bewijs vereist: Patch- of mitigatieoverzicht met versienummers.
ICT-beheer
Breng in kaart welke systemen, applicaties of accounts de kwetsbare component bevatten.
Bewijs vereist: Lijst van geraakte systemen uit de CMDB of inventaris.
Functioneel beheer
Controleer of de geraakte applicatie of koppeling extra aandacht nodig heeft.
Leveranciersmanager
Vraag de leverancier of de kwetsbare component wordt gebruikt en of misbruik is geconstateerd.
Bewijs vereist: Schriftelijke reactie van de leverancier.
Vraag de leverancier om een concrete planning voor patch en mitigatie.
Bewijs vereist: Planning van de leverancier.
Proceseigenaar
Beoordeel wat de dreiging betekent voor de continuiteit van het geraakte proces.
De acties zijn regelgebaseerd gegenereerd. Stem ze af op de eigen gemeentelijke omgeving en wijs per actie een eigenaar en deadline toe.
Relevante logbronnen
MITRE ATT&CK — tactieken
Huntingvragen
KQL-huntingqueries (Microsoft Sentinel)
Defender-waarschuwingen rond endpointcompromittatie
Toont waarschuwingen van Microsoft Defender for Endpoint met een hoge of gemiddelde ernst.
// Defender-waarschuwingen rond endpointcompromittatie
SecurityAlert
| where TimeGenerated > ago(7d)
| where ProductName == "Microsoft Defender for Endpoint"
| where AlertSeverity in ("High", "Medium")
| project TimeGenerated, AlertName, AlertSeverity, CompromisedEntity,
Description
| order by TimeGenerated descFalse positives: Beheertooling en pentests kunnen legitieme waarschuwingen genereren.
Indicators of compromise
Geen IOC's herkend in de openbare dreigingstekst. IOC's kunnen later via een threat-intelfeed worden aangevuld.
False-positive-aandachtspunten
Beoordeel afwijkingen in context; reguliere beheeractiviteit kan op een incident lijken.
Deze informatie is uitsluitend defensief: detectie en hunting. De KQL-queries zijn read-only en bedoeld voor Microsoft Sentinel.
Vragenlijst
E-mailonderwerp
Uitvraag leveranciersincident — reactie gevraagd
E-mailtekst
Geachte heer/mevrouw, Onze gemeente heeft kennisgenomen van een mogelijk incident bij npm. Wij doen deze uitvraag ter verificatie en feitenvaststelling, om te kunnen beoordelen of de aan onze gemeente geleverde dienstverlening wordt geraakt. Het betreft mogelijk het product of onderdeel "@bsv/wallet-toolbox". Wij verzoeken u de onderstaande vragen volledig en onderbouwd te beantwoorden en uw reactie binnen tien (10) werkdagen na ontvangst van dit bericht schriftelijk aan te leveren bij de informatiebeveiligingsfunctie van onze gemeente. Zijn bepaalde gegevens nog niet beschikbaar, dan ontvangen wij graag een tussentijdse terugkoppeling. Vragen: 1. Bent u geraakt door dit incident? 2. Welke dienstverlening aan gemeenten is mogelijk geraakt? 3. Zijn gegevens van onze gemeente bij het incident betrokken? 4. Zijn er persoonsgegevens betrokken? 5. Welke continuïteitsmaatregelen heeft u genomen? 6. Is een melding bij toezichthouders nodig of inmiddels gedaan? 7. Welke hersteltermijn verwacht u? 8. Welke bewijsstukken kunt u met ons delen? Deze uitvraag is bedoeld om de feiten vast te stellen en gezamenlijk tot een passende opvolging te komen. Wij stellen uw tijdige medewerking op prijs. Met vriendelijke groet, [Naam] Namens de informatiebeveiligingsfunctie Gemeente [Gemeente]
Vul vóór verzending de afzender en gemeentenaam in. De tekst is zakelijk en gericht op feitenvaststelling; pas hem aan op de eigen situatie.
Deze dreiging raakt de onderstaande governance-thema's. Met de aanbevolen bewijsstukken kunt u aantonen dat het signaal is opgevolgd — bruikbaar voor BIO2, NIS2/CBW, ISMS en de ENSIA-verantwoording.
Het incident raakt een leverancier; leveranciersmanagement borgt de afspraken en opvolging.
Aanbevolen bewijs: Leveranciersuitvraag en de schriftelijke reactie van de leverancier.
Uitval bij een leverancier kan de gemeentelijke continuïteit raken.
Aanbevolen bewijs: Continuïteitsafspraken met de leverancier.
NIS2 verlangt aandacht voor de beveiliging van de toeleveringsketen.
Aanbevolen bewijs: Risicobeoordeling van de leverancier en de gemaakte afspraken.
De dreiging en de opvolging ervan horen thuis in de periodieke rapportage aan het management en de directie.
Aanbevolen bewijs: Vermelding in de CISO- of directierapportage informatiebeveiliging.
De radar legt de beoordeling, prioritering en opvolging navolgbaar vast.
Aanbevolen bewijs: Scoringonderbouwing, actiekaart en statusgeschiedenis uit de radar.
De uitkomst van de uitvraag kan leiden tot bijsturing van afspraken of maatregelen (Act).
Aanbevolen bewijs: Besluit over vervolgmaatregelen of contractafspraken.
Aantoonbare opvolging draagt bij aan de jaarlijkse ENSIA-verantwoording over de BIO.
Aanbevolen bewijs: Overzicht van opgevolgde dreigingen voor de ENSIA-zelfevaluatie.
Reported by @echennells (Eric Chennells). Migrated from public issue #191 to a private advisory. **Affected:** `@bsv/wallet-toolbox` / `-client` / `-mobile`. Verified in `2.1.21` and `2.1.21-parity-fix.2`; the relevant code is the same at current HEAD **Summary:** When `createAction` runs against a remote `StorageClient`, the storage server returns the outputs to build. `buildSignableTransaction` takes each non-change output's `lockingScript` from the storage response and signs it, without comparing it to the `lockingScript` the caller supplied in `args.outputs`. `WalletPermissionsManager.createAction` parses the built transaction and has `args.outputs` available, but uses the tx only for `inputs` and `getFee()`; it does not inspect `tx.outputs`. A storage provider that returns a different recipient script than requested will therefore have that script signed and broadcast, while the calling app and UI still show the originally requested recipient. **Relevant code:** - `signer/methods/buildSignableTransaction.js` — non-change output `lockingScript = asBsvSdkScript(out.lockingScript)`, sourced from the storage response; `args.outputs` is not consulted. - `WalletPermissionsManager.js` `createAction` — parses the built tx, derives spend from `args.outputs` satoshis + `tx.getFee()`, reads `tx.inputs`; does not read `tx.outputs`. - `signer/methods/signAction.js`, `completeSignedTransaction.js` — sign the as-built tx; no output comparison. **Context:** Remote storage is a supported, default configuration (`StorageClient` over BRC-103 `AuthFetch`, default endpoint `storage.babbage.systems`, optional payment middleware). The mutual auth establishes the storage server's identity and protects the channel, but the contents it returns are not validated against the request. The attacker is the storage operator, or anyone who compromises it — not a passive network MITM. (`StorageServer.processAction` does compare the signed rawTx outputs to what storage stored, so a response-only MITM is rejected; an operator stores the substituted script from the start.) **Proof of concept:** We ran a storage server that returns a substituted recipient output, and pointed a current yours-wallet build at it as its active storage provider. With the wallet otherwise unmodified, a payment requested to one address was built, signed, and broadcast paying a different address, the substitution was not surfaced anywhere in the wallet.
Categorie 'supplier_incident' overgenomen van de bron; geen specifieker incidenttype gedetecteerd. Severity 'high' bepaald op basis van: bronlabel 'high'. Confidence 'likely': gerenommeerd securityonderzoek (GitHub Security Advisories). Geen bekende leveranciers of producten herkend.
Deze dreiging scoort 35/100 voor de gemeentelijke relevantie. Meegewogen: impact op identity of Microsoft 365 en een leveranciers- of ketenrisico. Geraakte processen: Microsoft 365 en identity, Netwerk en infrastructuur, Leveranciersketen.
Bestuurlijke duiding
Deze dreiging is relevant voor de gemeente. Omdat het een leverancier betreft, is de gemeente afhankelijk van diens herstel en is regie op de keten nodig. De impact is beheersbaar mits de geadviseerde maatregelen tijdig worden opgevolgd. Laat de CISO de voortgang bewaken en escaleer richting directie zodra nieuwe signalen daartoe aanleiding geven.
Geraakte processen
Geraakte technologie
Betrokken rollen
CISO · ISO · SOC · ICT beheer · Leveranciersmanager
Concrete stappen voor ICT-beheer en het securityteam.
Dit zijn algemene handelingsperspectieven. Stem de opvolging af op de eigen omgeving en het ISMS van uw gemeente.
Deel geen vertrouwelijke of persoonsgegevens in dit formulier. Beschrijf je melding algemeen; gevoelige details horen niet op een publieke radar thuis.