Isang Pagkakamali na May Isang Karakter na Nagpadala ng Malware
Nagsimula ito sa isang typo. Sa gitna ng matinding pagmamadali ng mga feature pushes at PR merge, may nag-type... @utils_core sa halip ng @utils-core sa package.json. Ang single character slip na iyon ay hindi nagdulot ng error. Sa halip, tahimik itong nagdulot ng malisyosong kamukha ng pakete sa susunod CI/CD patakbuhin, gamit ang tiwala sa mga naka-pin na bersyon at automation. Maligayang pagdating sa mundo ng typosquatting sa open source.
Typosquatting: Ang Vector ng Pag-atake na Umuunlad sa Pagkakamali ng Tao
Ang typosquatting ay eksakto kung ano ang tunog nito: ang mga malisyosong aktor ay nagrerehistro ng mga pakete na may mga pangalan na halos magkapareho sa mga lehitimong pangalan. Sa mabilis na mga kapaligiran, gumagana ito dahil nagtitiwala ang mga developer na ang kanilang package.json at package-lock.json sumasalamin sa inaasahan nila. Isang karakter lang ang kulang? Parang hindi na lang ito nakikita sa isang PR diff.
NPM ay may kasaysayan ng pagsasamantala sa pamamagitan ng typosquatting. Mga pakete tulad ng crossenv sa halip ng cross-env or kaganapan Naipakita na ng mga backdoor kung gaano kabisa ang mga kamukha nitong software. Ang mga pekeng paketeng ito ay kadalasang nakakapasa sa mga review dahil lang sa mukhang tama ang mga ito at hindi agad nagdudulot ng mga runtime error.
Kabilang sa mga karaniwang bitag ang:
- Gitling vs. salungguhit: lodash-core vs lodash_core
- Pangmaramihan: humiling vs kahilingan
- Mga pinalit na karakter: ekspresyon sa halip ng ekspres
Kung saan ang package-lock.json ay nagiging isang Blind Spot
Inayos ng developer ang kanilang typo. O sa palagay nila. Pero sa ngayon, package-lock.json ay nakakulong na sa pakete ng umaatake. At dito nagtatago ang tunay na panganib.
Hindi magkatulad package.json, na manu-manong ine-edit at mas sinusuri, package-lock.json ay awtomatikong nabubuo ng NPMBilang resulta, madalas itong itinuturing na isang pormalidad, nilalaktawan, o binabalewala lamang pull request mga review. Hindi bihira para sa mga team na markahan ito bilang "masyadong maingay" o basta-basta itong pagkatiwalaan nang walang malalim na pagsusuri.
Alam ito ng mga umaatake. Umaasa sila rito. Kapag malisyosong pakete ay tinutukoy, dahil sa isang typo sa package.json, package-lock.json Itinatala ang nalutas na bersyon. Kahit na naitama ang typo sa ibang pagkakataon, maaaring magpatuloy ang malisyosong entry maliban kung ang lockfile ay tahasang ginawang muli.
Para mas lumala pa ang sitwasyon, ang version pinning, na dapat sana'y nagsisiguro ng consistency, ay maaaring magdulot ng backfire. Maaaring i-version ng mga attacker ang kanilang pekeng package nang kapareho ng lehitimo. Kung ang CI/CD Kung ang sistema ay walang taros na nagtitiwala sa mga naka-pin na bersyon, hindi nito matutukoy na nag-i-install ito ng isang package na may kilalang-kilalang numero ng bersyon ngunit mula sa ibang at malisyosong pinagmulan.
Ang tahimik na pagtitiyaga na ito ang siyang dahilan package-lock.json napakadelikado. Tinitiyak nito ang mga deterministic build, oo, pero ginagarantiya rin nito na mananatili ang isang sirang pakete maliban kung mahuhuli at malinis nang manu-mano.
CI/CDKung Saan Tinatamaan ng Malware – package.json
Sa isang tipikal CI/CD pipeline, hindi na kailangang maghintay ang malisyosong pakete hanggang sa oras ng pagpapatakbo. Mas maaga itong nareresolba at nati-trigger sa daloy:
Dependency Resolution
Ang pipeline kinukuha ang eksaktong mga bersyon ng dependency mula sa package-lock.json, na ngayon ay kinabibilangan ng na-typo ang pakete dahil sa typo sa package.json.
Yugto ng Pag-install
Sa panahon ng npm ci, lahat ng dependency ay ini-install, kasama na ang malisyosong dependency. Walang mga babala, walang mga prompt, tahimik na pag-install lamang.
Pagpapatupad ng Script Pagkatapos ng Pag-install
Kasama sa lookalike package ang isang post-install script na awtomatikong tatakbo kapag nakumpleto na ang instalasyon. Dito nangyayari ang kompromiso.
Halimbawa ng pseudocode:
Paglalarawan ng pseudocode:
Sa yugto ng pag-install, kung mayroong hook pagkatapos ng pag-install, iti-trigger ng pekeng package ang nakatagong logic nito—kadalasan bago pa man tumakbo ang mga build o test. Maaaring kasama rito ang paggawa ng mga external request, pag-inject ng mga backdoor, o iba pang hindi awtorisadong aksyon.
⚠️ Babala: Ang pseudocode na ito ay para lamang sa mga layuning demonstrasyon at hindi dapat gamitin sa totoong kapaligiran.
Walang nati-trigger na mga alerto. Walang nabibigo. Nakompromiso na ang kapaligiran, bago pa man ang iyong pipeline umabot pa nga sa yugto ng pagsubok.
Pagtuklas sa Pagkakaiba Bago Mahuli ang Lahat
Isang karaniwang pagkakamali: pag-aakalang package.json nagsasalaysay ng buong kwento. Hindi. Ang tunay na kapangyarihan ay nasa kombinasyon ng package.json + package-lock.json.
Narito kung ano ang hahanapin:
- Sinusuportahan ba ng package-lock.json may kasamang mga hindi inaasahang pakete?
- Mayroon bang anumang mga dependency na nagmula sa hindi kilalang mga rehistro o may kakaibang mga saklaw?
- Masyado bang espesipiko o hindi ba magkatugma ang mga numero ng bersyon?
Gumamit ng mga tool ng CLI tulad ng:
- npm audit upang i-flag ang mga kilalang isyu
- npm ls para makita ang buong dependency tree
- Diff upang ihambing ang mga bersyon sa pagitan ng package.json at package-lock.json
Patigasin ang Iyong PipelineMga Depensang Epektibo
Para maiwasan ang typosquatting:
- Ipatupad ang mga paghihigpit sa saklaw sa package.json.
- Magdagdag ng pre-merge hooks para mag-lint at mag-validate ng mga dependency.
- paggamit npm ci upang maiwasan ang hindi sinasadyang pag-anod ng bersyon.
- Regular na i-scan package-lock.json para sa mga anomalya.
At pinakamahalaga: ituring ang mga hindi na-verify na entry sa package-lock.json bilang mga potensyal na panganib. Bawat commit dapat ituring bilang isang checkpoint ng supply chain.
Awtomatikong Pagtuklas: Paano Nakakatulong ang mga Kagamitang Tulad ng Xygeni
Bagama't hindi ito isang magandang solusyon, ang mga awtomatikong kagamitan tulad ng Xygeni Gumaganap ng mahalagang papel sa pagbabawas ng salik ng human error na siyang dahilan ng typosquatting. Direktang isinasama ang Xygeni sa iyong DevOps workflow, na nagdaragdag ng isang layer ng real-time na proteksyon laban sa dependency hijacking bago pa man ito umabot sa pagpapatupad.
Narito kung paano nakakatulong ang Xygeni:
- Pagtukoy sa Kahina-hinalang Pangalan ng Pakete:
Gumagamit ng smart heuristics upang matukoy ang mga pattern ng typosquatting sa package.json, naghahanap ng maliliit na pagkakaiba-iba sa mga kilalang pangalan ng pakete (tulad ng mga idinagdag na underscore, transposisyon, o pagpapalit ng letra). - Hindi Kilalang Pag-verify ng Hash:
Inihahambing ang hash ng bawat dependency sa package-lock.json laban sa isang database ng mga kilalang-magandang artifact mula sa mga pinagkakatiwalaang registry. Kahit na maganda ang hitsura ng pangalan at bersyon ng package, ang hindi pagtutugma ng hash ay nagdudulot ng pulang bandila. - Pagha-block Bago ang Pagbuo:
Hinaharang at hinaharangan ang pag-install ng anumang hindi na-verify o kahina-hinalang mga pakete bago pa man umabot ang mga ito sa mga yugto ng pag-install o pagkatapos ng pag-install. CI/CD pipeline. - Pagsusuri ng Graph ng Dependency:
Patuloy na sinusuri ang buong dependency tree para sa mga hindi direktang pagtatangka ng typosquatting o mga malisyosong transitive dependencies. - Mga Alerto at Pag-uulat:
Nagbibigay ng detalyado at naaaksyunang mga alerto, na nagpapakita kung ano ang na-flag, bakit, at saan ito nagmula sa dependency chain.
Habang nagiging mas kumplikado ang mga package ecosystem, nagiging mahalaga ang mga tool tulad ng Xygeni. Ang manu-manong pagsusuri ay hindi sumasaklaw sa paglawak ng dependency o mabilis na pag-ulit. Makikialam ang Xygeni upang i-automate ang mga kritikal na pagsusuri sa modernong... pipelinepangangailangan, na nagsasara ng agwat sa pagitan ng tiwala at beripikasyon.
Isang Tauhan. Mga Tunay na Bunga.
Hindi ito isang kakaibang bagay Zero-Araw. May typo. Isang karakter na hindi nailagay sa ibang lugar package.json, tahimik na pinatibay ng package-lock.json, at awtomatikong naipadala ang malware sa isang routine CI/CD tumakbo.
Iyan ang tunay na panganib ng typosquatting: hindi nito kailangan ng komplikasyon. Ginagamit nito ang bilis, tiwala, at automation. Maaaring napigilan sana ang kompromisong ito kung naipatupad ang mga tamang kontrol:
- Awtomatikong Pag-scan para mahuli ang mga kahina-hinalang pangalan at bersyon ng pakete bago i-install.
- Pag-audit ng Lockfile upang matukoy ang mga hindi nasuri o hindi inaasahang entry sa package-lock.json.
- Heuristiko sa Pag-verify ng Pangalan para i-flag ang mga malapit-tugma sa mga pinagkakatiwalaang pakete.
Isang karakter lang ang kailangan. Ang mga tamang pagsusuri ay mapipigilan sana ito bago pa man ito madikit sa iyo pipelineHindi sapat ang tiwala. Sa modernong DevSecOps, bineberipika mo ang lahat, o isinusuko mo ang lahat.
