Home News Malicious NPM packages target Amazon, Slack with new dependency attacks

    Malicious NPM packages target Amazon, Slack with new dependency attacks

    11
    0


    Supply chain attack

    Risk actors are concentrating on Amazon, Zillow, Lyft, and Slack NodeJS apps utilizing a brand new ‘Dependency Confusion’ vulnerability to steal Linux/Unix password recordsdata and open reverse shells again to the attackers.

    Final month, BleepingComputer reported that safety researcher Alex Birsan earned bug bounties from 35 companies by using a brand new flaw in open-source growth instruments.

    This flaw works by attackers creating packages using the identical names as an organization’s inside repositories or parts. When hosted on public repositories, together with npm, PyPI, and RubyGems, dependency managers would use the packages on the general public repo moderately than the corporate’s inside packages when constructing the applying.

    This “dependency confusion” would permit an attacker to inject their very own malicious code into an inside utility in a supply-chain assault.

    Risk actors start utilizing dependency confusion

    Since our report, BleepingComputer has been ready for malicious actors to make the most of this new vulnerability to ship malicious packages.

    Whereas we have now seen numerous security researchers impersonate Birsan’s work by creating innocent PoCs to earn bug bounties, we had not seen any malicious actions.

    That’s till right now when open-source safety agency Sonatype found malicious packages concentrating on purposes associated to Amazon, Zillow, Lyft, and Slack to steal passwords and open distant shells.

    “I used to be beginning to marvel once we have been going to see a malicious actor reap the benefits of the present scenario. Lastly, we have noticed one.”

    “There isn’t any state of affairs I can think about the place I will submit a PoC for a bug bounty program that truly harms the group. Taking their /and so forth/shadow file is unquestionably dangerous,” mentioned Sonatype safety researcher Juan Aguirre in a new report.

    These malicious packages are named ‘amzn’, ‘zg-rentals’, ‘lyft-dataset-sdk’, ‘serverless-slack-app’ and make the most of related names as identified repositories on GitHub [1, 2] and different projects.

    When the risk actors created their malicious NPMs, they used Birsan’s authentic PoCs as a template however added malicious code.

    “They begin out with just about the identical code base because the PoC launched by researcher Alex Birsan and so they progressively begin getting inventive,” Aguirre explains.

    For instance, the ‘amzn’ and ‘zg-rentals’ NPM packages won’t solely steal the /and so forth/shadows password file (line 5 beneath) and ship it again to the attackers (line 42) but in addition open up a distant shell (line 26), giving the risk actors full entry to the system.

    Malicious amzn package
    Malicious amzn package deal

    The ‘lyft-dataset-sdk’ and ‘serverless-slack-app’ look like from a unique writer, and as an alternative steal a Linux profiles .bash_history file and sends it to a distant host underneath the attacker’s management.

    serverless-slack-app stealing .bash_history file
    serverless-slack-app stealing .bash_history file

    You might be questioning why an attacker would wish to steal a .bash_history file?

    Because the historical past file incorporates a listing of all of the instructions you typed within the shell, together with passwords handed as arguments, stealing the .bash_history file is a known technique utilized by attackers to reap credentials.

    With the open and public nature of repositories and the convenience of making dependency confusion assaults, we must always anticipate to see such a assault proceed till utility builders safe their configuration recordsdata.

    Microsoft has created a white paper titled “3 Ways to Mitigate Risk When Using Private Package Feeds” that gives recommendations on stopping most of these supply-chain assaults.

    Sonatype additionally created a script that Nexus Repository Supervisor customers can use to verify if their non-public dependencies are named after present packages on public repositories.



    Source link