Este é o terceiro episodio dunha serie de artigos sobre o tipo máis frecuente de ataques á cadea de subministración de software: aqueles que abusan dun rexistro público de open-source compoñentes de software. Despois de analizar no episodio anterior "Anatomía dos paquetes maliciosos: cales son as tendencias?"Ao ver como os malos actores inxectan comportamento malicioso en compoñentes publicados novos ou existentes, estamos listos para poñernos as nosas chaquetas de extinción de incendios e examinar como podemos bloquear con éxito o software malicioso distribuído desta maneira ou, alternativamente, xestionar un incidente cibernético potencialmente grave porque adoptamos o enfoque incorrecto."
A maioría dos profesionais con coñecementos de seguridade teñen ideas sobre como xestionar esta ameaza. Escoitamos aos xestores de seguridade dicir sen dubidar que SCA As ferramentas xa che indican cando unha versión dun paquete é malware. Ou que dependen de compoñentes de software coñecidos e altamente revisados, onde calquera malware sería detectado e eliminado rapidamente. Usan versións menores/parches abertos para obter automaticamente correccións de vulnerabilidades, e esa é a forma correcta e recomendada de reducir o risco nas dependencias de código aberto, seguindo o "parchear cedo, parchear a miúdo”Principio.
Neste episodio, revisaremos por que estas ideas son erróneas e como estes conceptos erróneos contribúen á popularidade deste mecanismo de ataque e ao risco abrumador que están a experimentar as organizacións. Remataremos co que funciona e cal é o esforzo e os recursos implicados.
Malentendidos comúns
Durante a nosa viaxe pola seguridade do software, vimos como evolucionaban as técnicas de ataque e unha ampla gama de ideas por parte de persoas preocupadas pola seguridade. As organizacións adoitan malinterpretar o que funciona contra esta ameaza, polo que primeiro examinaremos o que non funciona, condensado na seguinte lista, non exhaustiva, de conceptos erróneos.
Idea equivocada # 1: SCA as ferramentas xa informan de compoñentes maliciosos
De feito! Pero despois do feito... Cando probablemente sexa demasiado tarde se o elemento se usou nunha compilación de software e os malos actores xa gañaron un punto de apoio nun desenvolvedor ou CI/CD servidor. É posible que se extraesen segredos, que se descargase e instalase software malicioso adicional e que o adversario se movese lateralmente e xa obtivese acceso a outro lugar.
Análise da composición do software (SCA) foron deseñadas para identificar posibles vulnerabilidades coñecidas. As ferramentas modernas fan un gran traballo aumentando a relación sinal-ruído, determinando se a vulnerabilidade é realmente alcanzable ou explotable. Pero son inútiles contra o novo software malicioso. Pense nun compoñente malicioso como unha vulnerabilidade de día cero: só cando se detecta o seu comportamento malicioso, o compoñente é notificado ao rexistro de almacenamento, que despois dunha revisión por parte dun equipo de seguridade é confirmado como malicioso e eliminado do rexistro. [1].
Nese momento, o mundo (incluíndo SCAs) sabe que instalar ou usar o compoñente (ou algunha versión dun compoñente existente) non é algo bo. Pero isto ocorre cando o compoñente non está dispoñible no rexistroSaber que teño vulnerabilidades en compoñentes de terceiros, ou mesmo en compoñentes que o rexistro categorizou como maliciosos, é bo, pero por desgraza SCA ou as ferramentas de auditoría comúns non axudan neste contexto. A menos que SCAA ferramenta /audit pode saber de antemán que un compoñente é malicioso antes de usalo na túa organización.
Lembra que calquera solución contra compoñentes de código aberto maliciosos debe detectalos. sobre a marcha, entre cando o compoñente se publica no rexistro e cando o compoñente (versión) se usa por primeira vez na súa organización. E iso inclúe os compoñentes transitivos.
Idea errónea nº 2: Controlar os scripts de instalación no momento da compilación impide o comportamento malicioso dos compoñentes de código aberto
Varios xestores de paquetes ofrecen a capacidade de executar scripts (incluídos no ficheiro tar do compoñente [2]), por razóns lexítimas, como compilar elementos necesarios en diferentes plataformas, xerar código ou executar probas, e todos deberiamos saber que poden ser abusados por malos actores se se inclúen scripts maliciosos no tarball ou se o atacante pode facer que un script malicioso se execute en lugar do bo.
Sabendo isto, podemos configurar o xestor de paquetes para ignorar os scripts. Por exemplo, con NPM o –ignorar-scripts bandeira (ou unha propiedade de configuración no .npmrc ficheiro) omite os scripts durante a instalación. Isto pode producir algúns problemas porque executar scripts é común en moitos ecosistemas: algúns xestores de paquetes nin sequera permiten desactivar a execución de scripts (pista: indicación "Que xestores de paquetes non permiten desactivar a execución de scripts de instalación?"na túa IA favorita). Pero isto non protexe en xeral (temos que facer cumprir que a configuración de desactivación de omisión estea en todas partes).
E cando o comportamento malicioso non se atopa nos scripts de instalación senón no software que se executa en tempo de execución, esta opción por si soa non nos protexe.
Idea errónea nº 3: A fixación de versións impide que se instalen compoñentes maliciosos
Hai un compromiso entre aplicar parches cedo e a miúdo con versións abertas (permitindo que o xestor de paquetes instale automaticamente novas actualizacións cando estean dispoñibles para correccións de seguridade) e fixación de versións (tendo todas as dependencias directas e transitivas para un software nunha versión fixa). Os principios de seguridade son teimosos e ás veces contraditorios, como ocorre con "parchear cedo, parchear a miúdo" e "A mellora non se debe tomar á lixeira"Algúns xestores de paquetes realizan actualizacións automáticas con intervalos de servidores do xeito recomendado. Xenial se tamén queres recibir as actualizacións maliciosas! Si, os compoñentes deben actualizarse para recibir correccións de seguranza que pechen as vulnerabilidades canto antes, pero... nunca deixes que o xestor de paquetes o faga automaticamente.
Idea errónea nº 4: Empregar compoñentes de confianza é seguro. Calquera versión maliciosa sería detectada, divulgada e eliminada de inmediato.
Por que se confia nun compoñente? Posiblemente porque é moi popular, con moitos ollos á procura de vulnerabilidades, un gran número de colaboradores para o mantemento e varios mantenedores principais que revisan con dilixencia todo. pull requestsA realidade é ben diferente. Algúns compoñentes esenciais son mantidos por un único desenvolvedor non remunerado. Os marcos de traballo amplamente utilizados teñen uns poucos colaboradores habituais, cun número decrecente en rápido commits por responsable de mantemento (os proxectos populares teñen unha longa cola de colaboradores que realizan algunhas tarefas pasivas) commit e nunca volven). E abundan os proxectos populares cun só responsable de mantemento.
Imaxínate dicindo "Ah, estamos a usar Spring Boot / Angular / React / PyTorch / imaxes base oficiais de Docker, polo que o risco do que falas é bastante baixo." Quizais sexa certo, nós, os provedores de seguridade, alarmismo constante e interferir cos equipos de desenvolvemento para mitigar un risco discutible é unha parvada. Pode que teñas a tentación de saltar ao parágrafo de aceptación de riscos (na seguinte sección) e listo. Desafortunadamente, os compoñentes máis populares son obxectivos para os malos actores e, por exemplo, o popular A biblioteca PyTorch foi atacada no pasado.
"Atopado, divulgado e retirado de inmediato". Un novo compoñente malicioso tarda días en eliminarse do rexistro público. Os rexistros son cautelosos á hora de eliminar unha versión dun compoñente, para ben. A nosa experiencia é que, unha vez que o noso informe é recibido, o tempo medio para que o rexistro elimine a versión afectada é de 39 horas, máis dun día e medio. Hai compoñentes maliciosos que levan unha semana desde o noso informe inicial no rexistro antes de ser eliminados. E nalgúns casos, o compoñente só se elimina despois de que unha vítima ou unha empresa de resposta a incidentes informe dun incidente relacionado co compoñente.
O que NON funciona contra compoñentes maliciosos
Calquera enfoque inespecífico fracasará estrepitosamente. Isto é unha certeza, non estás a proporcionar contramedidas eficaces para o risco asociado a esta ameaza.
Tradicional SCA As ferramentas infórmanche sobre software malicioso coñecido, pero teñen unha ampla xanela de exposición. A menos que realicen de forma proactiva a detección de software malicioso con bloqueo forzado de compoñentes maliciosos, non funcionan contra esta ameaza.
Desactivar os scripts de instalación podería axudar, pero debe aplicarse en todos os lugares onde se precise instalar un compoñente. O mesmo ocorre coa fixación de versións, xa que as versións non se poden fixar desde un estado inicial seguro para sempre.
Asumir que os compoñentes populares reciben suficiente atención como para non poder ser inxectados con comportamentos non desexados nun ataque á cadea de subministración sen unha detección case instantánea para evitar calquera dano é inxenuo e arriscado. Non queres vivir no límite, non si?
Se paras neste punto, entón aceptación de riscos é o único que podes facer: isto é un decisión que debe documentarse no seu modelo de ameazas/avaliación de riscos, incluíndo a xustificación para aceptar o risco e as súas posibles implicacións. Sensibilice comunicándoo á dirección e a outras partes relevantes. Algúns continxencia podería planificarse cando se instala ou inclúe un compoñente malicioso no software, pero isto é difícil porque os atacantes teñen moitos camiños que seguir. Os detalles dun ataque á cadea de subministración baseado no uso dun compoñente malicioso cambiarán drasticamente a divulgación pública do incidente, que probablemente sexa obrigatoria segundo o marco regulatorio da súa organización. Tamén pode abordar controis compensatorios or risco de transferencia por exemplo, con seguro.
Non obstante, existen controis que abordan a ameaza e que deberías ter en conta se non estás satisfeito coa aceptación do risco. Continúa lendo.
Que funciona contra os ataques que usan compoñentes maliciosos?
Manexo de versións sólidas
A fixación de versións con aumentos de versión controlados e informados é o camiño a seguir para equilibrar a necesidade de eliminar vulnerabilidades sen recibir software malicioso. Pero lembra o concepto erróneo número 3: a fixación de versións por si soa non abonda para bloquear o código malicioso procedente de novas versións, porque no futuro terás que actualizar as versións en calquera dependencia directa ou indirecta. Nese momento necesitas probas o suficientemente sólidas como para que todas as versións modificadas non conteñan software malicioso.
Alerta anticipada
Unha maneira de abordar o problema dos compoñentes maliciosos é un sistema de alerta temperá (denominado aquí Alerta temperá de software malicioso ou MEW), onde as novas versións publicadas (para compoñentes novos ou existentes) son analizadas por un motor de detección que, cando se atopan probas suficientes, pode clasificar a nova versión como potencialmente maliciosa.
A automatización é esencial aquí, xa que é imposible revisar manualmente todos os novos compoñentes ao ritmo de publicación actual. Polo tanto, o motor de detección necesita combinar unha variedade de técnicas, incluíndo quizais análises estáticas, dinámicas e de capacidades, reputación do usuario e evidencias procedentes de discrepancias entre os metadatos do compoñente e o contido do tarball, ou entre o tarball e o repositorio fonte de onde supostamente provén o compoñente.
hai un zona escura entre o momento da publicación e cando o motor analiza o contido dos compoñentes, pero non debe exceder uns minutos. O esquema pódese modificar, por exemplo, agardando a que se analicen os novos compoñentes antes de permitir que se instalen e se usen na compilación do software. pipelines, ou analizalos baixo demanda cando sexa necesario. Un compoñente nunha versión determinada é inmutable [3], polo que só precisa ser analizado unha vez.
Non é posible a automatización total e é necesaria unha revisión de seguranza para detectar compoñentes potencialmente maliciosos. Coidado cos defensores da panacea dixitalA IA e a aprendizaxe automática non están o suficientemente desenvolvidas como para ter a última palabra á hora de confirmar se un compoñente sospeitoso ten malware. É certo que a aprendizaxe automática xoga un papel fundamental no motor de detección á hora de clasificar o compoñente de entrada a partir da evidencia bruta capturada, pero unha vez que o compoñente está en "corentena", a última palabra recae na revisión manual por parte dun equipo de seguridade con experiencia en compoñentes maliciosos. Isto confirma calquera posible malware ou o reclasifícao como seguro. E o período de tempo é do rango de horas.
O rexistro informa sobre a versión/compoñente malicioso; o rexistro entón realiza a súa revisión para confirmar e procede á divulgación pública e á eliminación do rexistro. Algúns rexistros manteñen un paquete de almacenamento de seguridade. O intervalo de tempo aquí son os días ou semanas desde a publicación, que é o 'tempo de permanencia"ou"xanela de exposición' para a maioría dos compoñentes maliciosos.
É posible saber se unha versión dun compoñente é maliciosa?
Entón, para unha alerta temperá, precisamos dar unha resposta satisfactoria a esta pregunta: como podo saber que unha biblioteca ou un paquete é (non) malicioso? Como reunir probas suficientes de comportamento malicioso? Posible, pero difícil, xa que os adversarios empregan moito enxeño para evitar a detección. Existen diferentes enfoques, cada un con vantaxes e desvantaxes.
Análise estática pode examinar todas as rutas de execución, comprobar as técnicas empregadas polos atacantes sen executar o compoñente e realizar tarefas de preprocesamento como a desofuscación ou o desciframento. Mentres os atacantes tentan ocultar as súas malicias, os intentos de ofuscación son, de feito, proba de software malicioso (pero teña en conta que os compoñentes lexítimos ofuscan o código para preservar a propiedade intelectual, o que contradice "de código aberto"). Só unha minoría de ataques altamente sofisticados con ofuscación forte precisan de sandboxing, pero unha ofuscación tan forte é un sinal revelador de maldade. Teña en conta que os ataques convencionais SAST As ferramentas foron deseñadas para vulnerabilidades non intencionadas, non para intencións maliciosas como as portas traseiras.
Análise dinámica executa o compoñente e examina a resposta instrumentando o tempo de execución, normalmente proporcionando un ambiente de probas. O comportamento malicioso desencadeado baixo certas condicións pode pasar desapercibido: teña en conta que o software malicioso pode usar técnicas de evasión como Virtualización/Evasión de Sandbox para activarse só cando non estea baixo escrutinio e tamén un sinal revelador de actividade maliciosa para calquera motor de análise estática.
Análise de capacidades considera o que fai o compoñente: onde se conecta, a que ficheiros accede, que comandos ou programas se executan, as entradas/saídas do terminal ou dispositivo que se realizan ou que chamadas de sistema se invocan. Esta pegada dixital do comportamento podería compararse (para un compoñente existente) entre versións, de xeito que cando se detecta un comportamento inesperado, esa evidencia podería suscitar sospeitas dunha posible actividade maliciosa inxectada na nova versión. Esta estratexia segue os pasos de selección que seguen os analistas de seguridade cando se enfrontan a un posible software malicioso: unha inspección mediante cordas ou ferramentas similares. Esta estratexia detecta comportamentos maliciosos independentemente das condicións de activación e funciona cando non hai código fonte dispoñible.
Análise do contexto recompila información sobre como se publicou o compoñente e por quen. As campañas dos malos actores adoitan usar unha ou varias contas de usuario novas que non están suxeitas a ningún proceso de verificación estrito. O seguimento da actividade pasada pode proporcionar información sobre o usuario subxacente, principalmente para detectar anomalías que poden suxerir un posible compromiso. A reputación é moi difícil de gañar e moi fácil de perder! Un usuario sen actividade pasada é neutral, pero o karma persegue aos malévolos. Os hacktivistas ou usuarios normais aos que lles rouban as credenciais de publicación deben ser rastrexados coidadosamente.
Outra información contextual é calquera discrepancia entre o repositorio de orixe supostamente usado para crear o ficheiro tar do compoñente e o contido do propio ficheiro tar. E tamén seguir boas prácticas, como crear etiquetas ou versións no repositorio de orixe que coincidan coas versións do compoñente publicadas no rexistro público. Cando o repositorio de orixe nun determinado commit está etiquetado con release e, de súpeto, unha versión non a segue, iso por si só xa é unha forte evidencia de que o compoñente podería estar contaminado: o malfeitor podería ter comprometido a conta utilizada para publicar o compoñente, pero non ten permisos de escritura no repositorio de código fonte). Moitos ataques detéctanse habitualmente usando estas regras: por exemplo, o Ataque de Ledger podería detectarse facilmente neste sentido. Polo tanto, a análise contextual identifica tales anomalías no proceso de publicación.
Firewall de dependencias
Unha estratexia diferente é ter unha lista branca completa de compoñentes para todos os gráficos de dependencias empregados no software, de xeito que en calquera compilación pipeline executado na súa organización só se poden instalar e usar versións de compoñentes aprobadas. O "cortalumes"aplícase mediante un rexistro interno onde se serven os ficheiros tar das versións de compoñentes permitidas (en caché ou en proxy). Ten en conta que calquera lista branca non funcionará a menos que teñas a tecnoloxía para clasificar calquera nova versión como razoablemente segura para que se poida engadir á lista branca.
Ten en conta que a alerta temperá (detección rápida canto antes despois da publicación da nova versión) debe combinarse con algunha forma de usar esa información de forma proactiva para bloquear o compoñente que afecta á compilación. pipelines ou as máquinas dos desenvolvedores [4]A isto chamámoslle “cortafuegos de dependencias": un mecanismo de corentena para protexer as compilacións automatizadas de paquetes maliciosos. Os paquetes internos e os rexistros de imaxes son bos para illar as organizacións do mal externo, pero son necesarias probas o suficientemente sólidas para que a corentena sexa efectiva.
Zona de probas en tempo de execución
Unha alternativa para a detección no momento da publicación é analizar o comportamento no tempo de execución. A idea é capturar o comportamento esperado do software e detectar (ou bloquear) calquera anomalía que se atope. Esta liña de acción ten o problema de ter que instrumentar o tempo de execución para a monitorización ou o bloqueo, e é unha idea prometedora que se engadirá ao arsenal de mecanismos de protección contra a praga de compoñentes maliciosos.
Establecemento dunha estratexia integral
A estratexia recomendada precisa combinar diferentes técnicas no proceso de desenvolvemento de software, tomando o control das actualizacións de versións para bloquear os compoñentes maliciosos entrantes. Debemos adaptarnos á fixación de versións para evitar infeccións automáticas coa actualización de versións para obter correccións para as vulnerabilidades importantes; unha avaliación rápida e eficiente das dependencias directas e indirectas durante as actualizacións de versións para ter probas suficientes de que non están cheas de software malicioso. As compilacións de software que dependen de compoñentes maliciosos coñecidos deben ser bloqueadas. E todo debe ser aplicado.
Usa o fixamento de versións, sempre que sexa posible, xa que fai que as compilacións sexan máis reproducibles. Fixación de versións con aumentos de versión controlados e aprobados manualmentee asistido por tecnoloxía auxiliar, debería avaliar se a actualización trae software malicioso ou dana o software e conciliar a actualización para corrixir vulnerabilidades coa prevención de infeccións por malware. As ferramentas poden axudar neste caso, (1) priorizando as vulnerabilidades que realmente importan (alcanzables e explotables, cun alto risco de seren obxectivo de atacantes), (2) seleccionando as versións de destino que sexan compatibles cos usos actuais dos compoñentes e que non danen o software, (3) escollendo versións de destino que non conteñan comportamento malicioso e (4) facendo que a actualización da versión para dependencias directas e indirectas sexa moi sinxela, suxerindo cambios nos ficheiros de manifesto que se poidan aprobar rapidamente. O paso (3) necesita información específica sobre os compoñentes maliciosos o máis preto posible da súa data de publicación.
Este proceso de actualización de dependencias debe ser aplicado verificado en todos os lugares. O proceso debe estar documentado e todas as partes implicadas deben recibir formación, xa que a miúdo o desenvolvemento e a compilación/implementación de software externalizanse. O CI/CD pipelines debería modificarse en consecuencia, para que a automatización non permita que unha dependencia indirecta maliciosa se introduza na compilación: guardrails Recoméndase bloquear a compilación se hai probas suficientes de posible software malicioso nunha dependencia.
Se a súa organización ten un rexistro interno que actúa como proxy de seguranza para gardar as versións de compoñentes permitidas, debe obter información sobre os compoñentes maliciosos (ademais doutros criterios) para revisar un compoñente solicitado antes de engadilo á lista de permitidos.
Consumir software de código aberto con seguridade non é doado, e o factor malware debe terse en conta plenamente, cun esforzo similar na xestión de vulnerabilidades.
Unha nota final: Procedencia da fonte, en forma de atestacións de software, xeradas no momento da compilación do compoñente, é outra peza clave no esforzo por rastrexar o artefacto (arquivo tar do compoñente) coas fontes e o proceso de compilación que o produciron. Teña en conta que esta ligazón entre a instantánea da fonte + o ambiente de compilación e o artefacto de software asociado (asinado polo sistema de compilación de confianza) non impide per se que o compoñente non conteña comportamento malicioso, pero dificulta que os malfeitores inxecten software malicioso. E facer da validación da procedencia un requisito común para consumir compoñentes de código aberto levará moito tempo e só engadido recentemente a NPMFacer que eses sistemas de compilación e implementación de confianza sexan a proba de manipulacións ou permitir a detección de calquera manipulación na compilación é unha historia diferente, fóra do alcance desta publicación.
Outras lecturas
O seguinte episodio Paquetes maliciosos de código aberto: o enfoque Xygeni presentaremos a estratexia que seguimos en Xygeni para o noso Alerta temperá de software malicioso Sistema (MEW). As novas versións de paquetes nos rexistros públicos de paquetes e imaxes son escaneadas e as evidencias obtéñense mediante unha combinación de análises estáticas, dinámicas, de capacidades e contextuais. A evidencia, combinada coa reputación do usuario e o historial de cambios nos repositorios de código fonte, permite unha clasificación totalmente automatizada dun compoñente en categorías de alto risco e probablemente maliciosas. O sistema aprende das evidencias pasadas recollidas dos paquetes para reducir os falsos positivos ao mínimo.
As organizacións subscritas reciben unha notificación de aviso para os compoñentes que están a usar, directa ou indirectamente, cando se categoriza unha versión maliciosa. Despois, os nosos analistas realizan unha análise manual que confirma ou rexeita a clasificación. No caso do software malicioso confirmado, o rexistro público recibe unha notificación para que poida realizar a súa propia análise e, normalmente, eliminar a versión maliciosa ou realizar accións adicionais, como bloquear ou eliminar a conta de usuario en cuestión.
Explicaremos como axudamos a NPM, PyPI, GitHub e outras infraestruturas clave no ecosistema de código aberto a reducir o tempo de permanencia dun novo compoñente malicioso publicado ata que se confirma que é malware e se elimina do rexistro. E como as organizacións poden beneficiarse do sistema MEW para ter unha protección moito mellor contra os ataques da cadea de subministración de software que impliquen compoñentes de código aberto.
- [1] De todos os xeitos, os usuarios do compoñente deben comprobar se o ficheiro tar do compoñente está almacenado na caché ou rexistrado nalgún lugar, por exemplo nun rexistro interno, para erradicar o problema.
- [2] O compoñente empaquetado inclúe un manifesto que declara o seu contido e metadatos, código fonte ou compilado, scripts de instalación e elementos adicionais como conxuntos de probas, segundo un formato de empaquetado e normalmente en forma comprimida. Isto chámase "tarball do compoñente".
- [3] Mesmo se o actor malicioso pode modificar un compoñente publicado debido a unha violación no propio rexistro, un resumo criptográfico simple pode detectar calquera cambio no ficheiro tar despois de que se realice a análise.
- [4] Lembra que algúns compoñentes maliciosos execútanse no momento da instalación, polo que poden afectar aos nodos de desenvolvedor que executen sen sabelo "npm install X" con X como compoñente malicioso.
