En la antaŭa epizodo, Malfermfontaj Malicaj Pakaĵoj: La Problemo, ni diskutis kial la minacaktoroj estis tiel entuziasmaj pri publikigado de novaj malicaj komponantoj aŭ injektado de malica programaro en la plej novajn versiojn de ekzistantaj komponantoj: La malfermfonteca infrastrukturo permesas al iu ajn ie ajn krei efemeran konton en komponenta registro (kiel NPM, PyPI, Docker Hub aŭ Visual Studio Marketplace) aŭ kunlabora evoluiga platformo (kiel GitHub). Nula kosto, kaj multaj ŝancoj por utiligi la troan fidon, kiun programaraj teamoj tradicie havas al triapartaj komponantoj.
La malsimetrio inter kiom facile estas por atakantoj distribui malican programaron uzante la infrastrukturon haveblan por malfermfonteca programaro, kaj kiom malfacile estas por organizoj, kiuj disvolvas programaron (ĉiuj?) eviti infektiĝi per malicaj programoj (kaj liveri malican programaron en la programaro, kiun ili distribuas por aliaj), kondukis al la preskaŭ atingita kvaronmiliono da malicaj pakaĵoj lastjare.
Ĉi tiu estas problemo de tia grando, ke neniu sola organizaĵo povas solvi ĝin, kaj la komunumo estas en la procezo de reformulado de la malfermfonteca procezo koncerne fidon, principojn de sekureco-per-defaŭlto kaj sekureco-per-dezajno, kaj la vivciklon de komponantoj. Ni rigardos tiajn ideojn en la sekva epizodo. Protektado Kontraŭ Malfermfontaj Malicaj Pakaĵoj: Kio (Ne) Funkcias.
Memoru, ke ni parolas pri programaraj komponantoj, kiuj plej ofte respondas al programarpakaĵoj: reuzeblaj komponantoj pakitaj tiel ke ili povus esti referencitaj kiel dependeco en programara manifesto, kaj instalitaj per pakaĵadministrilo aŭ konstruilo. Bonvolu noti, ke ĉi tiu kazo povus esti vastigita por inkluzivi publikajn ujaj bildoj (uzata de konteneraj rultempaj kaj orkestradaj platformoj kiel Kubernetes), kaj etendaĵoj al programaraj iloj (por konstruado, aŭtomatigo kaj deplojo).
Jen ni analizas kiel ĉi tio ataka taktiko bazita sur malicaj komponantoj funkcias, laŭ pasintaj ekzemploj kaj tio, kion ni vidis en nia platformo por Frua Averto pri Malica Programaro (MEW). Ni analizos malicajn komponantojn en diversaj dimensioj:
(1) la elektita maniero por distribuado (registro uzata, en nova aŭ ekzistanta komponanto, kaj la tekniko uzata por infekti la publikigitan version de la komponanto), (2) kiel la malica programaro estas aktivigita aŭ ekigita, (3) la malica konduto, t.e. kiaj malutilaj agoj estas observitaj kaj kiu estas la motivo de la atakanto, (4) kiuj teknikoj estas oftaj por malklarigado, kaŝado por nerimarkiteco, laterala movado, komunikado kun komando- kaj kontrolo- (C2) gastigantoj, ktp.; kaj (5) la teknikoj por akiri sufiĉan popularecon kaj fidon por ke la viktimoj finu instalu la komponenton.
La Elektita Distribua Mekanismo
Ni observas "fona bruo"de nesofistikaj malicaj pakaĵoj uzantaj tajperarojn por trompi neatentajn programistojn kun tajperaro en la pakaĵnomo por ilia dependeco. Multaj popularaj pakaĵoj ricevas bombardon de simile nomitaj pakaĵoj kun tajperaroj, kun la atendo, ke ili trompos iujn neatentajn programistojn."
Ili uzas efemeran konton, publikigas grupon de typosquat-pakaĵoj, kreas alian, kaj publikigas alian grupon... Uzante iom da aŭtomatigo kaj eltrovemo ili povas atingi iom da rafinaĵo, sed tipe ili estas sufiĉe banalaj. Ni interne nomas ilin "anĉovojŜtelado de akreditaĵoj estas la ĉefa celo, sed foje ni trovas spionprogramojn elŝtelantajn fontkodon aŭ sentemajn datumojn kiel persone identigeblajn informojn (PII), kaptojn de tondujoj kaj aliajn dubojn.
Venante tute neatendite, ni vidas pli sofistikajn malicajn komponantojn, la "ŝarkojn". Malplimulto celas specifajn grupojn aŭ organizojn, tipe per kripto-dreniloj aŭ ret-senŝeligiloj, kiuj estas aktivigitaj kondiĉe, eble sekvante la aliron viditan en la... okazaĵo-fluo okazaĵo de malĉifrado de la ataka utila ŝarĝo nur kiam la pakaĵo estas referencita de cela pakaĵo.
La distribua mekanismo estis analizita en la bonega kaj nun klasika artikolo, “Kolekto de Tranĉiloj de Backstabber: Revizio de Atakoj kontraŭ Provizoĉenoj de Malfermfonteca Programaro", kiu estas nepre legebla. Certe vi jam vidis ĉi tiun belan diagramon antaŭe:
Ĉiuj vojoj estis esploritaj, inkluzive de novaj kaj ekzistantaj pakaĵoj; influi la fontkodon, la konstrusistemon, aŭ la pakitan komponenton mem; uzi ŝtelitajn akreditaĵojn aŭ socian inĝenieradon; kaperado de forlasitaj kontoj kaj deponejoj aŭ venenado de konservitaj. Kelkaj atakoj ricevis nomojn (Tajpokvartado, Dependeca Konfuzo, Manifesta Konfuzo, Repo-levado... ktp.) kaj jam estis diskutitaj aliloke.
Kio pri la elektitaj registroj?
NPM daŭre gvidas laŭ la tuta nombro de malicaj pakaĵoj, sed ni vidis plialtiĝon ekde ĉi tiu jaro ĉe PyPI. Python estas populara ekosistemo por datumscienco kaj maŝinlernado. Fakte, la denseco de malicaj programoj nun estas pli alta en PyPI ol en NPM.
Kiel la malica programaro estas ekigita
Malicaj pakaĵoj estas ekigitaj dum instalado nur en 4 el 10 kazoj (en la lastaj jaroj ĝi estis preskaŭ 6 el 10). La resto funkciigas malican konduton dum rulado, kun 1 el 100 ekigita dum testado. La kontraŭuloj ŝajnas scii, ke nekontrolita plenumo de instalaj skriptoj estis malebligita en multaj lokoj.
Kion ricevas la malbonuloj?
Ni listigos la kategoriojn de malica konduto, kun la plej populara unue. Bonvolu noti, ke la efiko povus esti tre malsama: a viŝilo estas obstine detrua, sed ĝi ne estas ofta kaj estis vidita nur en kelkaj kazoj, rilate al celitaj cibermilitaj kampanjoj aŭ brutala hakaktivismo. La jenaj kategorioj estas sufiĉe oftaj:
- InfoStealer / Akreditaĵoj DrainerSendube la plej oftaj, pli ol 90% el la nesofistikaj atakoj estas simplaj ŝtelistoj ĉefe serĉantaj akreditaĵojn kiel pasvortojn, alirajn ĵetonojn, API-ŝlosilojn kaj privatajn ŝlosilojn (por SSH kaj similaj). Ĝi estas probable la plej simpla por skribi (kune kun forviŝiloj?). Ili listigas konatajn dosierojn/dosierujojn kaj aliajn fontojn (ekz. registroŝlosilojn), pakas la enhavon kaj sendas tiujn datumojn al C2-servilo. La ideo estas simpla: "Mi publikigas ŝteliston por fiŝkaptaj akreditaĵoj, por ke mi poste povu uzi la akreditaĵojn por lanĉi direktitan atakon".
La observita C2-retigado estas tipe malmultekosta kaj malpura, kiel Telegram-kanaloj aŭ ngrok-similaj tunelaj iloj (ofte en la formo de inversaj prokuriloj eksponitaj per VPN-eliraj IP-adresoj). Ekzistas centoj (!) da eblecoj, kun multaj GitHub-projektoj sub la temo pri pasvortŝteloSpecialiĝoj kiel ŝlosilregistriloj estas maloftaj por malicaj pakaĵoj kaj kontenerbildoj, sed pli oftaj en iletendaĵoj, kie uzanta interagado estas atendata.
- Gutigilo / ElŝutiloLa dua laŭ populareco, tipe unua en plurŝtupaj atakoj. Pli ol unu el tri malicaj komponantoj havas elŝutilojn (se la malica utila ŝarĝo estas inkluzivita en la pakaĵo) aŭ elŝutilojn (la utila ŝarĝo estas elŝutita de finpunkto sub la kontrolo de la atakanto). La utila ŝarĝo ofte estas konata duuma variaĵo de malica programaro, kaj ĝi estas funkciigata kaj foje daŭrigata, por instali malantaŭajn pordojn, spionprogramojn, kripto-elŝutilojn kaj aliajn uzkazojn. La elŝutita aŭ deplojita utila ŝarĝo komencas duafazatakon kun la tuta potenco provizita de ekzistantaj malica programaro. La duumaj dosieroj povas esti distribuitaj ene de la pakaĵo, ofte maskitaj kiel bildoj aŭ supozeble sendanĝeraj dosiertipoj, por eviti detekton dum konektado al neatenditaj retejoj.
- Ŝtelistoj / Ministoj de KriptovalutojFinance motivitaj kontraŭuloj volas uzi viajn nubajn aktivaĵojn por funkciigi kriptoministojn (ili eĉ detektas ĉu ili funkcias en nuba virtuala maŝino). Ili ne zorgas pri la malalta profita proporcio de 1 dolaro por ĉiu 53 dolaroj fakturitaj al la viktimo pro la ŝtelita nuba infrastrukturo. Viktimoj eble ne konscios pri tio ĝis ili ricevos neatenditan fakturon. Bonŝance, tio venas kaj iras. Kriistoj kampanjoj en malicaj pakaĵoj foje aperas kaj poste malaperas, trompŝtelante monujajn uzantojn aŭ eventuale celante la monujprovizanton, kiel en la Ĉeflibro-atako.
Aliaj kondutoj, kiel deploji malantaŭa pordo por fora kodplenumo per malfermo de inversa ŝelo estas malpli ofta nun ol en la pasinteco. Ekzemple, la 123rf_kontribuanto_reto pakaĵo (nun forigita el la registro) malfermiĝas sen ia ajn malklarigo inversa ŝelo kopiita kaj algluita el la Inversa Ŝela Trompfolio:
Aldone al legitimaj kaj malicaj komponantoj, ni observis plurajn misuzojn, inkluzive de:
Spam-pakaĵoj
Ekzistas miloj da malgrandaj pakaĵoj, plejparte en NPM, sen malica programaro sed promesante facilajn enspezojn, ŝajnmanovrojn, ligilojn al Viagra-ofertoj, kaj ĉion tian. Kelkaj uzantoj publikigas tian spamon kaj prenas multan bendlarĝon de la registro. Alia(j) aktoro(j) eble el Indonezio provis eltiri profiton per misuzante la teonRango celita por kompensi malfermfontajn programistojn, per kreado de dekoj da miloj da interrilataj NPM-pakaĵoj kun rilataj GitHub-ŝajndeponejoj. Ĉi tio estas klara malobservo de la uzkondiĉoj.
Cimo-premioj kaj sekurec-esploradaj trompoj
Kiam pakaĵo priskribas sin kiel elfiltranta datumojn por bonaj celoj, kiel detekti sekurecajn difektojn por cimo-premiaj programoj aŭ esplori certajn aspektojn de la ekosistemo. Ni vidis milojn da pakaĵoj en ĉi tiu kategorio, kiuj alportas identigon sed ne tro sentemajn datumojn al Burp Collaborator-adreso de Portswigger (ekz. gastiganto en oastify.com-domajno). Ni ofte observis imitistojn de la Dependeca Konfuzo pruvo-de-koncepto fare de Alex Birsan, kiel la Aurora-retpoŝto-profesiulo pakaĵo (forigita el la registro), kiu simple ekzekutas ĉi tiun malagrablan kodon en la antaŭinstala skripto:
Kaj ankaŭ inkluzivis “Ĉi tio estas simpla atako kontraŭ dependeca konfuzo, pruvo de koncepto."priskribo de malgarantio en la pako.jsonĈi tio estas klara malobservo de la servkondiĉoj, eĉ sen malica intenco.
Ĉu bonaj novaĵoj? Ni (ankoraŭ) ne vidis elaĉetprogramajn atakojn faritajn per malicaj komponantoj. Pro nekonataj kialoj, ciberkrimuloj ŝajnas preferi pli tradician retpoŝtan fiŝkaptadon, RDP-bazitan kaj aŭtomatajn elŝutajn livermekanismojn.
Pliaj Teknikoj Observitaj
Multaj teknikoj estis uzitaj por persisto, defend-evitado, informkolektado, komunikado kun komando- kaj kontrol-gastigantoj, kaj elfiltrado.
persisto en malicaj komponantoj estas akirita uzante la persistfunkciojn en dua-ŝtupa binara malica programaro, sed kelkfoje la konduto troviĝas en la pakaĵkodo, kun planitaj taskoj kaj ŝanĝoj en la Vindoza registro la plej oftaj.
Malfunkcio estas ofta, sed nesofistika. Plej multaj tajperakupaĵaj pakaĵoj (memoru la "anĉovoj”?) tute ne uzas malklarigon; multaj uzas aŭ trivialajn (base64/sesuma kodado aŭ anstataŭigajn ĉifrojn kiel rot13) aŭ uzas disponeblajn kodmalklarigilojn kaj minimumigon, kio facile inversigeblas per la ĝusta ilo. Nur la “ŝarkoj” faras veran, malfacilan malklarigon, malfacile retroinĝeniereblan.
Malklarigado eble kaŝus la atakon, sed kial kodo en malfermfonteca komponanto bezonus esti malklarigita? Ĉu ekzistas pruvoj, ke io devas esti kaŝita de simpla vido? Ni trovis multajn kazojn de ne-malicaj pakaĵoj, kiuj uzas malklarigadon por protekti intelektan propraĵon, kio kontraŭdiras al "malfermfonteca". Malklarigado povas esti uzata kiel pruvo de malica programaro, sed ĝi ne estas decida. Estas ankaŭ malfacile malmalklarigi ĝin.
evasión de defendaj kontroloj adoptas simplajn teknikojn. Malica kodo ofte estas protektata en provi … kapti blokoj kiuj ignoras iujn ajn esceptojn, do nenormala agado ne estas montrata en la protokoloj. Kontrolo de la medio (funkcianta en virtuala maŝino aŭ ujo) estas malofta, krom se temas pri malica programaro celanta specifan organizon aŭ medion.
Maskado de duumaj dosieroj en bildoj kaj PDF-dosieroj (speco de steganografio) estis alia tekniko vidita por eviti detekton.
Ĉar la plej oftaj malicaj komponantoj estas informŝtelistoj, datumkolektado estas esenca. Sekretoj (pasvortoj, alirsignoj, API-ŝlosiloj, ĉifraj ŝlosiloj) estas rutine skanitaj en ŝtipo-dosieroj, ĉirkaŭaj variabloj, kaj eĉ la tondejo (vidite ĉe bankaj trojanoj kaj kriptoŝtelistoj). Fontkoda elfiltrado ankaŭ estas ofta, ĉar la pakaĵa instalado ofte okazas en evoluiga nodo, kie internaj git-deponejoj eble estas klonitaj. Ni vidis pakaĵojn listigantajn dosierujojn serĉante git-deponejojn. Serĉi lokojn kiel .env, private.pem, settings.py, app.js, aŭ application.properties estas sufiĉe ofta.
Elfiltrado estas alia vaste uzata ago. Nur malplimulto de malicaj pakaĵoj eĉ provas kaŝi la cellokon de la eltiritaj datumoj. Telegram-kanaloj kaj ngrok-similaj tuneloj ofte estas uzataj. Kaj estas multaj tipe blanklistigitaj domajnoj uzataj por eksfiltrado.
Aliaj teknikoj, kiel privilegieskalado aŭ laterala movado, estis malpli oftaj.
Gajnante Popularecon kaj Fidon
Imagu teĥnologian krimulon kun preta mortiga malica aĵo, kiu scivolas: "Kiel mi povas igi ĉi tiun fekaĵon fidinda al tiuj sensuspektaj stultuloj?".
Tio tradukiĝas al kiel fari la eniron por la malica komponanto por montri multajn stelojn / forkojn (por populareco), plus versiojn / problemojn kaj pull requests (por aktiveco). La ideo estas akiri fikcian popularecon (stelojn) kaj dependantojn, kaj konvinkan aspekton rilate al graveco kaj bontenado.
La registro ne kontrolas ĉu la enhavo en GitHub-projekto kaj la pakaĵenhavo kongruasĈi tio estas bone konata problemo en la provizoĉeno de programaro. La publikaj registroj estas gigantaj dolinoj, kiuj englutas ĉion, kion oni ĵetas al ili. Vi povas ligi ajnan deponejon.
Se la malica pakaĵo eraras laŭ la tajperaro de populara pakaĵo, tio estas facila: simple referencu la ekzistantan GitHub-deponejon en la dependeca manifesto uzata por krei la pakaĵon kaj publikigi ĝin en la registro. Por novaj pakaĵoj en falsa GitHub-deponejo, vi eble bezonos pli da eltrovemo, eble kreante falsajn... stelobservado/forkiĝo GitHub-kontoj per skriptado.
Kaj se la enhavo de via pakaĵo estas sufiĉe simila al la deponejo, enŝovu kelkajn bone dizajnitajn ŝanĝojn tie kaj tie... Vi povas injekti vian malware en novan pakaĵon similan al populara pakaĵo referencante la deponejon de la ekzistanta, kaj atendi la tajperarojn. Se iu kuraĝas kompari la enhavon de la pakaĵa tarball kun la enhavo de la GitHub-deponejo, la diferencoj ĉe la malware-injektaj punktoj povus facile esti preteratentitaj. Ni jam vidis ĉi tiun aliron multajn fojojn antaŭe.
Mekanismo por ke komponanto faru neŝanĝeblan deklaron pri deveno, kiel la pakaĵo estis konstruita, el kiaj fontoj, kaj de kiu, estus bonvena. Sed tio estas alia rakonto.
Ĉu komponanto X estas malica programaro?
Ĉu ekzistas (ampleksa) datumbazo de malicaj pakaĵoj? Ne. Malfermitkodaj vundeblecoj havas CVE-ID-on asignitan, sed nur kelkaj malicaj pakaĵoj (precipe tiuj, kiuj faras fraptitolojn) ricevas tian. La CWE por malicaj pakaĵoj estas CWE-506 (enigita malica kodo).
La kutimaj iloj kontraŭ malica programaro (VirusTotal, MalwareBazaar, SOREL-20M…) ne specifas la kondiĉojn por malicaj komponantoj. Tio estus bonvena!
Ekzistas esploraj specimenaj datumbazoj kaj datumaroj por analizo (ni uzas kelkajn el ili), sed la enskriboj estas ĝisdatigitaj nur kiam la malica pakaĵo estas konata, kio ofte estas tro malfrue. Se vi interesiĝas, la OpenSSF Malicaj Pakaĵoj estas bela komenco.
En la sekva afiŝo, ni diskutos kiel scii ĉu difinita pakaĵo estas malica. Averto: jes, ekzistas manieroj kontroli malicajn komponantojn frue dum la eksponperiodo, antaŭ ol la registro forigas konatan malican komponanton.
plia legado
En la sekva epizodo “Protektado Kontraŭ Malfermfontaj Malicaj Pakaĵoj: Kio (Ne) Funkcias" ni diskutos la farendaĵojn kaj nefarendaĵojn por malfermitkoda sekureco. Plej multaj sekurec-konsciaj profesiuloj havas intuiciojn pri kiel trakti ĉi tiun minacon, sed miskomprenoj abundas.
Ni revizios kial ĉi tiuj ideoj estas malĝustaj, kaj kiel tiaj miskomprenoj kontribuas al la populareco de ĉi tiu atakmekanismo, kaj al la superforta risko, kiun organizoj spertas. Ni daŭrigos poste kun tio, kio funkcias, kaj kiu estas la peno kaj rimedoj implikitaj.
Ankaŭ, ni afiŝos pri la evoluo de malicaj pakaĵoj rilate al ilia intenco, injektomekanismo kaj atakteknikoj.
Restu agordita!
