3 ms·

I mean there are 2 other posts related to data exfiltration attacks against MCP severs on the main page of HN at the time of this comment - at this point I thin

by _pdp_ 1y ago

I mean there are 2 other posts related to data exfiltration attacks against MCP severs on the main page of HN at the time of this comment - at this point I think you want to involve a security person to make sure it is not vulnerable to stupid things.

Atotalnoob 1y ago
The MCP attacks are really just due to bad token scoping. If you allow Y to do X, if an attacker takes control of Y, of course they can do X.
- wild_egg 1y ago
  Can you elaborate on "bad token scoping"? I don't think your XY phrasing fully describes the GitHub MCP exploit and curious if you think that's somehow a "token scoping" issue.
  - fkyoureadthedoc 1y ago
    I'm unaware of the GitHub MCP "exploit", but given the overall state of LLM/MCP security FUD, there's probably some self promotion blog post from a security company about an LLM doing something stupid with GitHub data that the owner of the LLM using system didn't intend. For example, let's say I create an application that lets you chat with my open source repo. I set up my LLM with a GitHub tool. I don't want to think about oauth and getting a token from the end user, so I give it a PAT that I generated from my account. I'm even more lazy so I just used a PAT I already had laying around, and it unfortunately had read/write access to SSH keys. The user can add their ssh key to my account and do malicious things. Oh no, MCP is super vulnerable, please buy my LLM security product. If you give the LLM a tool, and you give the LLM input from a user, the user has access to that tool. That shrimple.
    - wild_egg 1y ago
      https://news.ycombinator.com/item?id=44097390 https://news.ycombinator.com/item?id=44097390 Also currently on the front page. It's mainly that this tool hits the trifecta of having privileged access, untrusted inputs, and ability to exfiltrate. Most tools only do 1-2 of those so attacks need to be more sophisticated to coordinate that.
- rexer 1y ago
  I think this downplays the security issue. It's true that scoping the token correctly would prevent this exploit, but it's not a reasonable solution under the assumptions that are taken by the designers of MCP. LLM+MCP is intended to be ultra flexible, and requiring a new (differently scoped) token for each input is not flexible. Perhaps you could have an allow/deny popup whenever the LLM wanted to interact with a service. But I think the end state there is presenting the user a bunch of metadata about the operation, which the user then needs to reason about. I don't know that's much better; those OAuth prompts are generally click throughs for users.
truemotive 1y ago
GitLab Duo got hit with an oopsie, "AI agent runs with same privilege to site content as the authenticated user" kinda oopsie where you could just exfiltrate private repo information via a pixel gif. I knew it would get bad, but this bad already? I yearn for rigor haha

by _pdp_ 1y ago

Atotalnoob 1y ago

The MCP attacks are really just due to bad token scoping. If you allow Y to do X, if an attacker takes control of Y, of course they can do X.

wild_egg 1y ago
Can you elaborate on "bad token scoping"? I don't think your XY phrasing fully describes the GitHub MCP exploit and curious if you think that's somehow a "token scoping" issue.
- fkyoureadthedoc 1y ago
  I'm unaware of the GitHub MCP "exploit", but given the overall state of LLM/MCP security FUD, there's probably some self promotion blog post from a security company about an LLM doing something stupid with GitHub data that the owner of the LLM using system didn't intend. For example, let's say I create an application that lets you chat with my open source repo. I set up my LLM with a GitHub tool. I don't want to think about oauth and getting a token from the end user, so I give it a PAT that I generated from my account. I'm even more lazy so I just used a PAT I already had laying around, and it unfortunately had read/write access to SSH keys. The user can add their ssh key to my account and do malicious things. Oh no, MCP is super vulnerable, please buy my LLM security product. If you give the LLM a tool, and you give the LLM input from a user, the user has access to that tool. That shrimple.
  - wild_egg 1y ago
    https://news.ycombinator.com/item?id=44097390 https://news.ycombinator.com/item?id=44097390 Also currently on the front page. It's mainly that this tool hits the trifecta of having privileged access, untrusted inputs, and ability to exfiltrate. Most tools only do 1-2 of those so attacks need to be more sophisticated to coordinate that.
rexer 1y ago
I think this downplays the security issue. It's true that scoping the token correctly would prevent this exploit, but it's not a reasonable solution under the assumptions that are taken by the designers of MCP. LLM+MCP is intended to be ultra flexible, and requiring a new (differently scoped) token for each input is not flexible. Perhaps you could have an allow/deny popup whenever the LLM wanted to interact with a service. But I think the end state there is presenting the user a bunch of metadata about the operation, which the user then needs to reason about. I don't know that's much better; those OAuth prompts are generally click throughs for users.

truemotive 1y ago

GitLab Duo got hit with an oopsie, "AI agent runs with same privilege to site content as the authenticated user" kinda oopsie where you could just exfiltrate private repo information via a pixel gif. I knew it would get bad, but this bad already? I yearn for rigor haha