Aquest és el tercer episodi d'una sèrie d'articles sobre el tipus més prevalent d'atacs a la cadena de subministrament de programari: aquells que abusen d'un registre públic de de codi obert components de programari. Després d'analitzar a l'episodi anterior "Anatomia dels paquets maliciosos: quines són les tendències?"Com els malfactors injecten comportaments maliciosos en components publicats nous o existents, estem preparats per posar-nos les armilles de protecció i examinar com podem bloquejar amb èxit el programari maliciós distribuït d'aquesta manera o, alternativament, fer front a un incident cibernètic potencialment greu perquè hem adoptat l'enfocament equivocat."
La majoria de professionals amb coneixements de seguretat tenen idees sobre com gestionar aquesta amenaça. Hem sentit els responsables de seguretat dir sense dubtar-ho que SCA Les eines ja us indiquen quan una versió d'un paquet és programari maliciós. O que depenen de components de programari coneguts i altament revisats, on qualsevol programari maliciós es detectaria i s'eliminaria ràpidament. Utilitzen versions menors/pegats obertes per obtenir automàticament correccions de vulnerabilitats, i aquesta és la manera correcta i recomanada de reduir el risc en les dependències de codi obert, seguint el "pegat aviat, pegat sovint" principi.
En aquest episodi, revisarem per què aquestes idees són errònies i com aquests conceptes erronis contribueixen a la popularitat d'aquest mecanisme d'atac i a un risc aclaparador que estan experimentant les organitzacions. Acabarem amb què funciona i quin és l'esforç i els recursos implicats.
Ideas errònies habituals
Durant el nostre viatge amb la seguretat del programari, hem vist com evolucionaven les tècniques d'atac i una àmplia gamma d'idees de persones preocupades per la seguretat. Les organitzacions sovint no entenen què funciona contra aquesta amenaça, per la qual cosa primer examinarem què no funciona, condensat en la següent llista, no exhaustiva, d'idees errònies.
Idea equivocada núm. 1: SCA les eines ja informen de components maliciosos
En efecte! Però després del fet... Quan probablement ja és massa tard si l'element s'ha utilitzat en una compilació de programari i els malfactors ja s'han afermat a un desenvolupador o CI/CD amfitrió. Potser s'han exfiltrat secrets, s'ha descarregat i instal·lat programari maliciós addicional i, potser, l'adversari s'ha mogut lateralment i ja ha obtingut accés a altres llocs.
Anàlisi de la composició del programari (SCA) eines van ser dissenyades per identificar possibles vulnerabilitats conegudes. Les eines modernes fan una gran feina augmentant la relació senyal-soroll, determinant si la vulnerabilitat és realment accessible o explotable. Però són inútils contra el programari maliciós nou. Penseu en un component maliciós com una vulnerabilitat de dia zero: només quan es detecta el seu comportament maliciós, el component es notifica al registre de manteniment, que després d'una revisió per part d'un equip de seguretat es confirma com a maliciós i s'elimina del registre. [1].
En aquell moment, el món (inclòs SCAs) sap que instal·lar o utilitzar el component (o alguna versió d'un component existent) no és una bona cosa. Però això passa quan el component no està disponible al registreSaber que tinc vulnerabilitats en components de tercers, o fins i tot components que el registre ha classificat com a maliciosos, és bo, però malauradament SCA o les eines d'auditoria comunes no ajuden en aquest context. A menys que SCAL'eina /audit pot saber per endavant que un component és maliciós abans que s'utilitzi a la vostra organització..
Recordeu que qualsevol solució contra components de codi obert maliciosos els ha de detectar. sobre la marxa, entre quan el component es publica al registre i quan el component (versió) s'utilitza per primera vegada a la vostra organització. I això inclou els components transitius.
Idea errònia núm. 2: Controlar els scripts d'instal·lació en temps de compilació impedeix el comportament maliciós dels components de codi obert
Diversos gestors de paquets ofereixen la possibilitat d'executar scripts (inclosos al fitxer tar del component [2]), per motius legítims, com ara compilar elements necessaris en diferents plataformes, generar codi o executar proves, i tots hauríem de saber que poden ser utilitzats de manera abusiva per malfactors si s'inclouen scripts maliciosos al tarball o si l'atacant pot fer que s'executi un script maliciós en lloc del correcte.
Sabent això, podem configurar el gestor de paquets per ignorar els scripts. Per exemple, amb NPM, el -ignore-scripts bandera (o una propietat de configuració a .npmrc fitxer) omet els scripts durant la instal·lació. Això pot produir alguns problemes perquè l'execució de scripts és habitual en molts ecosistemes: alguns gestors de paquets ni tan sols permeten desactivar l'execució de scripts (pista: prompt "Quins gestors de paquets no permeten desactivar l'execució de scripts d'instal·lació?"a la teva IA preferida). Però això no protegeix en general (hem de fer complir que la configuració de desactivació de salts estigui a tot arreu).
I quan el comportament maliciós no es troba en els scripts d'instal·lació sinó en el programari que s'executa en temps d'execució, aquesta opció per si sola no ens protegeix.
Idea errònia núm. 3: La fixació de versions impedeix que s'instal·lin components maliciosos
Hi ha un compromís entre aplicar pegats aviat i sovint amb versions obertes (permetent que el gestor de paquets instal·li automàticament noves actualitzacions quan estiguin disponibles per a correccions de seguretat) i fixació de versions (tenint totes les dependències directes i transitives per a un programari en una versió fixa). Els principis de seguretat són tossuts i de vegades contradictoris, com passa amb "pegar aviat, pegar sovint" i "No s'ha de prendre a la lleugera la millora"Alguns gestors de paquets fan actualitzacions automàtiques amb rangs de servidors de la manera recomanada. Ideal si també voleu rebre les actualitzacions malicioses! Sí, els components s'han d'actualitzar per rebre correccions de seguretat que tanquin les vulnerabilitats el més aviat possible, però... no deixeu mai que el gestor de paquets ho faci automàticament.
Idea errònia núm. 4: L'ús de components de confiança és segur. Qualsevol versió maliciosa es trobaria, divulgaria i s'eliminaria ràpidament.
Per què es confia en un component? Possiblement perquè és molt popular, amb molts usuaris que busquen vulnerabilitats, un gran nombre de col·laboradors per al manteniment, amb diversos mantenidors principals que ho revisen tot diligentment. pull requestsLa realitat és força diferent. Alguns components essencials els manté un únic desenvolupador no remunerat. Els marcs de treball més utilitzats tenen uns quants col·laboradors habituals, amb un nombre que disminueix ràpidament commits per mantenidor (els projectes populars tenen una llarga cua de col·laboradors que realitzen algunes tasques de control) commit i no tornaran mai més). I abunden els projectes populars amb un únic mantenidor.
Imagina't dient "Oh, estem utilitzant Spring Boot / Angular / React / PyTorch / imatges base oficials de Docker, així que el risc del qual parleu és força baix." Potser això és cert, nosaltres, els proveïdors de seguretat, alarmisme constant i interferir amb els equips de desenvolupament per mitigar un risc discutible és una ximpleria. Potser us tempteu a anar directament al paràgraf sobre l'acceptació de riscos (a la secció següent) i ja està. Malauradament, els components més populars són objectius per a mals actors, i per exemple, els populars... La biblioteca PyTorch va ser atacada en el passat.
"Trobat, revelat i eliminat immediatament". Un component maliciós nou triga dies a ser eliminat del registre públic. Els registres són cautelosos a l'hora d'eliminar una versió d'un component, per bé. La nostra experiència és que, un cop informat per la nostra part, el temps mitjà perquè el registre elimini la versió afectada és de 39 hores, més d'un dia i mig. Hi ha components maliciosos que es troben una setmana després del nostre informe inicial al registre abans d'eliminar-se. I en alguns casos, el component només s'elimina després que una víctima o una empresa de resposta a incidents informi d'un incident relacionat amb el component.
Què NO funciona contra components maliciosos
Qualsevol enfocament inespecífic fracassarà estrepitosament. Això és una certesa, no esteu proporcionant contramesures efectives per al risc associat a aquesta amenaça.
Tradicional SCA Les eines us informen sobre programari maliciós conegut però tenen una finestra d'exposició àmplia. A menys que realitzin detecció de programari maliciós de manera proactiva amb el bloqueig forçat de components maliciosos, no funcionen contra aquesta amenaça.
Desactivar els scripts d'instal·lació podria ajudar, però s'ha d'aplicar a tot arreu on s'hagi d'instal·lar un component. El mateix passa amb la fixació de versions, ja que les versions no es poden fixar des d'un estat inicial segur per sempre.
Assumir que els components populars reben prou atenció com per no poder ser injectats amb un comportament no desitjat en un atac a la cadena de subministrament sense una detecció gairebé instantània per evitar qualsevol dany és ingenu i arriscat. No voleu viure al límit, oi?
Si t'atures en aquest punt, aleshores acceptació de riscos és l'única cosa que pots fer: Això és un decisió que cal documentar en el vostre model d'amenaces/avaluació de riscos, incloent-hi la justificació per acceptar el risc i les seves possibles implicacions. Sensibilitzeu-ho comunicant-ho a la direcció i a altres parts rellevants. Alguns contingència es podria planificar quan s'instal·la o s'inclou un component maliciós al vostre programari, però això és difícil perquè els atacants tenen molts camins a seguir. Els detalls d'un atac a la cadena de subministrament basat en l'ús d'un component maliciós canviaran dràsticament la divulgació pública de l'incident, que probablement és obligatòria segons el marc regulador de la vostra organització. També podeu abordar controls compensatoris or risc de transferència per exemple, amb assegurança.
Tanmateix, hi ha controls que aborden l'amenaça i s'han de tenir en compte si no esteu satisfets amb l'acceptació del risc. Si us plau, continueu llegint.
Què funciona contra els atacs que utilitzen components maliciosos?
Gestió de versions sòlides
La fixació de versions amb canvis de versió controlats i informats és el camí a seguir per equilibrar la necessitat d'eliminar vulnerabilitats sense rebre programari maliciós. Però recordeu el concepte erroni número 3: la fixació de versions per si sola no és suficient per bloquejar el codi maliciós que prové de les noves versions, perquè en el futur caldrà actualitzar les versions en qualsevol dependència directa o indirecta. En aquest moment, necessiteu proves prou sòlides que no totes les versions modificades continguin programari maliciós.
Alerta anticipada
Una manera d'abordar el problema dels components maliciosos és un sistema d'alerta primerenca (anomenat aquí com a Alerta precoç de programari maliciós o MEW), on les noves versions publicades (per a components nous o existents) són analitzades per un motor de detecció, que quan es troba prou proves pot classificar la nova versió com a potencialment maliciosa.
L'automatització és essencial aquí, ja que és impossible revisar manualment tots els components nous al ritme de publicació actual. Per tant, el motor de detecció ha de combinar diverses tècniques, com ara anàlisis estàtiques, dinàmices i de capacitats, reputació d'usuaris i proves derivades de discrepàncies entre les metadades del component i el contingut del tarball, o entre el tarball i el repositori font d'on suposadament prové el component.
Hi ha un zona fosca entre el moment de la publicació i quan el motor analitza el contingut dels components, però no hauria de superar uns minuts. L'esquema es pot modificar, per exemple, esperant que s'analitzin els nous components abans de permetre que s'instal·lin i s'utilitzin en la compilació del programari. pipelines, o analitzar-los sota demanda quan sigui necessari. Un component en una versió determinada és immutable [3], per tant, només cal analitzar-lo una vegada.
L'automatització completa no és possible i cal una revisió de seguretat per a components potencialment maliciosos. Compte amb els defensors de la panacea digitalLa IA i l'aprenentatge automàtic no estan prou desenvolupats per tenir l'última paraula a l'hora de confirmar si un component sospitós té programari maliciós. És cert que l'aprenentatge automàtic juga un paper clau en el motor de detecció a l'hora de classificar el component d'entrada a partir de l'evidència bruta capturada, però un cop el component està "en quarantena", l'última paraula la té un equip de seguretat amb experiència en components maliciosos que revisa manualment. Això confirma qualsevol programari maliciós potencial o el reclassifica com a segur. I el període de temps és de l'ordre d'unes hores.
El registre informa sobre la versió/component maliciós; aleshores, el registre realitza la seva revisió per confirmar-la i procedeix a la divulgació pública i a l'eliminació del registre. Alguns registres mantenen un paquet de seguretat. L'interval de temps aquí són els dies o setmanes des de la publicació, que és el 'temps de permanència'o'finestra d'exposició' per a la majoria de components maliciosos.
És possible saber si una versió d'un component és maliciosa?
Així doncs, per a una alerta primerenca, hem de donar una resposta satisfactòria a aquesta pregunta: Com puc saber que una biblioteca o un paquet és (no) maliciós? Com puc recopilar prou proves de comportament maliciós? Possible, però difícil, ja que els adversaris utilitzen molt d'enginy per evitar la detecció. Hi ha diferents enfocaments, cadascun amb avantatges i inconvenients.
Anàlisi estàtica pot examinar totes les rutes d'execució, comprovar les tècniques utilitzades pels atacants sense executar el component i realitzar tasques de preprocessament com ara la desofuscació o el desxiframent. A mesura que els atacants intenten amagar les seves malifetes, els intents d'ofuscació són, de fet, prova de programari maliciós (però tingueu en compte que els components legítims ofusquen el codi per preservar la propietat intel·lectual, contradient "de codi obert"). Només una minoria d'atacs altament sofisticats amb una forta ofuscació necessiten un sandboxing, però aquesta forta ofuscació és un signe revelador de malícia. Tingueu en compte que els atacs convencionals SAST Les eines es van dissenyar per a vulnerabilitats no intencionades, no per a intencions malicioses com les portes del darrere.
Anàlisi dinàmica executa el component i examina la resposta instrumentant el temps d'execució, normalment proporcionant un entorn de prova. El comportament maliciós activat en determinades condicions pot passar desapercebut: tingueu en compte que el programari maliciós pot utilitzar tècniques d'evasió com ara Virtualització/Evasió de Sandbox s'activi només quan no estigui sota escrutini, i també un signe revelador d'activitat maliciosa per a qualsevol motor d'anàlisi estàtica.
Anàlisi de capacitats considera què fa el component: on es connecta, a quins fitxers accedeix, quines ordres o programes s'executen, el terminal o dispositiu d'E/S que s'executa o quines crides de sistema s'invoquen. Aquesta empremta digital del comportament es podria comparar (per a un component existent) entre versions, de manera que quan es detecta un comportament inesperat, aquesta evidència podria suscitar sospites d'una possible activitat maliciosa injectada a la nova versió. Aquest enfocament segueix els passos de triatge que segueixen els analistes de seguretat quan s'enfronten a un possible programari maliciós: una inspecció mitjançant cordes o eines similars. Aquest mètode detecta comportaments maliciosos independentment de les condicions desencadenants i funciona quan no hi ha codi font disponible.
Anàlisi del context recopila informació sobre com es va publicar el component i per qui. Les campanyes dels malfactors sovint utilitzen un o més comptes d'usuari nous que no estan subjectes a cap procés de verificació estricte. El seguiment de l'activitat passada pot donar informació sobre l'usuari subjacent, principalment per detectar anomalies que poden suggerir un possible compromís. La reputació és molt difícil de guanyar i molt fàcil de perdre! Un usuari sense activitat passada és neutral, però el karma persegueix els malfactors. Els hacktivistes o usuaris normals a qui se'ls roben les credencials de publicació s'han de rastrejar acuradament.
Una altra informació contextual és qualsevol discrepància entre el repositori font suposadament utilitzat per crear el tarball del component i el contingut del tarball en si. I també seguir bones pràctiques, com ara crear etiquetes o versions al repositori font que coincideixin amb les versions del component publicades al registre públic. Quan el repositori font en un lloc concret commit està etiquetat amb llançament, i de sobte una versió no la segueix, això per si sol ja és una prova sòlida que el component podria estar contaminat: l'actor malintencionat podria haver compromès el compte utilitzat per publicar el component, però no té permisos d'escriptura al repositori de codi font). Molts atacs es detecten rutinàriament utilitzant aquestes regles: per exemple, el Atac de Ledger es podrien detectar fàcilment en aquest sentit. L'anàlisi del context, per tant, identifica aquestes anomalies en el procés de publicació.
Tallafocs de dependències
Un enfocament diferent és tenir una llista blanca completa de components per a tots els gràfics de dependències utilitzats al vostre programari, de manera que en qualsevol compilació pipeline executat a la vostra organització només es poden instal·lar i utilitzar versions de components aprovades. El "firewall"s'aplica mitjançant un registre intern on es serveixen els fitxers tar de les versions de components permeses (en memòria cau o mitjançant proxy). Tingueu en compte que cap llista blanca no funcionarà tret que tingueu la tecnologia per classificar qualsevol versió nova com a raonablement segura perquè es pugui afegir a la llista blanca.
Tingueu en compte que l'alerta primerenca (detecció ràpida tan aviat com sigui possible després de la publicació de la nova versió) s'ha de combinar amb alguna manera d'utilitzar aquesta informació de manera proactiva per bloquejar el component que afecta la compilació. pipelines o les màquines dels desenvolupadors [4]Anomenem això “tallafocs de dependències": un mecanisme de quarantena per protegir les compilacions automatitzades de paquets maliciosos. Els paquets interns i els registres d'imatges són bons per aïllar les organitzacions del mal extern, però calen proves prou sòlides per fer que la quarantena sigui efectiva.
Sandboxing en temps d'execució
Un enfocament alternatiu per a la detecció en el moment de la publicació és analitzar el comportament en temps d'execució. La idea és capturar el comportament esperat del programari i detectar (o bloquejar) qualsevol anomalia que es trobi. Aquesta línia d'acció té el problema d'haver d'instrumentar el temps d'execució per a la supervisió o el bloqueig, i és una idea prometedora que s'afegirà a l'arsenal de mecanismes de protecció contra la plaga de components maliciosos.
Establir una estratègia integral
L'estratègia recomanada ha de combinar diferents tècniques en el procés de desenvolupament de programari, prenent el control de les actualitzacions de versions per bloquejar els components maliciosos entrants. Hem d'adaptar-nos a la fixació de versions per evitar la infecció automàtica amb l'actualització de versions per obtenir solucions per a les vulnerabilitats importants; una avaluació ràpida i eficient de les dependències directes i indirectes durant les actualitzacions de versions per tenir prou proves que no estan plenes de programari maliciós. Les compilacions de programari que depenen de components maliciosos coneguts s'han de bloquejar. I tot s'ha d'aplicar.
Feu servir la fixació de versions, sempre que sigui possible, ja que fa que les compilacions siguin més reproduïbles. Fixació de versions amb canvis de versió controlats i aprovats manualmenti assistit per tecnologia auxiliar, hauria d'avaluar si l'actualització porta programari maliciós o trenca el programari, i conciliar l'actualització per solucionar vulnerabilitats amb evitar infeccions de programari maliciós. Les eines poden ajudar aquí, (1) prioritzant quines vulnerabilitats són realment importants (accessibles i explotables, amb un alt risc de ser objectiu d'atacants), (2) seleccionant les versions de destinació que siguin compatibles amb els usos actuals dels components i que no trenquin el programari, (3) triant versions de destinació que no continguin comportament maliciós i (4) fent que l'actualització de versions per a dependències directes i indirectes sigui molt senzilla, suggerint canvis als fitxers de manifest que es puguin aprovar ràpidament. El pas (3) necessita informació específica sobre els components maliciosos el més proper possible a la seva data de publicació.
Aquest procés d'actualització de dependències ha de ser aplicat i verificat en tots els llocs. El procés ha d'estar documentat i totes les parts implicades han de rebre formació, ja que sovint el desenvolupament i la compilació/desplegament de programari s'externalitzen. El/La CI/CD pipelines'hauria de modificar en conseqüència, de manera que l'automatització no permeti que una dependència indirecta maliciosa s'infiltri a la compilació: guardrails El mètode recomanat és bloquejar la compilació si hi ha prou evidència de possible programari maliciós en una dependència.
Si la vostra organització té un registre intern que actua com a intermediari de seguretat per contenir les versions de components permeses, heu d'obtenir informació sobre components maliciosos (a més d'altres criteris) per revisar un component sol·licitat abans d'afegir-lo a la llista de permesos.
Consumir programari de codi obert amb seguretat no és fàcil, i s'ha de tenir plenament en compte el factor programari maliciós, amb un esforç similar en la gestió de vulnerabilitats.
Una nota final: Procedència de la font, en forma d'atestats de programari, generats en el moment de la compilació del component, és una altra peça clau en l'esforç per rastrejar l'artefacte (arxiu tarball del component) amb les fonts i el procés de compilació que el va produir. Cal tenir en compte que aquest enllaç entre la instantània d'origen + l'entorn de compilació i l'artefacte de programari associat (signat pel sistema de compilació de confiança) no impedeix per se que el component no contingui comportaments maliciosos, però dificulta que els delinqüents injectin programari maliciós. I fer que la validació de la procedència sigui un requisit comú per consumir components de codi obert trigarà molt de temps, i només afegit recentment a NPMFer que aquests sistemes de compilació i implementació de confiança siguin a prova de manipulacions, o permetre la detecció de qualsevol manipulació en la compilació és una altra història, fora de l'abast d'aquesta publicació.
Altres lectures
El següent episodi Paquets maliciosos de codi obert: l'enfocament Xygeni presentarem l'estratègia que seguim a Xygeni per a la nostra Alerta precoç de programari maliciós Sistema (MEW). Escanegen les noves versions de paquets als registres públics de paquets i imatges i se n'obtenen proves mitjançant una combinació d'anàlisi estàtica, dinàmica, de capacitats i contextual. Les proves, combinades amb la reputació de l'usuari i l'historial de canvis als repositoris de codi font, permeten una classificació totalment automatitzada d'un component en categories d'alt risc i probablement malicioses. El sistema aprèn de les proves anteriors recollides dels paquets per reduir els falsos positius al mínim.
Les organitzacions subscrites reben una notificació d'advertència per als components que utilitzen, directament o indirectament, quan es categoritza una versió maliciosa. A continuació, els nostres analistes fan una anàlisi manual que confirma o rebutja la classificació. En el cas del programari maliciós confirmat, es notifica al registre públic perquè pugui realitzar la seva pròpia anàlisi i, normalment, eliminar la versió maliciosa o prendre mesures addicionals, com ara bloquejar o eliminar el compte d'usuari en qüestió.
Explicarem com estem ajudant NPM, PyPI, GitHub i altres infraestructures clau de l'ecosistema de codi obert a reduir el temps de permanència que un nou component maliciós publicat roman actiu fins que es confirma que és programari maliciós i s'elimina del registre. I com les organitzacions es poden beneficiar del sistema MEW per tenir una protecció molt millor contra els atacs a la cadena de subministrament de programari que impliquen components de codi obert.
- [1] De totes maneres, els usuaris del component han de comprovar si el fitxer tar del component està emmagatzemat a la memòria cau o registrat en algun lloc, per exemple en un registre intern, per tal d'eradicar el problema.
- [2] El component empaquetat inclou un manifest que declara el seu contingut i metadades, el codi font o compilat, els scripts d'instal·lació i elements addicionals com ara conjunts de proves, segons un format d'empaquetament i normalment en forma comprimida. Això s'anomena "arxiu tar del component".
- [3] Fins i tot si l'actor maliciós pot modificar un component publicat a causa d'una bretxa al registre mateix, un resum criptogràfic senzill pot detectar qualsevol canvi al fitxer tar després que s'hagi fet l'anàlisi.
- [4] Recordeu que alguns components maliciosos s'executen en el moment de la instal·lació, de manera que poden afectar els nodes de desenvolupador que executen sense voler "npm install X" amb X com a component maliciós.
