Axios of Evil ☢️

Forrige uke var Feross Aboukhadijeh, CEOen i Socket, gjest på TBPN-podcasten for å fortelle historien om hvordan nordkoreanske statsaktører klarte å kompromittere Axios, som er ett av npm-økosystemets mest brukte biblioteker.

Angrepet var et mesterstykke i sosial manipulasjon, bygget opp over flere uker. Først satte angriperne opp et fabrikert selskap og et falskt Slack-workspace, inviterte en av hovedvedlikeholderne av Axios inn, og brukte lang tid på å etablere et tilsynelatende normalt, tillitsfullt samarbeid. De bygget en falsk, svært sofistikert Microsoft Teams-klient ved hjelp av mange av Microsofts egne offisielle SDKer, slik at appen fremsto helt troverdig. Vedlikeholderen ble så invitert inn i en Teams-samtale, som etter en kort stund ble avbrutt med en beskjed om at han måtte oppdatere klienten sin med en binærfil som han ble bedt om å installere. Idet han kjørte binærfilen, ble maskinen hans kompromittert. Angriperne klarte å hente ut npm-innloggingsinformasjonen hans og brukte den til å publisere en forgiftet versjon av Axios.

I podcasten poengterer Feross at hele programvare-forsyningskjeden er bygget på blind tillit. Samtidig er det en strukturell asymmetri som favoriserer angripere, hvor én travel utvikler må tette alle sikkerhetshull og stå imot statsfinansierte angripere som bare trenger å finne én sårbarhet. Han pekte derimot på at vi som utviklere nå har en uendelig skalerbar hær av KI-agenter som vi kan (og bør) bruke til sikkerhetsanalyse, og at vi derfor kan få et jevnere kappløp fremover.

Hvis du vil unngå å installere nordkoreansk skadevare på maskinen din, bør du slå på en "minimum age"-grense i pakke-manageren din. De fleste ondsinnede pakkeversjoner blir oppdaget og fjernet fra npm-registeret i løpet av kort tid, så ved å vente noen dager før du installerer en ny versjon får du billig beskyttelse mot mange slike angrep. I pnpm og bun heter innstillingen minimumReleaseAge, mens yarn har en tilsvarende npmMinimalAgeGate.

Google introduserer JSIR 🔧

Forrige uke tilgjengeliggjorde Google kildekoden til JSIR (JavaScript Intermediate Representation). Men hva er egentlig en IR?

En IR er en intern datastruktur som verktøy bruker etter at koden er parset. Når verktøy som ESLint, esbuild, Babel, SWC, Terser eller TypeScript-kompilatoren leser JavaScript-kode, vil hver av de parse koden til sin egen interne struktur, som deretter analyseres og transformeres. Problemet er at alle disse verktøyene har sine egne interne representasjoner. Når ingen av dem er helt like, blir det vanskelig for dem å dele eventuelle optimaliseringer på tvers.

Det er altså 100 interne representasjoner ute i npm-økosystemet, og nå kommer JSIR og skal være den ene representasjonen som alle bruker. Og slik ble det 101 interne representasjoner i npm-økosystemet.

Neida. Det er jo en reell risiko, men det er også grunn til å tro at dette kan bli bra.

Noe lignende har nemlig blitt forsøkt før, og vært en stor suksess. LLVM-prosjektet løste et lignende problem for kompilerte språk som C, C++ og Swift for mange år siden. Disse språkene kompilerer ned til samme interne representasjon, som betyr at eventuelle optimaliseringer i denne representasjonen hjelper alle språkene samtidig. JSIR ser ut til å sikte mot noe lignende, bare for JavaScript.

For frontend-utviklere kan JSIR gi både raskere byggetid og mer effektive verktøy, siden den interne strukturen kan deles på tvers av verktøy istedenfor å bli bygget på nytt flere ganger.

github.com

GitHub - google/jsir: Next-generation JavaScript analysis tooling

Next-generation JavaScript analysis tooling. Contribute to google/jsir development by creating an account on GitHub.

Sesjoner som mister verdi hvis du stjeler de 🔐

Sesjonstyveri er et svært alvorlig sikkerhetsproblem på nettet i dag. Når du logger inn på et nettsted, sender serveren typisk en cookie med informasjon om sesjonen din tilbake til nettleseren. Denne cookien kan du bruke til å bevise at du er en gyldig innlogget bruker, og den gjør at du slipper å logge inn hver gang du bytter side.

Men hvis angripere får tak i denne cookien, så kan de bare lime den inn i sin egen nettleser og utgi seg for å være deg.

Heldigvis rullet Google nylig ut Device Bound Session Credentials (DBSC) i Google Chrome. DBSC binder autentiserte sesjoner kryptografisk til enheten din. Når du logger inn, genererer Chrome et kryptografisk nøkkelpar og lagrer den private nøkkelen trygt i Windows sin Trusted Platform Module (TPM). Når en sesjon utløper, må nettleseren bevise at den har den private nøkkelen før den fornyes.

Det betyr at sesjon-cookien mister mye av verdien sin hvis man ikke har den fysiske enheten som signerte den.

Men merk at hvis angripere klarer å få tak i en cookie som ikke er utløpt, så kan de fortsatt utgi seg for å være deg. Den private nøkkelen sjekkes nemlig kun når sesjonen fornyes. Derfor er det lurt å ha kortlevde sesjoner.

DBSC er foreløpig kun tilgjengelig i Chrome 146 på Windows, men macOS-støtte er allerede på vei 🙏

thehackernews.com

Google Rolls Out DBSC in Chrome 146 to Block Session Theft on Windows

Google releases DBSC in Chrome 146 for Windows, binding cookies to devices to reduce session theft and prevent unauthorized access.

Det var alt for denne gang, ha en fin uke 👋