Arch Linux AUR Repository sig at indeholde malware

Arch Linux AUR Repository sig at indeholde malware

The Arch Linux-bruger-vedligeholdt software repository kaldet AUR har vist sig at hoste malware. Opdagelsen blev gjort efter en ændring i en af ​​pakkens monteringsvejledning blev gjort. Dette er endnu en hændelse, der viser, at Linux-brugere ikke eksplicit skal have tillid til bruger-kontrollerede depoter.

AUR Bruger-Vedligeholdt Arch Linux Repository Forurenet med malware




Linux-brugere i alle distributioner har modtaget en stor advarsel om ikke at udtrykkeligt har tillid til bruger-run softwarearkiver efter den seneste hændelse relateret til Arch Linux. Projektets bruger vedligeholdt AUR pakker (som står for ”Arch User Repository”) har vist sig at hoste malware kode i flere tilfælde. Heldigvis en kode analyse var i stand til at opdage de ændringer i god tid.

De sikkerhed undersøgelse viser, at viser, at en ondsindet bruger med nick navn xeactor ændret i juni 7 en forældreløs pakke (software uden en aktiv vedligeholder) kaldet acroread. Ændringerne omfattede en krølle script, der henter og kører et script fra et fjernt sted. Dette installerer en vedholdende software, der konfigurerer systemd for at starte med jævne mellemrum. Selv om det fremgår, at de ikke er en alvorlig trussel mod sikkerheden i de inficerede værter, scripts kan manipuleres til enhver tid at omfatte vilkårlig kode. To andre pakker blev ændret på samme måde.

relaterede Story: Gentoo Linux GitHub hacket via Password Guessing

Efter opdagelsen alle farlige forekomster blev fjernet, og den brugerkonto suspenderet. Undersøgelsen afslører, at de gennemførte scripts omfattede en høst af data komponent, der henter følgende oplysninger:

  • Machine ID.
  • Udgangssignalet fra uname -a.
  • CPU Information.
  • Pacman (pakke management utility) Information.
  • Udgangssignalet fra systemctl list-enheder.

Den høstede information skulle overføres til en Pastebin dokument. Den AUR hold opdagede, at de scripts, indeholdt den private API nøgle, der viser, at dette sandsynligvis blev udført af en uerfarne hacker. Formålet med informationssystemet forbliver ukendt.




Den confirmed list of affected packages includes the following AUR entries:

  • acroread 9.5.5-8
  • balz 1.20-3
  • minearbejder port 8.1-2

Der er flere hypoteser, der i øjeblikket betragtes som muligt. En reddit bruger (xanaxdroid_) førstnævnte online, der “xeactor” har lagt adskillige cryptocurrency minearbejder pakker, som viser, at infektion med dem var en sandsynlig næste skridt. Den opnåede systemoplysninger kan bruges til at vælge en generisk minearbejder instans, der ville være forenelig med de fleste af de inficerede værter. Den anden idé er, at nick navn tilhører en hacker gruppe, der kan målrette de inficerede værter med ransomware eller andre avancerede vira.

Hvorvidt Linux-brugere bruger Arch Linux, de bør dobbelttjekke, om nogen bruger-fastholdt depoter, som de bruger er troværdige. Denne hændelse viser endnu engang, at sikkerhed ikke kan garanteres. En bemærkning fra Giancarlo Razzolini (en Arch Linux betroede bruger) læser, der eksplicit tillidsfuld AUR og brug af hjælpeprogrammer er ikke en god sikkerhed praksis. Som reaktion på postlisten annoncerede han indsendt følgende svar:

Jeg er overrasket over, at
denne type af tåbelige pakke overtagelse og malware introduktion sker ikke oftere.

Det er derfor, vi insisterer brugerne altid hente PKGBUILD fra AUR, inspicere det og
bygge det selv. Hjælpere, der gør alt automatisk og brugere, der ikke betaler
opmærksomhed, *vil * har problemer. Du skal bruge hjælpere i endnu højere grad ved din risiko end
AUR selv.

Tidslinje for Arch Linux AUR Incident Respons

  • Sun juli 8 05:48:06 UTC 2018 - Initial Report.
  • Sun juli 8 05:54:58 UTC 2018 - Konto Suspenderet, begå vendt ved hjælp Trusted User privilegier.
  • Sun juli 8 06:02:08 UTC 2018 - De ekstra pakker er fastsat ved AUR teamet.

Brugere af alle Linux-distributioner bør være klar over de risici, der er forbundet med at installere software fra depoter, der ikke vedligeholdes direkte af deres direkte vedligeholdere. I nogle tilfælde har de ikke bære samme engagement og ansvar, og det er langt mere sandsynligt, at en malware-infektion kan spredes og kan ikke behandles i tide.

Note: Artiklen er blevet opdateret med en tidslinje over begivenhederne.

Martin Beltov

Martin dimitterede med en grad i Publishing fra Sofia Universitet. Som en cybersikkerhed entusiast han nyder at skrive om de nyeste trusler og mekanismer indbrud.

Flere indlæg

Følg mig:
TwitterGoogle Plus

16 Kommentarer

  1. somebob

    Så erm listen over pakker berørte kunne være rart i omfatte.

    Svar
    1. Martin Beltov (Indlæg forfatter)

      Hey somebob,

      Jeg fulgte hændelsen på den officielle Arch linux mailingliste og de nævnte pakker er “libvlc.git” og “acroread.git”. Udviklerne angiver, at to andre pakker foruden “acroread” er blevet manipuleret, en senere email nævnt “libvlc”.

      Kig på linket i artiklen for at få adgang til diskussion, hvis du er interesseret i, hvordan holdet håndterede situationen i detaljer.

      Svar
  2. neithere

    Doesn’texplicit trustmean the desired behaviour, dvs.. a user’s informed decision about a given package, hellere end “implicit trust”, dvs.. the lack of user’s decision regarding a particular package but a general trust to all of them?

    Svar
    1. Martin Beltov (Indlæg forfatter)

      I guess you’re right!

      Svar
  3. ingen

    Somebody was just questioning the libvlc source. If you read the later emails it was pointed out that the url is part of pacman-mirrorlist.

    Svar
    1. Martin Beltov (Indlæg forfatter)

      Thanks for clarifying this.

      Svar
  4. Marcin Mikołajczak

    Probably every single one AUR helper informs us that we should read PKGBUILDs, so being infected by malware at this layer means that somebody doesn’t treat security seriously…

    Svar
    1. Martin Beltov (Indlæg forfatter)

      Rigtigt, hopefully this incident will help to raise awareness.

      Svar
  5. Roel Brook

    6 minutes is a pretty good response time.

    My guess would be the output could be used for a more targeted attack against the more powerful machines. If you can tell most of the machines with 32 CPU cores have some package installed, you know which one you should hijack next.

    It’s not so much a trust in the AUR system itself. It’s more trusting the maintainer(s). When a package switches maintainer, you should be temporary on guard.

    Would be a nice addition to youart.

    Svar
    1. Martin Beltov (Indlæg forfatter)

      THE AUR trusted users are awesome IMHO!

      Svar
  6. Condor

    Hence why you may want to check the PKGBUILD every now and then before installing or upgrading AUR software. User-maintained repositories can sometimes hold packages that were built by jackasses, no shit Sherlock!

    Svar
    1. Martin Beltov (Indlæg forfatter)

      Rigtigt, but not everyone can understand the variables and code in the PKGBUILD files.

      Svar
  7. KAGE

    That’s why I can reccomend usingtrizen” løbet “yaourt”: I get all the information first. (Also they did their escaping routines right).

    Svar
    1. Martin Beltov (Indlæg forfatter)

      Thanks for the recommendation, I have always usedyaourtas I am accustomed to it.

      Svar
  8. Phoenix591

    Rigtigt, but it is straightforward bash concentrated almost entirely in a single file (I much prefer it to debian format in that regard), and the only official direction on how to use the AUR has had nice red warnings saying check for potentially malicious code (and if unsure ask on thr forums and/or mailing list) årevis

    Svar
    1. Martin Beltov (Indlæg forfatter)

      I agree that the Arch Linux user community is very reliable. The AUR repository is awesome as it contains many packages that cannot be included in the main repos.

      The wiki gives a detailed overview on how it is managed, I hope that theacroread casewill set the necessary warning lights to new users in handling the user-maintained packages with greater care.

      KAGE posted a comment here stating that thetrizenhelper application shows detailed PKGBUILD info by default.

      Svar

Efterlad en kommentar

Din e-mail-adresse vil ikke blive offentliggjort. Krævede felter er markeret *

Frist er opbrugt. Venligst genindlæse CAPTCHA.

Del på Facebook Del
Loading ...
Del på Twitter Tweet
Loading ...
Del på Google Plus Del
Loading ...
Del på Linkedin Del
Loading ...
Del på Digg Del
Del på Reddit Del
Loading ...
Del på Stumbleupon Del
Loading ...