Tag: DevSecOps

  • First Malicious MCP and Mitigation’s

    First Malicious MCP and Mitigation’s

    As you may have heard: the first malicious MCP[Model Context Protocol] was found in the wild [link + archived of coursex2 ]. While many articles tout this not a ton go over mitigation strategies. The good news is that many “traditional” security control mechanisms could help. Thinking off the top of my head I can think of a couple:

    Preempting issue beforehand:

    Unfortunately hindsight can be 20/20 but there are things you can do before hand to try to preempt these issues such as:

    – Administrative Controls: Risk assessment
    – Artifact management
    – SCA [software composition analysis] or BOM [bill of materials]
    – Dependency pinning

    Many developers feel slowed down by needing to go to yet another review-board but these provide the valuable opportunity to ask basic questions like “Does this tool log to our enterprise logging solution?” and others. Going through the rigmarole can help ensure everyone is security/architecture minded and has a good guidance to mitigate risks [or at-least implement controls to remediate afterwords].

    In addition artifact management tools [like artifactory, sonatype,… others] could also help by preventing developers from pulling unknown artifacts from the web during build time. Unfortunately this has the perception of slowing down developers and doesn’t work for artifacts pulled outside of your enterprise solution.

    Also there are tools within the artifact management domain such as SCA and BOM to be able to identify artifacts and where they’re used etc… This might be something for you to look into as well.

    Another thing to consider [which may or may not have helped in this case] is dependency pinning. Instead of automatically upgrading dependencies you might want to have them stay at a particular version or (current -1). Unfortunately this approach has the gap of needing developers to manually update dependencies which can get laborious.

    Preempting In-flight:

    While a request is traveling over the wire there might be ways to preempt/prevent this as a technical compensating control. i.e.:

    -Least Privilege: MTA deny BCC functionality / deny-list

    Least privilege is a common security tenant: i.e. give the application[or thing..] the lest amount of privileges needed to do it’s job. Let’s say your app doesn’t use BCC consider seeing if it’s possible to turn it off & log+alert when it’s being used. While I’m not sure if it’s possible for the MCP issue at hand it’s a good thing to consider in general.

    Detection/After/Remediation

    Unfortunately in the real world these things happen being able to identify and remediate the issue is paramount. Here are some things I can think of:

    -Logging: Service itself or DPI
    -Artifact management w/ logging
    -MCP registry

    Logging is one of the common ways of looking for issues. If you have the logs from either the service itself or DPI[Deep packet inspection] you could probably look through those using a log analyzer [like splunk, sumologic, cloudwatch etc..] to identify patterns of malicious activity [i.e. emails BCC’d to `phan@giftshop [dot] club` ]. Unfortunately people might not have logging setup correctly or truncate the logs in a small time period. Also some tools make setting up logs difficult and may need work arounds such as using webhooks or custom coding a lambda/chron job to get them from point A to B.

    In addition you may want to play “who done it” i.e.: identify teams using bad dependencies and tap them on the shoulder to fix it. One way of doing that is via your artifact management solution [like artifactory, sonatype,… others]. If you have logging setup you could try to pull a report saying X “users” are pulling the bad artifact [although mapping that machine-to-machine service account to a git repo might be another story]. Also another gap is not everybody in your org might be using the artifact solution to pull artifacts. In such as case you may want to “fall back” to using logs from a egress gateway/DPI/network monitoring solution [i.e. palo alto, corelight zeek, squid proxy etc…] for which artifacts are being pulled where; although mapping IPs to human owners can be difficult.

    Another things too is the emergence of MCP registries. As this technology becomes more popular and utilized in the enterprise setting it may help identify who is using which MCP servers as well as decrease time to market by cataloging known good MCP servers.

    As we can see there are many ways using traditional security controls can help. As a bit of a disclaimer though your mileage may vary 🙂

    Here’s a diagram of what a typical enterprise setup could look like:

    A technical architecture diagram illustrating a secure enterprise environment, showing how public artifacts like NPM interact with private VPCs, CI/Git, Artifact Management, Egress/Ingress, Prod Services, Email SVC, Customers, and a Logging Analyzer, with dashed lines indicating logging pathways.

    Works Cited:

    Most of this article was based off my industry experience as a IT engineer.

    Original article from https://www.koi.security/blog/postmark-mcp-npm-malicious-backdoor-email-theft | Archived | X2

    infosecurity-magazine article https://www.infosecurity-magazine.com/news/malicious-ai-agent-server/ | Archived | X2

    FYI the thumbnail for this article was generated by generative-ai technologies namely my personal account for google Gemini. Thanks Gemini!