Breaking the Chain: An Attacker's Perspective on Supply Chain Vulnerabilities and Flaws

00:34:49
https://www.youtube.com/watch?v=mWgcJxQ7i2U

Ringkasan

TLDRIn this presentation, security researchers Akil Kotokoda and Eli Goldman from Aqua Security explore various vulnerabilities in the software supply chain, particularly focusing on open-source projects and development tools. They discuss the risks associated with different phases of the development flow, including the IDE, SCM, registry, CI/CD, artifacts, and runtime phases. The researchers provide real-world examples of vulnerabilities such as malicious VS Code extensions, repo jacking, package planting, and timing attacks on npm. They emphasize the importance of understanding potential attack vectors and suggest mitigations and best practices for developers and organizations to enhance security against supply chain attacks.

Takeaways

  • 🔍 Understanding supply chain attacks is crucial for developers.
  • 🛡️ Malicious VS Code extensions can pose significant risks.
  • ⚠️ Repo jacking can redirect users to malicious repositories.
  • 📦 Package planting allows attackers to take control of npm packages.
  • ⏱️ Timing attacks can expose private package names on npm.
  • 🔑 Regularly rotate secrets to minimize exposure.
  • 🛠️ Use security tools to evaluate open-source projects.
  • 📈 Threat modeling helps identify vulnerabilities in development flow.
  • 🔗 Verified signs in marketplaces can be misleading.
  • 📣 Report vulnerabilities to improve overall security.

Garis waktu

  • 00:00:00 - 00:05:00

    Akil Kotokoda and Eli Goldman, security researchers from Aqua Security, introduce their focus on vulnerabilities in the supply chain and open source projects. They highlight the importance of understanding supply chain attacks and the various phases of the development flow, from code writing to production deployment.

  • 00:05:00 - 00:10:00

    The presentation discusses the risks associated with Visual Studio Code (VS Code) extensions, emphasizing the ease of impersonating popular extensions. They demonstrate how malicious extensions can be disguised and the challenges in distinguishing between legitimate and fake ones, raising concerns about the security of the marketplace.

  • 00:10:00 - 00:15:00

    The researchers explain the concept of 'repo jacking,' where an attacker can take over a repository after an organization changes its name. They provide examples of how this can lead to users inadvertently accessing malicious repositories, emphasizing the need for organizations to maintain control over their old repository names to prevent exploitation.

  • 00:15:00 - 00:20:00

    In the registry phase, they discuss a vulnerability in npm that allowed attackers to add themselves as owners of malicious packages. This could mislead developers into installing harmful packages, highlighting the importance of verifying package ownership and the need for better security practices in open source projects.

  • 00:20:00 - 00:25:00

    The CI/CD phase reveals vulnerabilities in Travis CI that exposed sensitive tokens from numerous open source projects. The researchers found that attackers could access public logs and retrieve sensitive information, stressing the importance of deleting old logs and rotating tokens regularly to mitigate risks.

  • 00:25:00 - 00:34:49

    Finally, they address the artifact phase, focusing on a timing attack that could disclose private package names on npm. They call for unified security standards across different registries to enhance overall supply chain security, concluding with a reminder of the potential catastrophic consequences of these vulnerabilities and the need for vigilance in the development process.

Tampilkan lebih banyak

Peta Pikiran

Video Tanya Jawab

  • What is the main focus of the research presented?

    The research focuses on vulnerabilities in the software supply chain, particularly in open-source projects and development tools.

  • What are some examples of vulnerabilities discussed?

    Examples include malicious VS Code extensions, repo jacking, package planting, and timing attacks on npm.

  • What is repo jacking?

    Repo jacking occurs when an attacker takes control of an old repository name after an organization changes its name, leading users to access the attacker's repository instead.

  • How can developers protect themselves from malicious packages?

    Developers should verify the ownership of packages, use security ranking tools, and regularly audit their dependencies.

  • What is the significance of the verified sign in marketplaces?

    The verified sign indicates that the platform has validated the publisher's identity, but it can be misused if not properly managed.

  • What recommendations do the speakers provide for organizations?

    Organizations should conduct threat modeling, rotate secrets regularly, and ensure security practices are in place at each stage of the development flow.

  • What is the impact of malicious VS Code extensions?

    Malicious extensions can execute harmful actions on a developer's machine, such as stealing credentials or executing ransomware.

  • What is package planting?

    Package planting is a vulnerability where an attacker can add themselves as a new owner of a malicious package on npm.

  • What should developers do if they find vulnerabilities in their dependencies?

    They should report the vulnerabilities to the respective platforms and consider using secret scanning tools.

  • Why is it important to understand the development flow?

    Understanding the development flow helps identify potential exposure points to supply chain attacks and implement appropriate defenses.

Lihat lebih banyak ringkasan video

Dapatkan akses instan ke ringkasan video YouTube gratis yang didukung oleh AI!
Teks
en
Gulir Otomatis:
  • 00:00:02
    hello everyone my name is Akil kotokoda
  • 00:00:05
    and I am Eli Goldman and we are security
  • 00:00:07
    researchers from Aqua security and in
  • 00:00:10
    this session we will demonstrate you
  • 00:00:11
    several of accountabilities and flow
  • 00:00:12
    that we found in some platforms so some
  • 00:00:15
    details about us Eli and I have previous
  • 00:00:18
    experience in penetration testing and
  • 00:00:19
    red teaming and we have tried to use
  • 00:00:21
    this experience in our research mindset
  • 00:00:23
    currently we are mainly focused on
  • 00:00:25
    vulnerabilities on the supply chain
  • 00:00:27
    space and in open source projects
  • 00:00:30
    so we first want to start with Iron Man
  • 00:00:33
    sets for This research here in front of
  • 00:00:35
    you are four famous articles about
  • 00:00:36
    supply chain attacks each one of them
  • 00:00:39
    head or could have had destructive
  • 00:00:41
    effects now each attack has its own
  • 00:00:44
    story behind it some begun maybe because
  • 00:00:46
    of a secret exposed in a Docker image
  • 00:00:49
    file ever because a developer was hacked
  • 00:00:51
    the possibilities are endless
  • 00:00:53
    we see all the time today publications
  • 00:00:55
    of a malicious python package was
  • 00:00:58
    uploaded uploaded to pewpie and this is
  • 00:01:00
    a good thing it's a good step to another
  • 00:01:02
    Community but for us to be aware we
  • 00:01:04
    don't just need to seek out malicious
  • 00:01:06
    packages uploaded to the platform where
  • 00:01:08
    we consumer dependencies form we first
  • 00:01:10
    need to understand what makes an attack
  • 00:01:12
    a supply chain attack understand our
  • 00:01:14
    organization's point of exposure to
  • 00:01:15
    supply chain attacks and defend at each
  • 00:01:18
    point because attackers today have many
  • 00:01:20
    entry points to the organization from
  • 00:01:22
    the from the moment the developer writes
  • 00:01:25
    the code on his own laptop until the
  • 00:01:26
    binary is one in production that is why
  • 00:01:29
    we want to raise awareness of attacks in
  • 00:01:31
    each phase of the development flow so
  • 00:01:33
    first a quick recap of the development
  • 00:01:36
    flow we first start with the ID where
  • 00:01:38
    the developer writes his code then we
  • 00:01:41
    move on to the sem phase where the
  • 00:01:42
    developer and his organization store
  • 00:01:44
    their code
  • 00:01:45
    after that we're in the registry phase
  • 00:01:47
    which includes attacks on the platform
  • 00:01:49
    where we consume our dependencies from
  • 00:01:51
    then we will arrive to the cicd phase
  • 00:01:53
    this phase takes everything up to here
  • 00:01:56
    combines the code into one artifact and
  • 00:01:58
    sometimes even deploy it
  • 00:02:00
    after that we are in the artifacts phase
  • 00:02:02
    the artifacts phase is just like the
  • 00:02:04
    register phase reporting on your point
  • 00:02:06
    of view are you a consumer of a package
  • 00:02:08
    or a provider of a package for example
  • 00:02:11
    and finally the runtime phase where our
  • 00:02:13
    code is being executed we speak here
  • 00:02:16
    about original research that we've
  • 00:02:17
    connected in each one of these phases
  • 00:02:19
    except the runtime phase starting with
  • 00:02:22
    the IDE phase he will talk about
  • 00:02:24
    research about Visual Studio code
  • 00:02:26
    extensions
  • 00:02:27
    so first why this code there are many
  • 00:02:30
    code editors as you can see here Sublime
  • 00:02:32
    IntelliJ and this code but this code is
  • 00:02:35
    the most popular one how popular
  • 00:02:37
    according to a survey conducted by stack
  • 00:02:39
    Overflow more than 74 percent of the
  • 00:02:41
    users use vs code as their main IDE
  • 00:02:44
    now viscode is strong tool but its main
  • 00:02:46
    power comes from its extensions there
  • 00:02:49
    are many extensions varying from
  • 00:02:50
    prettifying the code that you write and
  • 00:02:52
    ending with Git integration and debug
  • 00:02:54
    tools how do you install these
  • 00:02:56
    extensions from the marketplace just go
  • 00:02:58
    online search the extension you want to
  • 00:03:00
    install and install it you can do it
  • 00:03:02
    from the web interface as you can see
  • 00:03:04
    here or from the viscode application
  • 00:03:06
    itself
  • 00:03:07
    now that we know how popular are this
  • 00:03:10
    code and the extensions I want to shift
  • 00:03:12
    our view a bit when I tell you npm
  • 00:03:15
    packages what are the associations that
  • 00:03:16
    you are getting
  • 00:03:17
    so of course this is a security
  • 00:03:19
    conference and probably most of us are
  • 00:03:21
    thinking about malicious npm packages
  • 00:03:23
    and indeed when you search Google for
  • 00:03:25
    malicious npm packages you see many
  • 00:03:28
    results of packages stealing credit
  • 00:03:29
    cards and tokens and this is a good
  • 00:03:31
    thing the Publications not the malicious
  • 00:03:33
    packages but what happens when you
  • 00:03:35
    search for mesha's vs code extensions
  • 00:03:38
    there are hardly any results there are
  • 00:03:41
    results about results about vulnerable
  • 00:03:43
    extensions but it's important to state
  • 00:03:45
    that vulnerable is not malicious and
  • 00:03:48
    there are two different things
  • 00:03:49
    okay there aren't any Publications about
  • 00:03:52
    malicious extensions but what can an
  • 00:03:55
    extension even do so the answer it can
  • 00:03:58
    do anything the user can do it runs on
  • 00:04:00
    the progress laptop can run ransomware
  • 00:04:02
    for example or even use the SSH key of
  • 00:04:04
    the programmer to connect to the private
  • 00:04:06
    repositories of visualization in GitHub
  • 00:04:09
    so now that we know the dangers of
  • 00:04:11
    installing a malicious physical
  • 00:04:12
    extensions we want to see how easy it is
  • 00:04:15
    to impersonate a popular extension in
  • 00:04:17
    the marketplace fooling developers into
  • 00:04:19
    installing it so that we chose spirit is
  • 00:04:23
    the fiscal extension that is in the top
  • 00:04:24
    10 installs in the marketplace we
  • 00:04:27
    uploaded our own pretty with warranty I
  • 00:04:29
    want to see the differences and
  • 00:04:31
    similarities let's take a closer look
  • 00:04:33
    we can see marked at 1 the URL there is
  • 00:04:37
    a slight change but not many look at the
  • 00:04:39
    URL what I really want to focus here on
  • 00:04:42
    Watermark two and three in the image you
  • 00:04:44
    can see that they are identical this is
  • 00:04:46
    because this is the Publishers and the
  • 00:04:49
    extensions display name property it does
  • 00:04:52
    not have to be unique and you can put in
  • 00:04:53
    there whatever you want and for example
  • 00:04:55
    here we wrote prettier with two T's
  • 00:04:58
    there's also the installs and reviews
  • 00:05:01
    which is a good measure to understand if
  • 00:05:03
    the extension is okay or not but it can
  • 00:05:05
    be fabricated overall when we look at
  • 00:05:08
    both these extensions it's very hard to
  • 00:05:10
    distinguish which one is the original
  • 00:05:12
    one and which one is the person
  • 00:05:13
    impersonating one but do not worry
  • 00:05:15
    Microsoft is here to help us
  • 00:05:18
    they uploaded a guideline that says can
  • 00:05:21
    I trust extensions from the marketplace
  • 00:05:22
    okay that sounds good and in there they
  • 00:05:25
    tell you here are a few steps that you
  • 00:05:27
    can take in order to make an informed
  • 00:05:29
    decision and one of these steps is
  • 00:05:31
    take a look at the repository that is
  • 00:05:33
    linked to the extension but we were able
  • 00:05:36
    to fabricate the repository in the
  • 00:05:38
    extension to be the same so this does
  • 00:05:41
    not help us at all
  • 00:05:42
    in Microsoft defense other platforms has
  • 00:05:44
    destroyable as well
  • 00:05:46
    now up to here we saw how we can make
  • 00:05:50
    the land page of the extension seems
  • 00:05:52
    similar but how will someone even get to
  • 00:05:54
    our extension when you search for
  • 00:05:56
    pritier in the marketplace there are
  • 00:05:58
    many many results and your extension is
  • 00:06:00
    not even here
  • 00:06:01
    but what happens when someone by mistake
  • 00:06:04
    searches for Britain with one t
  • 00:06:07
    the answer is that our extension is the
  • 00:06:09
    only result and you can even see there
  • 00:06:11
    that in the Box it it results with the
  • 00:06:13
    display name property tweeted with 2T
  • 00:06:15
    making it very hard to distinguish
  • 00:06:17
    we took everything into account here
  • 00:06:20
    how easy it is to impersonate a purple
  • 00:06:22
    extension in the marketplace and what a
  • 00:06:25
    malicious extension can do in your
  • 00:06:26
    computer computer which is anything and
  • 00:06:28
    decided to upload the POC we upload the
  • 00:06:30
    pre-tier with one t so earlier it just
  • 00:06:33
    gave us a little ping when it was
  • 00:06:34
    installed by a developer and the results
  • 00:06:37
    are in front of you Another 48 Hours
  • 00:06:40
    more than 1 000 developers around the
  • 00:06:43
    world installed our own personal
  • 00:06:45
    extension each developer here could have
  • 00:06:48
    been the entry point Focus supply chain
  • 00:06:50
    attack on his internal organization now
  • 00:06:52
    just imagine the scenario of a real
  • 00:06:54
    attacker uploading a real malicious
  • 00:06:56
    extension
  • 00:06:58
    another flow I want to talk to you about
  • 00:07:00
    in the marketplace is the verified sign
  • 00:07:02
    when we see this verified sign the
  • 00:07:05
    associations that we are getting is that
  • 00:07:07
    the platform is validated that the
  • 00:07:08
    person behind this page is indeed with
  • 00:07:11
    lenses let's see an example of the
  • 00:07:13
    social accounts of LeBron James we can
  • 00:07:15
    see we have Instagram Facebook and
  • 00:07:17
    Twitter all of them he has a verified
  • 00:07:19
    sign all of them validated that LeBron
  • 00:07:21
    James is Behind These Pages now let's
  • 00:07:24
    look at the verified sign in the
  • 00:07:26
    marketplace here we can see we have
  • 00:07:28
    semic load here that has an extension of
  • 00:07:31
    two installs okay and a verified sign
  • 00:07:33
    when we put our Mouse on the verified
  • 00:07:35
    sign we can see there is a little pop-up
  • 00:07:37
    that says Santa Claus has a verified
  • 00:07:40
    ownership for the domain semi-cloud.net
  • 00:07:43
    wait what
  • 00:07:45
    let's look at the requirements to even
  • 00:07:47
    get a verified sign in the marketplace
  • 00:07:49
    you go online choose the publisher you
  • 00:07:51
    want to verify enter an eligible domain
  • 00:07:54
    which is just any domain prove that you
  • 00:07:58
    own this domain and that's it this means
  • 00:08:01
    that any developer like semi-cloud here
  • 00:08:03
    can receive a verified sign Sam if
  • 00:08:06
    you're present or listening to this
  • 00:08:07
    recording nothing personal thank you for
  • 00:08:10
    your contribution to our research
  • 00:08:12
    now the sharp eyes of you can see that
  • 00:08:14
    they're verified sign location is near
  • 00:08:17
    the display name property what we did
  • 00:08:19
    pretty with two things before just
  • 00:08:21
    imagine the scenario of an attacker
  • 00:08:23
    receiving a verified sign and then
  • 00:08:25
    changing the display in property to
  • 00:08:27
    pretend with duties
  • 00:08:29
    probably the most suspecting developers
  • 00:08:31
    will be full volume so now what I've
  • 00:08:34
    showed you here are the requirements for
  • 00:08:36
    verified sign before the publication of
  • 00:08:38
    our research
  • 00:08:39
    after the publication Microsoft added a
  • 00:08:42
    little note that says if you change your
  • 00:08:45
    if you change your display name property
  • 00:08:46
    your verified badge will be revoked so
  • 00:08:48
    this is a good mitigation from the
  • 00:08:50
    platform to minimize some of the risks
  • 00:08:53
    another good thing we saw the result of
  • 00:08:55
    the research is that the real prettier
  • 00:08:56
    receive the verified sign they did not
  • 00:08:58
    have before
  • 00:08:59
    the problem remains of what this
  • 00:09:01
    verified sign represents but it's a good
  • 00:09:04
    step from the publisher side
  • 00:09:06
    now we talked a lot about the
  • 00:09:08
    marketplace I want to dig a little
  • 00:09:10
    deeper into what is an extension so an
  • 00:09:13
    extension ends with Visa X which is just
  • 00:09:15
    a zip file and when you unzip this file
  • 00:09:18
    you see there are many other files and
  • 00:09:20
    in one of them a little magic file this
  • 00:09:22
    file is Packet Json so where do you
  • 00:09:25
    remember package.json
  • 00:09:27
    from npm packages what you need to
  • 00:09:29
    understand from now on is that a viscode
  • 00:09:32
    extension is just like an npm package
  • 00:09:35
    and those are the all the dangers of npm
  • 00:09:37
    packages like attacks on dependencies of
  • 00:09:39
    dependencies but this is for another
  • 00:09:40
    session
  • 00:09:42
    now we talked here before that there are
  • 00:09:44
    a lot of publications of malicious npm
  • 00:09:46
    packages I want to introduce you to
  • 00:09:48
    bextable backstable is a collection of
  • 00:09:51
    malicious open source packages hence
  • 00:09:54
    including malicious npm packages that
  • 00:09:56
    was collected over the years
  • 00:09:58
    it is how it looks like it has many
  • 00:10:01
    details about different malicious
  • 00:10:02
    packages including the objective of the
  • 00:10:05
    package like stealing tokens environment
  • 00:10:06
    variables and the method of attack like
  • 00:10:09
    typos quoting
  • 00:10:10
    here's an example of such a package
  • 00:10:13
    you can see the code takes the
  • 00:10:14
    environment variable of the process and
  • 00:10:17
    sends it to the attacker machine
  • 00:10:18
    stealing the environment variables of
  • 00:10:20
    the attacked user now we took a look at
  • 00:10:23
    many packages like this one in order to
  • 00:10:26
    search for patterns of malicious npm
  • 00:10:29
    packages in order to find malicious vs
  • 00:10:32
    code extensions in the marketplace
  • 00:10:35
    for that we used same group same rep is
  • 00:10:38
    a SAS tool that uses rules in order to
  • 00:10:40
    search for patterns inside code
  • 00:10:43
    here's a very simple rule that we wrote
  • 00:10:45
    that just searches for execution
  • 00:10:47
    commands like exec and eval that happen
  • 00:10:49
    after an HTTP event like a get request
  • 00:10:51
    we run it across the marketplace and
  • 00:10:54
    here's the result that we found
  • 00:10:55
    you can see that upon installation of
  • 00:10:57
    the extension the uh the computer will
  • 00:11:00
    go to the attacker's machine make a get
  • 00:11:02
    request
  • 00:11:03
    from the get request take the response
  • 00:11:05
    data and send it to eval which is a
  • 00:11:07
    command execution this means that when a
  • 00:11:10
    developer will install this malicious
  • 00:11:12
    malicious extension upon installation
  • 00:11:14
    the computer will go to the advanced
  • 00:11:16
    domain fetch code and run it locally now
  • 00:11:19
    this can be a malicious extension or
  • 00:11:22
    just a very bad code written by
  • 00:11:24
    developer I can tell you on top of that
  • 00:11:26
    that the domain that you see here was
  • 00:11:29
    available for everyone to buy when we
  • 00:11:31
    encounter this extension this means that
  • 00:11:33
    even if this is not a malicious
  • 00:11:35
    extension an attacker could have bought
  • 00:11:37
    this domain and attack legitimate users
  • 00:11:40
    making it a malicious extension
  • 00:11:43
    either way we report it to Microsoft and
  • 00:11:45
    they removed it from the marketplace of
  • 00:11:46
    course
  • 00:11:48
    another thing we need to understand
  • 00:11:49
    about extensions in the marketplace is
  • 00:11:52
    that when we upload an extension it's
  • 00:11:54
    visible for everyone and we may by
  • 00:11:56
    mistake leak secrets we scanned with
  • 00:12:00
    various scanning tools the marketplace
  • 00:12:01
    and it is an example that we found you
  • 00:12:04
    can see that when you open the Visa X of
  • 00:12:06
    the extension there are many files and
  • 00:12:08
    here there is a little token file and
  • 00:12:10
    what this token file holds
  • 00:12:12
    tokens tokens to the marketplace itself
  • 00:12:15
    this means that when an attacker will
  • 00:12:17
    get this token he can publish a
  • 00:12:19
    malicious extension under the name of an
  • 00:12:21
    innocent publisher we found many other
  • 00:12:23
    tokens like AWS keys and many more of
  • 00:12:26
    course everything is here was revoked
  • 00:12:28
    and reported to the publishers
  • 00:12:31
    so a few mitigations recommendations for
  • 00:12:34
    the IDE phase of the vs code extensions
  • 00:12:36
    first thing first the platforms and
  • 00:12:39
    Publishers responsibility the platform
  • 00:12:41
    has a responsibility for us the
  • 00:12:43
    consumers especially a platform where
  • 00:12:45
    Anonymous users can upload an extension
  • 00:12:47
    to minimize our points of exposure we
  • 00:12:50
    saw they mitigated some of the risks in
  • 00:12:52
    the verified sign but there are many
  • 00:12:54
    other flaws that need to be taken care
  • 00:12:56
    of
  • 00:12:57
    the Publishers also have responsibility
  • 00:12:59
    there is a verified mechanism apply for
  • 00:13:01
    IT Help users identify you
  • 00:13:06
    there is a brand new world out there or
  • 00:13:09
    vulnerability is secrets and maybe even
  • 00:13:11
    malicious activities in the marketplace
  • 00:13:13
    are you an extension developer be sure
  • 00:13:16
    to scan your extensions for
  • 00:13:17
    vulnerabilities and secrets before you
  • 00:13:19
    upload them to the marketplace you may
  • 00:13:21
    never know which token you may have
  • 00:13:22
    leaked by mistake starting a supply
  • 00:13:24
    chain attack on your organization
  • 00:13:26
    most importantly we've shown here how we
  • 00:13:29
    can attack developers even before they
  • 00:13:31
    write their code we call it shift left
  • 00:13:33
    lift attacking the developers now these
  • 00:13:36
    results were shown on this code in the
  • 00:13:38
    marketplace but there are many more
  • 00:13:40
    ideas and their own Marketplace that
  • 00:13:43
    probably have the same flaws
  • 00:13:46
    okay
  • 00:13:47
    we finished with ID phase about this
  • 00:13:49
    code and moving on to the SCM phase he
  • 00:13:52
    will talk about an attack called
  • 00:13:54
    reprojecting so first what is
  • 00:13:56
    reprojecting let's start with an example
  • 00:13:59
    assume an organization called
  • 00:14:00
    marginization and within the repository
  • 00:14:03
    called my lipo in order for user to
  • 00:14:05
    access this repository you'll need to
  • 00:14:07
    browse the URL in front of you
  • 00:14:09
    now the organization decides to change
  • 00:14:11
    their name to new organization so the
  • 00:14:13
    users will need to access the new URL
  • 00:14:15
    instead
  • 00:14:16
    however what will happen if a user
  • 00:14:19
    accesses the old URL by mistake
  • 00:14:22
    there will be an HTTP redirect and
  • 00:14:24
    everything will be okay
  • 00:14:25
    but now because the organization changed
  • 00:14:28
    their name then my organization name is
  • 00:14:30
    free for everyone to take what will
  • 00:14:32
    happen if an attacker creates the
  • 00:14:34
    marginalization organization and reflect
  • 00:14:37
    the my repo Repository
  • 00:14:39
    there will no longer be a redirect and
  • 00:14:41
    users that access the old URL of the
  • 00:14:43
    legitimate repository by mistake will
  • 00:14:46
    actually access the attacker's
  • 00:14:47
    Repository
  • 00:14:48
    this is the call of repo jacking there
  • 00:14:50
    are more scenarios like transferring the
  • 00:14:52
    ownership instead of rename but it's all
  • 00:14:54
    about the same
  • 00:14:55
    now there are some restrictions deployed
  • 00:14:58
    by GitHub of the capability of the
  • 00:15:00
    attacker of opening dual repository name
  • 00:15:02
    but just in 2022 there were so many
  • 00:15:06
    bypasses to these restrictions defined
  • 00:15:08
    by GitHub so as a result in our research
  • 00:15:11
    in our research and this presentation a
  • 00:15:14
    repository that has a redirect for its
  • 00:15:16
    old name and the old name is available
  • 00:15:18
    to take counted as vulnerable
  • 00:15:20
    nevertheless
  • 00:15:22
    all the examples we're going to show
  • 00:15:24
    here were fully exploitable even with
  • 00:15:27
    the the protections deployed by GitHub
  • 00:15:30
    so up to here one is so the triple
  • 00:15:32
    checking is just a redirect not
  • 00:15:34
    happening right let's understand a few
  • 00:15:37
    exploitation scenarios for this attack
  • 00:15:39
    a link in the code to the previous name
  • 00:15:41
    this can be when in the code itself
  • 00:15:43
    there is a reference to your level
  • 00:15:45
    repository to download the resource for
  • 00:15:47
    example we're going to go module file a
  • 00:15:49
    go module Imports uh installation guide
  • 00:15:52
    references
  • 00:15:53
    this can be when in written instructions
  • 00:15:55
    there is a reference to the URL of the
  • 00:15:58
    repository but when the organization
  • 00:15:59
    changed their name they forgot to change
  • 00:16:01
    the written instructions we'll see an
  • 00:16:03
    example of this
  • 00:16:04
    and how to cover Link in post across the
  • 00:16:06
    internet
  • 00:16:07
    and scenario of this someone recommends
  • 00:16:09
    a specific tool in stack Overflow
  • 00:16:10
    linking a repository after the answer
  • 00:16:12
    the only of the repository change the
  • 00:16:15
    organization name but of course the
  • 00:16:17
    stack Overflow enter remained the same
  • 00:16:19
    let's see some real life examples here
  • 00:16:22
    we have a Google project Google Map
  • 00:16:24
    steps that was probably transferred to
  • 00:16:26
    their ownership but they forgot to
  • 00:16:28
    change the readme instructions let's
  • 00:16:29
    take a closer look at the readme
  • 00:16:32
    here we can see Google is the access to
  • 00:16:33
    do a git clone to the socratic map steps
  • 00:16:36
    and not the Google Map steps and indeed
  • 00:16:38
    when you access this URL you get
  • 00:16:40
    redirected to Google Map steps however
  • 00:16:43
    when an attacker will create a Socratic
  • 00:16:46
    organization and within the math steps
  • 00:16:48
    repository they will no longer be a
  • 00:16:50
    redirect and users that follow Google's
  • 00:16:52
    instructions will actually clone the
  • 00:16:54
    attackers Repository
  • 00:16:56
    when Google is accessed to do npm
  • 00:16:58
    install which will result in remote code
  • 00:17:00
    execution of the attacker on Google
  • 00:17:02
    users we made a POC on this repository
  • 00:17:05
    we opened a socatic organization and
  • 00:17:08
    within it the Master's repository and
  • 00:17:10
    the uploaded repository to give us a
  • 00:17:12
    little ping when npm install was
  • 00:17:13
    executed we got number as a result of
  • 00:17:16
    code execution on open source users and
  • 00:17:18
    developers of big companies
  • 00:17:22
    another example I want to show you here
  • 00:17:23
    is this installer sales script we can
  • 00:17:26
    see inside the script there is the
  • 00:17:27
    download URI which points to a zip
  • 00:17:29
    inside the repository that is vulnerable
  • 00:17:32
    to repo jacking now it it the script
  • 00:17:35
    downloads this ZIP locally and unzips it
  • 00:17:38
    and from the zip takes the Dominos stage
  • 00:17:41
    script and executes it
  • 00:17:43
    this means that when an attacker will
  • 00:17:45
    create a yes graph organization that is
  • 00:17:47
    in the download URI the s-gov
  • 00:17:49
    organization and within the Dominus
  • 00:17:50
    repository users that execute the
  • 00:17:53
    original install sh scripts will
  • 00:17:55
    actually download the zip of the
  • 00:17:56
    attacker and execute the Dominos sales
  • 00:17:59
    clip of the attacker
  • 00:18:01
    this is the proof that we control the
  • 00:18:03
    sgov organization and within it we can
  • 00:18:05
    open the Dominos Repository
  • 00:18:08
    now a third example I'll show you is
  • 00:18:10
    just like the Google scenario of written
  • 00:18:12
    instructions but it's a special case for
  • 00:18:14
    us so I'll show it anyway you can see in
  • 00:18:16
    the written instructions they tell us to
  • 00:18:18
    download an extension Visa X which is
  • 00:18:21
    a vs code extension
  • 00:18:23
    and of course this link is vulnerable to
  • 00:18:24
    repo jacking it's from the releases in
  • 00:18:26
    GitHub and when an attacker will create
  • 00:18:28
    the old organization name Infinity
  • 00:18:30
    repository they will no longer be a
  • 00:18:32
    redirects and users that press this
  • 00:18:35
    download link will actually download the
  • 00:18:37
    attacker's Discord extension now
  • 00:18:40
    actually this repository is what led us
  • 00:18:43
    a research to understand what are the
  • 00:18:45
    dangers of installing a malicious
  • 00:18:46
    vehicle extensions any dangers and the
  • 00:18:49
    flaws in the marketplace that we've
  • 00:18:50
    shown before
  • 00:18:52
    in order for an attacker to exploit this
  • 00:18:55
    broadly he needs to know the previous
  • 00:18:56
    names of repositories for that he can
  • 00:18:59
    use the gh1 projects this project
  • 00:19:01
    records all public activities
  • 00:19:04
    on a public repository like commits and
  • 00:19:07
    pull requests this is a gold mine for
  • 00:19:09
    researchers
  • 00:19:10
    and attackers you can see here in the of
  • 00:19:14
    the data set there are specific download
  • 00:19:15
    links of a specific years and months
  • 00:19:18
    each link here contains millions of
  • 00:19:21
    repositories
  • 00:19:22
    so what would we do with this
  • 00:19:23
    information nothing beats a good
  • 00:19:25
    statistic charts we took a random month
  • 00:19:27
    June 2019 and restarted all the
  • 00:19:30
    repositories name from there that
  • 00:19:31
    amounted to 125 million unique
  • 00:19:34
    repositories
  • 00:19:35
    from that we took a random sample of one
  • 00:19:37
    percent which is 1.25 million
  • 00:19:40
    repositories eject each one if it is
  • 00:19:42
    vulnerable to repo jacking and the
  • 00:19:44
    result
  • 00:19:45
    approximately 37 000 repositories
  • 00:19:48
    available to repo jacking that is almost
  • 00:19:50
    three percent
  • 00:19:51
    if you apply this stat on the entire
  • 00:19:53
    GitHub out of 100 repositories out there
  • 00:19:56
    three of them are vulnerable to repo
  • 00:19:58
    jacking and we have a way to find the
  • 00:19:59
    previous name using these data sets we
  • 00:20:02
    disclosed our findings to various
  • 00:20:04
    companies of the examples we saw here
  • 00:20:06
    and many many more remember thanks to
  • 00:20:09
    the data sets if you change your name
  • 00:20:11
    anytime in the past an attacker can't
  • 00:20:13
    find your old name and explore it and
  • 00:20:15
    change references
  • 00:20:17
    that being said we have a few
  • 00:20:19
    mitigations recommendations we'd like to
  • 00:20:20
    suggest check all the GitHub links in
  • 00:20:23
    your code now
  • 00:20:25
    and periodically you may never know when
  • 00:20:28
    a go model for example might change
  • 00:20:30
    their name
  • 00:20:31
    do you want to change organization M
  • 00:20:33
    sure do it but also keep it just as a
  • 00:20:36
    place over there so antaki won't be able
  • 00:20:38
    to acquire it and exploit and change
  • 00:20:39
    references
  • 00:20:41
    do you want to sell it for vulnerable
  • 00:20:43
    repositories here is a little tip there
  • 00:20:45
    is a high possibility of findings that's
  • 00:20:47
    vulnerable repositories around
  • 00:20:48
    Acquisitions and mergers when they
  • 00:20:51
    rename the organization
  • 00:20:53
    okay we've finished with the ID phase
  • 00:20:56
    and the sem phase and now we're moving
  • 00:20:58
    on to the registry phase so yeah
  • 00:21:01
    okay in this phase we will demonstrate
  • 00:21:04
    use vulnerability that we found on npm
  • 00:21:05
    and was fixed by there this
  • 00:21:07
    vulnerability will demonstrate you the
  • 00:21:08
    risk for developer so what is package
  • 00:21:11
    planting in the past npm registry allow
  • 00:21:14
    any user to add any other user as the
  • 00:21:16
    new as the new owner of malicious
  • 00:21:18
    packages
  • 00:21:19
    and as you can see here first of all
  • 00:21:21
    attacker upload Alicia's package and
  • 00:21:22
    then he add another user in which is the
  • 00:21:25
    new maintenance of the malicious packet
  • 00:21:26
    and this is really simple Vector that
  • 00:21:29
    could be done via the npm CLI first of
  • 00:21:31
    all attacker use npm publish in order to
  • 00:21:33
    publish the package then attack any user
  • 00:21:36
    A Wish For example popular profile like
  • 00:21:39
    npm and Facebook profile and of course
  • 00:21:41
    after this attacker remove himself in
  • 00:21:44
    order to make the package seem to be
  • 00:21:45
    more innocent
  • 00:21:47
    and this is how the malicious landing
  • 00:21:49
    page of the package will look like as
  • 00:21:51
    you can see if you or any other
  • 00:21:53
    developer in your organization somehow
  • 00:21:55
    encountered this fancy malicious packet
  • 00:21:57
    you might be full into installing it
  • 00:21:58
    because it seemed to be owned by user
  • 00:22:00
    with a lot of reputation in the platform
  • 00:22:03
    and it was also possible via the npm
  • 00:22:06
    website to add another user but the
  • 00:22:08
    reason why I'm showing it here is there
  • 00:22:10
    is another issue some of you may notice
  • 00:22:12
    that when attackers try to add another
  • 00:22:14
    user as the new owner of his malicious
  • 00:22:16
    packet you will get their 2fa status so
  • 00:22:19
    we have two information disclosed
  • 00:22:21
    of course we write a wrote a script that
  • 00:22:24
    did this for us and we get a lot of 2fa
  • 00:22:26
    status of many popular maintainers on
  • 00:22:29
    npm and we get really interesting
  • 00:22:32
    statistics about the 2fa status of
  • 00:22:34
    direct maintainer and indirect
  • 00:22:37
    maintenance of popular packages
  • 00:22:39
    we report our fighting to npm which say
  • 00:22:42
    they act they tracking this issue
  • 00:22:44
    internally and they actively working on
  • 00:22:46
    fixing it and after some month they
  • 00:22:48
    release a patch a confirmation mechanism
  • 00:22:50
    so now it's no longer possible and if
  • 00:22:53
    you want to add another user as the
  • 00:22:54
    owner of your package an email will be
  • 00:22:57
    sent to their email address and they
  • 00:22:58
    need to approve it first
  • 00:23:00
    there are some lessons that you can
  • 00:23:02
    learn from the currency from the current
  • 00:23:03
    issue first of all if you are using npn
  • 00:23:06
    it might be a good idea to check that
  • 00:23:08
    all the packages under your scope really
  • 00:23:10
    belong to your scope because this Vector
  • 00:23:12
    was possible in the past and you need to
  • 00:23:15
    be always suspicious about the ownership
  • 00:23:17
    of your about the owners of your
  • 00:23:19
    dependency now I know it sounds obvious
  • 00:23:21
    and it's easier said than done so what
  • 00:23:23
    you can do in order to achieve this
  • 00:23:25
    first of all you can evaluate open
  • 00:23:27
    source project by using different
  • 00:23:28
    sources that are available today lag
  • 00:23:31
    devdaps and socket Dev that actually
  • 00:23:33
    give you security ranking of different
  • 00:23:34
    open source project and you can also use
  • 00:23:37
    browser extension that do this thing for
  • 00:23:39
    us and actually and actually collect
  • 00:23:42
    data from different sources
  • 00:23:44
    okay we are on the cicd phase here we
  • 00:23:48
    will show you vulnerability that you
  • 00:23:49
    found on traffic CI that could put at
  • 00:23:52
    risk 10 of thousand of open source
  • 00:23:53
    project so
  • 00:23:55
    our research began after we realized
  • 00:23:57
    there had been a huge increase among
  • 00:23:59
    different CI providers over there if you
  • 00:24:01
    think about it in the past Jenkins and
  • 00:24:04
    Travis were the only available CI tools
  • 00:24:06
    but now we have GitHub action Circle CI
  • 00:24:09
    Azure Pipeline and more and we start to
  • 00:24:11
    notice that many open source projects
  • 00:24:13
    start to migrate between both different
  • 00:24:14
    CI providers and sometimes it's possible
  • 00:24:17
    to find user to this they decide to move
  • 00:24:20
    from Travis to GitHub action for example
  • 00:24:22
    and in is all the infrastructure on
  • 00:24:25
    Travis to find some secret data
  • 00:24:28
    after we read a great article about
  • 00:24:30
    eight flow about similar issue and we
  • 00:24:33
    decided took our research one step
  • 00:24:35
    further and actually we found a lot of
  • 00:24:36
    token of popular projects
  • 00:24:38
    while researching the API of Travis we
  • 00:24:41
    found that actually one of the API
  • 00:24:43
    Travis is vulnerable to idle which means
  • 00:24:45
    attacker could actually get any public
  • 00:24:47
    log that ever exists in Travis API and
  • 00:24:50
    within this log actually to search for
  • 00:24:53
    secrets and this is how it's look it's
  • 00:24:55
    really simple all attackers you need to
  • 00:24:56
    do is change the sequence number and
  • 00:24:58
    then it will get instant random build
  • 00:25:00
    number it build output and we found
  • 00:25:04
    actually that there are more than 770
  • 00:25:07
    Millions available logs of different
  • 00:25:08
    projects but we must admit that not all
  • 00:25:12
    the log in this range were available so
  • 00:25:14
    we keep our research and found another
  • 00:25:16
    API of traffic is available to idle this
  • 00:25:19
    time there are two interesting part
  • 00:25:20
    about this issue first of all these
  • 00:25:23
    sequence numbers start from 1 and it
  • 00:25:25
    will then it will it will really direct
  • 00:25:28
    us to some S3 bucket and this will be
  • 00:25:32
    the exact same logs as we found in the
  • 00:25:34
    first method but now logs that we found
  • 00:25:38
    in the first method and were accessible
  • 00:25:39
    now have become available so we managed
  • 00:25:42
    to bypass their restriction and expand
  • 00:25:45
    our attack surface
  • 00:25:47
    and like the repo jacking research we
  • 00:25:49
    like a lot of data so because we lazy we
  • 00:25:51
    decided to took only one percent of the
  • 00:25:53
    available log which sell up to around 8
  • 00:25:56
    million slogs and then run different
  • 00:25:58
    scanning tools and our own word list and
  • 00:26:01
    then we saw the price we got a lot of
  • 00:26:03
    token that related to really popular
  • 00:26:05
    platform like GitHub AWS Docker app some
  • 00:26:08
    of the token that we found related to
  • 00:26:10
    project with ten of thousands of GitHub
  • 00:26:12
    actually form only one percent of the
  • 00:26:15
    log we found more than 73 000 of
  • 00:26:17
    different token
  • 00:26:19
    and in the chat if one of you you can
  • 00:26:21
    see the diversity of the token that we
  • 00:26:23
    found a lot of token for defense usages
  • 00:26:25
    and it's really important to say that
  • 00:26:27
    not all the token are equal and some
  • 00:26:29
    exposure and danger more than other
  • 00:26:32
    in order to understand how to use this
  • 00:26:35
    token we use the clear X project that
  • 00:26:37
    contain a lot of token and the related
  • 00:26:38
    API and this helps us to know how to
  • 00:26:40
    verify those token
  • 00:26:44
    of course Travis tried to censor some of
  • 00:26:46
    the token that we found by the diversity
  • 00:26:48
    of the token and the log where too much
  • 00:26:50
    to handle you can see that only for
  • 00:26:52
    GitHub token we found more than 20
  • 00:26:54
    different aliases
  • 00:26:56
    okay so let's connect all we have here
  • 00:26:59
    we had a lot of token that anyone can
  • 00:27:01
    access a way to access a restriction
  • 00:27:04
    logs and a poor rate limiting process so
  • 00:27:07
    we get it a really dangerous and
  • 00:27:09
    critical situation
  • 00:27:11
    we import our finding to avci which
  • 00:27:13
    which responded that this issue is by
  • 00:27:15
    Design and they do not intend to fix it
  • 00:27:17
    great for us and of course after our
  • 00:27:21
    research was widely published Travis
  • 00:27:23
    start mitigate the risk and deleted the
  • 00:27:24
    logs we also report our filing to a
  • 00:27:27
    respective service provider all of them
  • 00:27:29
    were aligned and initiated y key
  • 00:27:30
    rotation and other verified that at
  • 00:27:32
    least 50 percent of our findings were
  • 00:27:35
    still valid so what we can learn from
  • 00:27:37
    the current issue
  • 00:27:38
    first of all it might be a good idea to
  • 00:27:40
    delete any Legacy or old component that
  • 00:27:43
    you have in or in your infrastructure
  • 00:27:45
    because sometimes it can contains logs
  • 00:27:47
    and regardless logs it's important to
  • 00:27:50
    rotate them periodically some of the
  • 00:27:52
    token that we found were 70 years old
  • 00:27:55
    it's also important to give your third
  • 00:27:57
    party token the only privilege they need
  • 00:27:59
    and it might be a good idea to scan any
  • 00:28:02
    output from your development flow or
  • 00:28:04
    from any CI that you have with secret
  • 00:28:06
    scanning tool and when you do so try to
  • 00:28:09
    use different scanning tools because
  • 00:28:11
    each one of them have their own nuance
  • 00:28:13
    and their own method for example some of
  • 00:28:15
    them use entropy some of them use
  • 00:28:17
    pattern and in order to get fully
  • 00:28:19
    visualization of exposed secrets you
  • 00:28:21
    need to combine them together
  • 00:28:23
    okay now we are on the artifact phase
  • 00:28:26
    here we'll demonstrate the vulnerability
  • 00:28:28
    that we found on npm that can allow
  • 00:28:30
    attacker to disclose private package
  • 00:28:32
    name so first of all what is private
  • 00:28:34
    package on npm npm registry allow user
  • 00:28:37
    to upload to the public npm registry
  • 00:28:39
    private package these packages is only
  • 00:28:42
    available to to specific numbers of user
  • 00:28:44
    and organizations and as their name
  • 00:28:46
    suggests the content and their name
  • 00:28:49
    should not be available for anyone the
  • 00:28:51
    name of private package must consist of
  • 00:28:53
    two parts first of all the username aka
  • 00:28:56
    the scope and then the private package
  • 00:28:59
    name
  • 00:29:00
    and what is timing attack when we refer
  • 00:29:03
    to timing attack we refer to a method
  • 00:29:05
    for a for attacker to disclose sensitive
  • 00:29:08
    data from the server only by observing
  • 00:29:10
    the they took the server to respawn for
  • 00:29:12
    different input here for example
  • 00:29:14
    attacker could only by observing the
  • 00:29:16
    time they took the npm API to respond
  • 00:29:19
    for specific metadata of of private
  • 00:29:22
    package to figure if the package exists
  • 00:29:24
    or not
  • 00:29:25
    so how npm is vulnerable to timing
  • 00:29:28
    attack
  • 00:29:28
    let's assume that attackers want to
  • 00:29:30
    query npm API for a specific package
  • 00:29:33
    that called Secrets package of an
  • 00:29:35
    organization that called random
  • 00:29:36
    organization
  • 00:29:37
    of course if he will try to do this as
  • 00:29:39
    Anonymous user it will not get any
  • 00:29:42
    result in 404 but the interesting part
  • 00:29:45
    is not the 4004 and there has no any
  • 00:29:48
    data about this package the interesting
  • 00:29:51
    part is the time they took the server to
  • 00:29:53
    respond
  • 00:29:54
    in our research we found that if
  • 00:29:55
    attackers make around 5 requests in a
  • 00:29:58
    row it's possible to determine if the
  • 00:30:00
    package exists or not basically if the
  • 00:30:02
    package exists the respawn time will be
  • 00:30:05
    longer and if the package doesn't exist
  • 00:30:07
    the respawn time will be shorter and
  • 00:30:09
    will decrease over time because some
  • 00:30:11
    caching mechanism on npm and if you want
  • 00:30:14
    more specific data in our research we
  • 00:30:16
    found that if the package exists and you
  • 00:30:18
    try to query npm API for specific
  • 00:30:21
    private package the server will respond
  • 00:30:23
    after 600 milliseconds and if the
  • 00:30:25
    package doesn't exist the respond time
  • 00:30:27
    will be under 100 millisecond
  • 00:30:31
    so our attacker can use this attack
  • 00:30:34
    let's assume that attacker by using this
  • 00:30:36
    method find a private package that
  • 00:30:37
    called a low ward of an organization
  • 00:30:39
    that's called an e-test.org what attack
  • 00:30:42
    you will try to do is to figure out if
  • 00:30:44
    there is another package under the
  • 00:30:46
    public npm registry without the scope in
  • 00:30:50
    order to take other developer that
  • 00:30:52
    forget to mention the scope of the
  • 00:30:53
    package
  • 00:30:54
    but in order to deeply understand this I
  • 00:30:57
    want to give an example from another
  • 00:30:58
    platform Docker Hub if you know Docker
  • 00:31:01
    app you know that when you try to upload
  • 00:31:03
    Docker image the name of Docker image
  • 00:31:05
    must consist of two parts first of all
  • 00:31:08
    the username and then the image name and
  • 00:31:11
    attacker or anyone cannot upload an
  • 00:31:14
    image without a scope the only one that
  • 00:31:16
    could do it in Docker app is actually
  • 00:31:18
    the docker app team themselves so we
  • 00:31:20
    have scenario that is possible in npm
  • 00:31:22
    but it's not possible in Docker app and
  • 00:31:25
    this lead us to our first takeaway here
  • 00:31:26
    we need to unified security standard
  • 00:31:28
    between different registry on the supply
  • 00:31:31
    chain space because each one of them
  • 00:31:33
    have their own nuance and mitigations
  • 00:31:35
    and then PM have a lot of them but if we
  • 00:31:38
    will combine all of them as Community we
  • 00:31:40
    actually improve the overall security of
  • 00:31:42
    the supply supply chain space
  • 00:31:45
    okay we disclose our finding to npm team
  • 00:31:48
    and which responded because some
  • 00:31:50
    architectural limitation they cannot
  • 00:31:52
    prevent such attack so it's still
  • 00:31:54
    possible and they even exclude this from
  • 00:31:56
    the their back Bounty program but the
  • 00:32:00
    mitigation here is very simple all that
  • 00:32:02
    new users need to do in order to
  • 00:32:03
    mitigate the rescue is to create place
  • 00:32:05
    order package under the public npm
  • 00:32:07
    registry
  • 00:32:08
    and if you want to read more about other
  • 00:32:11
    attack Vector that you related to this
  • 00:32:13
    issue there is a really great blog by
  • 00:32:15
    npmting npm avoiding substitution
  • 00:32:18
    attacks and a security researcher it's
  • 00:32:20
    always a good idea to check for timing
  • 00:32:22
    attack in other platforms
  • 00:32:24
    so let's sum up all the points that we
  • 00:32:27
    have here we've shown you a lot of
  • 00:32:28
    different examples for different phases
  • 00:32:30
    we have talked about IDE extension about
  • 00:32:33
    repo jacking package planting tokens on
  • 00:32:36
    cicds and even our attacker can find
  • 00:32:40
    your private package on npm if you think
  • 00:32:42
    about it each of the example were really
  • 00:32:45
    simple but their consequences might be
  • 00:32:48
    catastrophical for some organizations
  • 00:32:51
    you need to ensure security at each
  • 00:32:53
    stage of the development flow we've
  • 00:32:55
    shown you many mitigations for different
  • 00:32:57
    risks but sometimes they will very
  • 00:33:00
    specific to the research description
  • 00:33:01
    here on this college for example you
  • 00:33:03
    need to understand how your organization
  • 00:33:05
    fits inside this development flow and do
  • 00:33:08
    threat modeling to understand the
  • 00:33:09
    different risks that you are exposed to
  • 00:33:12
    are you a security researcher be careful
  • 00:33:15
    if the pocs that you upload do you
  • 00:33:18
    remember the CTX incident a security
  • 00:33:20
    researcher uploaded a malicious python
  • 00:33:23
    package to pewpie stealing environment
  • 00:33:25
    variables after there was a lot of
  • 00:33:27
    traffic regarding this message package
  • 00:33:29
    he uploaded a blog post that says do not
  • 00:33:31
    worry I'm a security researcher not a
  • 00:33:34
    malicious actor I do not intend to do
  • 00:33:36
    anything with your secrets and I deleted
  • 00:33:39
    them
  • 00:33:39
    now of course no one can believe
  • 00:33:42
    anything he says and now all the
  • 00:33:44
    organizations need to rotate the secrets
  • 00:33:46
    and the security evaluations to
  • 00:33:48
    understand if they were bleached by
  • 00:33:50
    using these secrets
  • 00:33:52
    as a security researcher you need to
  • 00:33:54
    understand when you upload the POC to
  • 00:33:56
    npm pupil or even the marketplace of
  • 00:34:00
    this code you don't Target a single user
  • 00:34:02
    or a single company you target the whole
  • 00:34:04
    open source community so things go out
  • 00:34:06
    of hand very easily you need to be very
  • 00:34:09
    careful
  • 00:34:10
    and our last point if you think about it
  • 00:34:14
    all the security researchers and the
  • 00:34:16
    open source Community when we speak
  • 00:34:17
    about vulnerabilities and attack vectors
  • 00:34:19
    that related to supply chain they are
  • 00:34:22
    only focused on popular platform like
  • 00:34:23
    npm go and pewpie but there are so many
  • 00:34:27
    other registry that sometimes vulnerable
  • 00:34:29
    to the same issue but currently they do
  • 00:34:32
    not get any attention from anyone and
  • 00:34:34
    they can expose a lot of organization to
  • 00:34:36
    supply chain attacks
  • 00:34:37
    thanks for listening everyone if you
  • 00:34:39
    have any questions feel free to contact
  • 00:34:41
    us there or right now
  • 00:34:43
    thank you
  • 00:34:44
    [Applause]
Tags
  • supply chain
  • vulnerabilities
  • open source
  • security
  • npm
  • repo jacking
  • malicious packages
  • CI/CD
  • development flow
  • best practices