Грешка од једног карактера која је слала злонамерни софтвер
Почело је са грешком у куцању. Негде у масовној гужви промовисања нових функција и спајања порука са јавношћу, неко је откуцао @utils_core УМЕСТО @utils-core у пацкаге.јсонТај пропуст са једним карактером није избацио грешку. Уместо тога, тихо је унео злонамерни пакет сличан злонамерном током следећег CI/CD покренути, користећи поверење у закачене верзије и аутоматизацију. Добродошли у свет типосквотинга у отвореном коду.
Типосквотинг: Вектор напада који напредује захваљујући људским грешкама
Типосквотинг је управо оно што звучи: злонамерни актери региструју пакете са именима готово идентичним легитимним. У брзим окружењима ово функционише јер програмери верују да њихови пацкаге.јсон пацкаге-лоцк.јсон одражава оно што очекују. Један лик је погрешан? Могло би бити исто тако невидљиво у PR разлици.
НПМ има историју злоупотребе путем типосквотинга. Пакети попут крос-енв УМЕСТО крос-енв or ток догађаја Бакдоори су већ показали колико ефикасни могу бити ови слични пакети. Ови лажни пакети често пролазе провере једноставно зато што изгледају добро и не избацују тренутне грешке током извршавања.
Уобичајене замке укључују:
- Цртица наспрам подвлаке: lодаш-кор vs lodash_core
- Множина: захтева vs Захтеви
- Замењени знакови: експрес УМЕСТО изразити
Где package-lock.json постаје слепа тачка
Програмер исправља своју грешку у куцању. Или барем тако мисле. Али до сада, пацкаге-лоцк.јсон већ је закључао пакет нападача. И ту се крије прави ризик.
супротно пацкаге.јсон, који се ручно уређује и подвргава се детаљнијој контроли, пацкаге-лоцк.јсон је аутоматски генерисан од стране НПМКао резултат тога, често се третира као формалност, прескаче се или се само површно прелиста pull request рецензије. Није неуобичајено да тимови означе да је „превише бучна“ или да јој имплицитно верују без дубљег разматрања.
Нападачи то знају. Они се ослањају на то. Једном злонамерни пакет је референцирано, захваљујући грешци у куцању package.json, package-lock.json бележи решену верзију. Чак и ако се грешка у куцању касније исправи, злонамерни унос може да опстане осим ако се датотека закључавања експлицитно не регенерише.
Да ствар буде још гора, фиксирање верзија, које би требало да обезбеди доследност, може се обити о главу. Нападачи могу да верзионишу свој лажни пакет идентично легитимном. Ако CI/CD Систем слепо верује закаченим верзијама, неће открити да инсталира пакет са познато добрим бројем верзије, али из другог, злонамерног извора.
Ова тиха истрајност је оно што чини пацкаге-лоцк.јсон тако опасно. Обезбеђује детерминистичке изградње, да, али такође гарантује да ће лош пакет остати у употреби осим ако се не ухвати и не очисти ручно.
CI/CDГде злонамерни софтвер удара – package.json
У типичном CI/CD pipeline, злонамерни пакет не мора да чека до извршавања. Решава се и покреће много раније у току:
Резолуција зависности
pipeline извлачи тачне верзије зависности из package-lock.json, што сада укључује пакет са погрешном куцањем због грешке у куцању package.json.
Фаза инсталације
Током npm ci, све зависности се инсталирају, укључујући и злонамерну. Без упозорења, без захтева, само тиха инсталација.
Извршавање скрипте након инсталације
Пакет сличан лајку укључује скрипту након инсталације која се аутоматски покреће након завршетка инсталације. Ту се дешава компромитовање.
Пример псеудокода:
Опис псеудокода:
Током фазе инсталације, ако је присутан пост-инсталациони животни циклус хоок, лажни пакет покреће своју скривену логику — често пре него што се изградње или тестови уопште покрену. То може укључивати слање спољних захтева, убацивање задњих врата или друге неовлашћене радње.
⚠️ Упозорење: Овај псеудокод је само у сврху демонстрације и не сме се користити у стварним окружењима.
Не покрећу се никаква упозорења. Ништа не отказује. Окружење је већ угрожено, пре него што ваше pipeline чак стиже до фазе тестирања.
Уочавање разлике пре него што буде прекасно
Уобичајена грешка: претпостављање пацкаге.јсон прича целу причу. Не прича. Права моћ лежи у комбинацији package.json + package-lock.json.
Ево на шта треба обратити пажњу:
- Да ли? пацкаге-лоцк.јсон укључити неочекиване пакете?
- Да ли неке зависности потичу из непознатих регистара или имају чудне опсеге?
- Да ли су бројеви верзија превише специфични или погрешно поравнати?
Користите CLI алате као што су:
- нпм аудит да означи познате проблеме
- npm ls да бисте видели целокупно стабло зависности
- дифф да упоредите верзије између пацкаге.јсон пацкаге-лоцк.јсон
Очврсти своје PipelineОдбране које делују
Да бисте се заштитили од грешака у типографији:
- Примените ограничења обима у package.json.
- Додај пре спајања hooks за линтовање и валидацију зависности.
- употреба нпм ци да би се избегло ненамерно померање верзије.
- Редовно скенирајте пацкаге-лоцк.јсон за аномалије.
И најважније: третирајте непроверене уносе у пацкаге-лоцк.јсон као потенцијалне ризике. Сваки commit треба третирати као контролну тачку ланца снабдевања.
Аутоматско откривање: Како алати попут Xygeni-ја помажу
Иако нису чаробни штапић, аутоматизовани алати попут Ксигени играју кључну улогу у смањењу фактора људске грешке на којем „typosquatting“ напредује. Xygeni се директно интегрише у ваш DevOps ток рада, додајући слој заштите у реалном времену од отмице зависности пре него што уопште дође до извршења.
Ево како Ксигени помаже:
- Детекција сумњивог имена пакета:
Користи паметну хеуристику за откривање образаца грешака у типографији пацкаге.јсон, тражећи мање варијације у добро познатим именима пакета (као што су додате доње црте, транспозиције или замене слова). - Верификација непознатог хеша:
Упоређује хеш сваке зависности у пацкаге-лоцк.јсон у односу на базу података познатих артефаката из поузданих регистара. Чак и ако назив и верзија пакета изгледају у реду, неусклађеност хеша изазива забринутост. - Блокирање пре изградње:
Пресреће и блокира инсталацију свих непроверених или сумњивих пакета пре него што дођу до фазе инсталације или постинсталације у CI/CD pipeline. - Анализа графа зависности:
Непрекидно прегледа целокупно стабло зависности у потрази за индиректним покушајима грешака у типографији или злонамерним транзитивним зависностима. - Упозорења и извештавање:
Пружа детаљна, практична упозорења, приказујући шта је означено, зашто и одакле је дошло у ланцу зависности.
Како екосистеми пакета постају сложенији, алати попут Xygeni-ја постају неопходни. Ручни преглед се не скалира са ширењем зависности или брзом итерацијом. Xygeni ускаче да аутоматизује критичне провере модерног... pipelineпотреба, затварање јаза између поверења и верификације.
Један лик. Праве последице.
Ово није била егзотика нулти данБила је то грешка у куцању. Један погрешно постављен знак у пацкаге.јсон, тихо појачано од стране пацкаге-лоцк.јсони злонамерни софтвер је аутоматски испоручен током рутине CI/CD трцати.
То је права опасност од типосквотинга: не захтева сложеност. Искоришћава брзину, поверење и аутоматизацију. Овај компромис је могао бити спречен уз одговарајуће контроле:
- Аутоматско скенирање да би се открила сумњива имена и верзије пакета пре инсталације.
- Ревизија закључаних датотека да би се открили непрегледани или неочекивани уноси у пацкаге-лоцк.јсон.
- Хеуристика верификације имена да означи блиска подударања са поузданим пакетима.
Један знак је био довољан. Праве провере би га зауставиле пре него што би додирнуо твоје... pipelineПоверење није довољно. У модерним DevSecOps-овима, или све проверавате, или ризикујете све.
