Casa > Cyber ​​Notizie > Arch Linux AUR Repository trovato per contenere malware
CYBER NEWS

Arch Linux AUR Repository rilevata la presenza di malware

Il repository software user-mantenuto Arch Linux chiamato AUR è stato trovato per ospitare il malware. La scoperta è stata fatta dopo un cambiamento in una delle istruzioni per l'installazione del pacchetto è stata fatta. Questo è ancora un altro episodio che mette in mostra che gli utenti Linux non dovrebbero fidarsi esplicitamente repository utente controllato.

AUR User-Mantenuto Arch Linux Repository contaminato da malware




Gli utenti di Linux di tutte le distribuzioni hanno ricevuto un importante monito a non fidarsi esplicitamente repository software user-run dopo l'ultimo incidente relativi a Arch Linux. user-mantenuta del progetto pacchetti AUR (che sta per “Arch User Repository”) sono stati trovati per ospitare codice malware in diversi casi. Fortunatamente un analisi del codice è stato in grado di scoprire le modifiche in tempo utile.

Gli spettacoli di indagine di sicurezza che mostra che un utente malintenzionato con il nick name xeactor modificato nel mese di giugno 7 un pacchetto orfano (software senza un mantenitore attivo) detto acroread. I cambiamenti inclusi uno script ricciolo che scarica e esegue uno script da un sito remoto. Questo installa un software persistente che riconfigura systemd per avviare periodicamente. Mentre sembra che essi non sono una seria minaccia per la sicurezza degli host infettati, gli script possono essere manipolati in qualsiasi momento per includere codice arbitrario. altri due pacchetti sono stati modificati nella stessa maniera.

Story correlati: Gentoo Linux GitHub Hacked tramite password guessing

A seguito della scoperta sono stati rimossi tutti i casi pericolosi e l'account utente sospeso. L'indagine rivela che gli script eseguiti incluso un i dati di raccolta componente che recupera le seguenti informazioni:

  • ID macchina.
  • L'uscita di -a uname.
  • Informazioni CPU.
  • Pacman (utilità gestione dei pacchetti) Informazioni.
  • L'uscita di systemctl list-unità.

Le informazioni raccolte doveva essere trasferita a un documento Pastebin. Il team ha scoperto che AUR gli script contenevano la chiave API privata che dimostra che questo è stato probabilmente fatto da un di hacker inesperti. Lo scopo del sistema di informazioni rimane sconosciuto.

Aggiornamento agosto 2018 – Pacchetti Malware Analysis

Come accennato prima abbiamo aggiornato l'articolo con le nuove informazioni sugli script e dei loro effetti sul sistema di destinazione. Siamo stati in grado di ottenere informazioni dettagliate sugli script’ operazione.

Lo script di distribuzione iniziale è stata rilevata la presenza di un file di configurazione di systemd che aggiunge una presenza persistente sul computer. Questo rende il servizio di init di avviare automaticamente lo script ogni volta che il computer viene avviato. E 'programmato per scaricare il scaricare lo script che scarica ed esegue un file dannoso.

Si chiama script di upload che chiama diversi comandi che raccolgono i seguenti dati:

  • ID macchina
  • dati
  • Informazioni di sistema
  • Informazioni sul pacchetto
  • Informazioni moduli del sistema

Queste informazioni vengono poi riferito al conto on-line Pastebin.




Il lista confermata di pacchetti interessati comprende le seguenti voci AUR:

  • acroread 9.5.5-8
  • Balz 1.20-3
  • cancello minatore 8.1-2

Ci sono diverse ipotesi che sono attualmente considerati come possibili. Un utente reddit (xanaxdroid_) menzionata in linea che “xeactor” ha pubblicato diversi pacchetti criptovaluta minatore che dimostra che l'infezione con loro è stato un passo successivo probabile. Le informazioni di sistema ottenuto può essere utilizzato per scegliere un esempio minatore generica che sarebbe compatibile con la maggior parte degli host infettati. L'altra idea è che il nick name appartiene ad un gruppo di hacker che possono indirizzare gli host infettati con ransomware o altri virus avanzate.

Se gli utenti Linux utilizzano Arch Linux che dovrebbe ricontrollare se qualsiasi repository utente-sostenuto che usano sono affidabili. Questo spettacolo incidente ancora una volta che la sicurezza non può essere garantita. Un commento fatto da Giancarlo Razzolini (un utente Arch Linux di fiducia) si legge che fidarsi esplicitamente AUR e l'utilizzo di applicazioni helper non è una buona pratica di sicurezza. In risposta alla mailing list annunciato che postato la seguente risposta:

Sono sorpreso che
questo tipo di sciocco acquisizione del pacchetto e l'introduzione di malware non accade più spesso.

Questo è il motivo per cui insistiamo agli utenti di scaricare sempre il PKGBUILD da AUR, ispezionarla e
costruire da soli. Helpers che fanno tutto automaticamente e gli utenti che non pagano
Attenzione, *si hanno problemi *. Si dovrebbe usare aiutanti ancora di più a vostro rischio rispetto
AUR stessa.

Timeline di Arch Linux AUR Incident Response

  • Sun luglio 8 05:48:06 UTC 2018 - Rapporto iniziale.
  • Sun luglio 8 05:54:58 UTC 2018 - Account sospeso, impegnarsi per conversione utilizzando i privilegi utente attendibili.
  • Sun luglio 8 06:02:08 UTC 2018 - I pacchetti aggiuntivi sono stati fissati con il team AUR.

Gli utenti di tutte le distribuzioni Linux dovrebbero essere ben consapevoli dei rischi connessi con l'installazione di software da repository che non sono mantenuti direttamente dai loro manutentori diretti. In alcuni casi essi non portano lo stesso impegno e la responsabilità, ed è molto più probabile che un'infezione da malware può diffondersi e non possono essere affrontati a tempo debito.

Nota: L'articolo è stato aggiornato con una cronologia degli eventi.

Martin Beltov

Martin si è laureato con una laurea in Pubblicazione da Università di Sofia. Come un appassionato di sicurezza informatica si diletta a scrivere sulle ultime minacce e meccanismi di intrusione.

Altri messaggi

Seguimi:
Cinguettio

16 Commenti
  1. somebob

    Così ERM l'elenco dei pacchetti colpite potrebbe essere bello in include.

    Replica
    1. Martin Beltov (Autore Post)

      Hey somebob,

      Ho seguito l'incidente sul Arch Linux mailing list ufficiale e i pacchetti citati sono “libvlc.git” e “acroread.git”. Gli sviluppatori affermano che due altri pacchetti oltre “acroread” sono stati manipolati, una e-mail in seguito menzionato “libvlc”.

      Guarda il link in questo articolo per accedere alla discussione, se siete interessati a come la squadra ha gestito la situazione in dettaglio.

      Replica
  2. neithere

    non “trust esplicito” intende il comportamento desiderato, i.e. decisione informata di un utente su un determinato pacchetto, piuttosto che “fiducia implicita”, i.e. la mancanza di decisione dell'utente per quanto riguarda un particolare pacchetto, ma una generale fiducia a tutti loro?

    Replica
    1. Martin Beltov (Autore Post)

      Credo che tu abbia ragione!

      Replica
  3. nessuno

    Qualcuno era appena discussione la fonte libvlc. Se andate a leggere le e-mail più tardi è stato sottolineato che l'URL fa parte di pacman-mirrorlist.

    Replica
    1. Martin Beltov (Autore Post)

      Grazie per chiarire questo.

      Replica
  4. Marcin Mikolajczak

    Probabilmente ognuno aiutante AUR ci informa che dobbiamo leggere PKGBUILD, così essere infettati da malware a questo livello vuol dire che qualcuno non trattare seriamente la sicurezza ...

    Replica
    1. Martin Beltov (Autore Post)

      Vero, speriamo che questo incidente aiuterà a sensibilizzare.

      Replica
  5. Roel Brook

    6 minuti è un tempo di risposta piuttosto bene.

    La mia ipotesi sarebbe l'uscita potrebbe essere utilizzato per un attacco più mirata contro le macchine più potenti. Se si può dire la maggior parte delle macchine con 32 core hanno qualche pacchetto installato, a sapere che uno si dovrebbe dirottare prossima.

    Non è tanto una fiducia nel sistema AUR sé. E 'più fidarsi del manutentore(s). Quando un pacchetto passa manutentore, si dovrebbe essere temporanea in guardia.

    Sarebbe una bella aggiunta alla youart.

    Replica
    1. Martin Beltov (Autore Post)

      AUR fiducia gli utenti sono IMHO impressionante!

      Replica
  6. Condor

    Quindi perché si consiglia di controllare il PKGBUILD ogni tanto prima di installare o aggiornamento del software AUR. repository utente-mantenuto a volte possono contenere i pacchetti che sono state costruite dai somari, no Sherlock merda!

    Replica
    1. Martin Beltov (Autore Post)

      Vero, ma non tutti possono capire le variabili e il codice nei file PKGBUILD.

      Replica
  7. TORTA

    È per questo che posso consigliare utilizzando “trizen” sopra “yogurt”: Ho tutti le informazioni di prima. (Inoltre hanno fatto la loro routine fuga giusta).

    Replica
    1. Martin Beltov (Autore Post)

      Grazie per la raccomandazione, Ho sempre usato “yogurt” come io sono abituato ad esso.

      Replica
  8. Phoenix591

    Vero, ma è bash semplice concentrato quasi interamente in un unico file (Preferisco di gran lunga in formato debian in proposito), e l'unica direzione ufficiale su come usare AUR ha avuto belle avvisi rossi dicendo assegno di codice potenzialmente dannoso (e in caso di dubbi chiedere sul forum thr e / o mailing list) per anni

    Replica
    1. Martin Beltov (Autore Post)

      Sono d'accordo che la community di Arch Linux è molto affidabile. Il repository AUR è impressionante in quanto contiene molti pacchetti che non possono essere incluse nelle principali repos.

      Il wiki fornisce una panoramica dettagliata di come viene gestito, Spero che la “acroread caso” fisserà le spie necessarie ai nuovi utenti nella gestione dei pacchetti dall'utente mantenuto con maggior cura.

      TORTA postato un commento qui affermando che la “trizen” applicazione di supporto mostra dettagliate informazioni PKGBUILD di default.

      Replica

Lascio un commento

Il tuo indirizzo email non verrà pubblicato. I campi obbligatori sono contrassegnati *

This website uses cookies to improve user experience. By using our website you consent to all cookies in accordance with our politica sulla riservatezza.
Sono d'accordo