Tietoturvatutkija tunkeutui suuryritysten verkkoihin avoimen lähdekoodin pakettivarastojen kautta

[Kaotik]

Kaotik kirjoitti uutisen/artikkelin:
Tietoturvatutkija Alex Birsan on löytänyt mielenkiintoisen tietoturvaongelman, joka koskee useita avoimen lähdekoodin pakettivarastoja (repository, repo) sekä niihin luottavia sovelluksia. Birsan murtautui sen avulla yli 35 suuren teknologiayrityksen verkkoon tutkimustarkoituksessa.

Birsan huomasi aiempaa tutkimusta tehdessään erään PayPalin sisäisesti käyttämän npm-paketin manifestin viittaavan paketteihin, jotka eivät olleet saatavilla julkisesti npm:n pakettivarastosta, vaan vain PayPalin sisäisistä pakettivarastoista. Uteliaana tutkijana Birsan testasi, miten sovellus käyttäytyisi, mikäli saman niminen paketti löytyisikin yksityisen pakettivaraston lisäksi julkisesta jaosta.

Birsan testasi asiaa käytännössä selvittämällä mahdollisimman monien sisäisten pakettien, joita ei olisi jaossa julkisissa pakettivarastoissa, nimiä ja loi omat pakettinsa identtisin nimin asianmukaisiin julkisiin pakettivarastoihin kuten npm:ään, PyPI:hin ja RubyGemsiin. Käytännön testit osoittivat, että useimmissa tapauksissa julkisista varastoista löytyvät tiedostot saivat ohjelmilta prioriteetin sisäisten yli ja esimerkiksi PyPI-paketeissa korkeamman versionumeron sisältävä sai prioriteetin riippumatta siitä, missä paketti sijaitsi.

Birsan sai syötettyä omat tiedostonsa pakettivarastojen kautta ainakin Applelle, Microsoftille, Netflixille, PayPalille, Shopifylle, Teslalle, Uberille ja Yelpille. Hän kutsuu metodiaan ”dependency confusioniksi” eli riippuvaisuushämmennykseksi ja pitää sitä haavoittuvuutena tai suunnitteluvirheenä automaattisissa kääntö- ja asennustyökaluissa. Birsan on tienannut haavoittuvuudella jo yli 130 000 dollaria eri yritysten Bug Bounty -ohjelmien kautta. Voit lukea yritysten kommentteja asiasta Bleeping Computerin artikkelista.

Lähde: Bleeping Computer

Linkki alkuperäiseen juttuun

 

[Agent_007]

Suurempi ongelma tässä on se, että suurimmassa osassa pakettienhallintaa ei ole mitään suoritusoikeuksien rajojen asettamista noille paketeille. Deno taitaa olla ensimmäisiä ajoympäristöjä, joissa tämä on otettu edes jotenkin huomioon.

 

[jive]

Sellainen pieni tarkennus että tällä kertaa kyse ei ole käyttöjärjestelmien/jakelujulkaisujen paketinhallinnasta vaan sovelluskehysten jakelumekanismeista. Itse olen kategorisesti estänyt PyPi, npm ja CPAN mekanismit. Lisäksi kaikki varannot ovat peilattuja omille palvelimille.

 

[finnaster]

Suurempi ongelma tässä on se, että suurimmassa osassa pakettienhallintaa ei ole mitään suoritusoikeuksien rajojen asettamista noille paketeille. Deno taitaa olla ensimmäisiä ajoympäristöjä, joissa tämä on otettu edes jotenkin huomioon.

Denossa oikeudet ovat sovelluskohtaisia, eli oikeuksia ei voi antaa pakettikohtaisesti. Ajatus on kyllä hieno, mutta lopulta hieman turha, koska kaikki asennetut paketit saavat samat oikeudet.

 

[Raikku]

Pystyisikö pakettiautomaattien kautta hakkeroitumaan postiin?

 

[antero]

En tunne Linuxia, mutta tuo nostaa karvat pystyyn.
"Birsan testasi asiaa käytännössä selvittämällä mahdollisimman monien sisäisten pakettien, joita ei olisi jaossa julkisissa pakettivarastoissa, nimiä ja loi omat pakettinsa identtisin nimin asianmukaisiin julkisiin pakettivarastoihin kuten npm:ään, PyPI:hin ja RubyGemsiin
Eli eikö pakettivarastoissa ole minkään näköistä sensuuria vaan kuka vaan voi lisätä sinne pakettejaan?
Lisäksi hänellä ollu sisäpiirin tietoa kun on tienny tidestojen nimet etukäteen.

 

[Grez]

Eli eikö pakettivarastoissa ole minkään näköistä sensuuria vaan kuka vaan voi lisätä sinne pakettejaan?V

Niissä on vissiin saman verran "sensuuria" kuin domainnimissä - kuka vaan voi rekisteröidä itselleen domainin joka ei vielä ole käytössä.

Ideahan on kummassakin (pakettivarastot ja internet) aika lailla samanlainen. Kumpaankin voi julkaista tuottamaansa sisältöä ja jos joku kokee siitä olevan iloa itselleen, voi käyttää sitä. Se että joku sensori kävisi kaiken julkaistavan läpi tuntuu kummassakin tapauksessa aika raskaalta operaatiolta hyötyyn nähden. Ja ennakkosensuuria ei yleensä länsimaissa edes katsota hyvällä.

En tunne Linuxia, mutta tuo nostaa karvat pystyyn.

Miten tämä nyt Linuxiin liittyi? Samoja pakettivarastoja käyttää myös Windowsilla ja Macilla devaavat.

 

[maverikki]

En tunne Linuxia, mutta tuo nostaa karvat pystyyn.
Lisäksi hänellä ollu sisäpiirin tietoa kun on tienny tidestojen nimet etukäteen.

Kyseessä oli vaan NPM:n espressohuuruinen pakettivarasto. Ei liity mitenkään Linuxiin. Ei tartte kummaa sisäpiirin tietoa kaivaa jostain paketista sen riippuvuudet. Mutta nää on ainakin jollain tasalla korjattu ja organisaatiossa olisi syytä katsoa peiliin, jos julkisesti pääsee sisäverkosta latailemaan ihan mitä vaan.

 

[bakugi]

Kyseessä oli vaan NPM:n espressohuuruinen pakettivarasto. Ei liity mitenkään Linuxiin. Ei tartte kummaa sisäpiirin tietoa kaivaa jostain paketista sen riippuvuudet. Mutta nää on ainakin jollain tasalla korjattu ja organisaatiossa olisi syytä katsoa peiliin, jos julkisesti pääsee sisäverkosta latailemaan ihan mitä vaan.

Nämä ovat siis olleet mm. githubissa julkisissa repoissa nähtävillä:

While attempting to hack PayPal with me during the summer of 2020, Justin Gardner (@Rhynorater) shared an interesting bit of Node.js source code found on GitHub.

The code was meant for internal PayPal use, and, in its package.json file, appeared to contain a mix of public and private dependencies — public packages from npm, as well as non-public package names, most likely hosted internally by PayPal. These names did not exist on the public npm registry at the time.

A few full days of searching for private package names belonging to some of the targeted companies revealed that many other names could be found on GitHub, as well as on the major package hosting services — inside internal packages which had been accidentally published — and even within posts on various internet forums.

 

[Oss]

Pystyisikö pakettiautomaattien kautta hakkeroitumaan postiin?

Pakettiautomaattien kautta Postin sisäiseen pakettivarastoon tunkeutuminen onnistunee ns. "Man in the Middle Box" -hyökkäyksen avulla fyysistä vektoria hyväksykäyttäen, soveltuvin kääntö- ja asennustyökaluin varustautuneena.

 

[djtob]

Eikö näissä hommissa juuri palkkioita lahjoiteta niitä valkohattuisia hakkereita löytämään ne reiät ennen kuin ovat mustahattuisilla hakkereilla hyödynnettävissä? Muistaakseni aikoinaan oli uutisoitu tämän tapaisista uutisista, joten en olisi huolissaan.

 

[Kaotik]

Eikö näissä hommissa juuri palkkioita lahjoiteta niitä valkohattuisia hakkereita löytämään ne reiät ennen kuin ovat mustahattuisilla hakkereilla hyödynnettävissä? Muistaakseni aikoinaan oli uutisoitu tämän tapaisista uutisista, joten en olisi huolissaan.

Kyllä, ja niin tässäkin tapauksessa uutista kirjoittaessa oli saanut jo $130k noista bug bounty -ohjelmista tämän löytämisestä

 

[Kautium]

En tunne Linuxia, mutta tuo nostaa karvat pystyyn.
"Birsan testasi asiaa käytännössä selvittämällä mahdollisimman monien sisäisten pakettien, joita ei olisi jaossa julkisissa pakettivarastoissa, nimiä ja loi omat pakettinsa identtisin nimin asianmukaisiin julkisiin pakettivarastoihin kuten npm:ään, PyPI:hin ja RubyGemsiin
Eli eikö pakettivarastoissa ole minkään näköistä sensuuria vaan kuka vaan voi lisätä sinne pakettejaan?
Lisäksi hänellä ollu sisäpiirin tietoa kun on tienny tidestojen nimet etukäteen.

Noissa kehitysympäristöjen pakettivarastoissa on nähty monta kertaa vaikka millaista ketkua, jotka luottavat siihen että joku kuitenkin kirjoittaa paketin nimen pikkuisen väärin ja lopputuloksena koneelle voi valua vaikka millaista schaissea. Oletuksena noissa ei ole mitään tarkistuksia välissä.

Tässä joku satunnainen uutinen muutaman vuoden takaa:

Malicious code in the Node.js npm registry shakes open source trust model

Bad actors using typo-squatting place 39 malicious packages in npm that went undetected for two weeks. How should the open source community respond?

www.csoonline.com

Tämän ketjun aloituksen tapauksessa oli tavallaan kyse saman asian kääntöpuolesta, eli paketin nimi oli oikein, mutta latauspaikka ja siten sisältökään ei.