Mackenzie Jackson: Hello everyone. Welcome to another episode of The Secure Disclosure. I'm here with Brooks McMillin. Brooks, thanks so much for joining me here today.
Brooks McMillin: Yeah, no, happy to be here.
Mackenzie Jackson: So, we're at CactusCon. You delivered a talk yesterday, so probably no surprise what we're going to talk about today. You were talking about malicious model context protocol servers, MCP servers. This is a fairly new thing. So maybe just to get everyone up to speed, what is an MCP server? How does it work in this wacky world of AI that we live in today?
Brooks McMillin: So, the simple explanation, I feel like, for MCP servers is it's almost a wrapper around a backend API to help LLMs understand what a function is used for, what it can do with it, what the arguments are, all of that sort of thing. For my example, I build my own task management system. So I can have a backend API that's like create a task. I throw an MCP server around that and you just kind of give it a big docstring right under the function in a Fast-MCP-type Python framework and can say, "This is the get task function, the arguments are like start date, end date, blah, blah, blah." And the LLM can just read that, be like, "Okay, I understand this is what this function does." And Anthropic has their API in the backend that puts it all together and it just kind of tells the LLM what it can do with the tooling you've attached to it. So it's really kind of these MCP servers. They're kind of the modern version of what APIs were like, or they kind of built on top of that. So it shares some of the similar frameworks and operations that.
Mackenzie Jackson: Yeah, it's very similar. So you have a lot of similar infrastructure setup or security setup you would have for API servers with MCP servers as well.
Brooks McMillin: Okay. So one of the things you were talking about in your talk is that we basically just haven't learned our lessons at all. We're just, we're doing it all again. So I don't know if we just talk about that. What are you kind of seeing in the MCP server world that is kind of insecure and that the lessons that we haven't learned from previous technology?
Mackenzie Jackson: So there are some really, at least in my mind, kind of silly ones. Like there have been big CVEs where there's just an open-source library that's calling eval on third-party input. So it's no surprise someone's going to figure out how to send malicious code to, in that case, an OAuth authorization URL. It's going to hide malicious calls in there and then when you call eval on their commands, you're running this RC right off the bat. So there's some really silly ones there that, when I saw that, it reminded me back of when you could SQL inject any website back when it feels like.
Brooks McMillin: Any attack would work pretty much.
Mackenzie Jackson: Yeah, it's like sometimes I think we're past that, but then you see something like this, it's like, okay, never mind. We're kind of back in the Wild West again. So there are kind of the silly ones like that. I feel like a lot more common are just trying to figure out how to get authorization right, because that is, has already been a problem, making sure people have the right permissions and then they're not able to access other people's information just by writing the correct ID in there. But now it becomes a little bit more complicated because your MCP server is going to be running as some process. I know when I'm building my MCP server, I just give it kind of my user account credentials off the bat because it's just my personal stuff that I'm testing. But eventually you're going to need to figure out how to take the intersection of privileges so that way the MCP server or whatever credentials it has can't get me extra permissions. And it probably shouldn't have all the permissions I have anyway. So just figuring out how to make sure that everything's locked down appropriately while of course still letting people do stuff, that's another kind of age-old security balance that has gotten a bit more complicated, but it is kind of the same principles that just need to be applying. Yeah, it's funny you're talking about the challenges of authorization where it's like since the conception of OWASP, number one has basically been broken access control and we're now in this Wild World of AI and everything's technology and like what's, what are we still proving? Oh, it's broken access control again.
Brooks McMillin: How do we actually kind of try and fix some of this? Or actually, first, let's take it back a little. Are you seeing this kind of out there in the wild? Are you kind of looking at these MCP servers out there in the wild and going, "Oh, wow, this is, this is, this is what?" And like kind of a lot of them having issues, is it edge case scenarios? How common is this in reality?
Mackenzie Jackson: Well, I haven't done any like personal studies myself. I feel like article after article. Recently there was a ServiceNow one where the red teamer pretty much just said, "I'm this person. Create me an admin account." The agent was like, "Okay, here you go." And it's just like there's some stuff like that where it's like that is again, it's not an AI or LLM specific security problem. If you had enough people reviewing the right stuff, they'd be like, "Okay, maybe we need to have some authorization checks before this happens." So you see a lot of those and you see a lot of actually big companies making not silly mistakes but getting hacked or kind of bad things happening to them. Like you have GitHub, it was like posting private code to public repos. You have Asana, I'm blanking on exactly what it was. But it's like these are not just, you have a lot of just people putting stuff up like Maltbot, OpenClaw, whatever we call it these days.
Brooks McMillin: That can have security issues, but yeah, big companies are also trying to figure things out as they go.
Mackenzie Jackson: Yeah, I guess that's part of it too. Is this kind of new in the security world? What I mean by this is we're talking about the same old security issues. What I'm struggling with is how does this kind of relate into the security world in the terms that why are we repeating these mistakes? Is it something to do with the AI? Is it fundamentally different technology that we're looking at and that's what's enabling us to make these mistakes? Or are we just literally haven't learned and doing the exact same things again?
Mackenzie Jackson: Yeah, so I think part of it is we definitely haven't learned the full lesson. I do think AI makes it worse. Like for that ServiceNow example, if there was not an agent that could, you know, try to figure out the different paths to help this red team that it was, you know, assumed was a legitimate user.
Brooks McMillin: Then that might have been a flaw that wasn't uncovered for years or they might have fixed it before that someone could manipulate that. But since you have these LLMs that are very excited to be as helpful as they can, it's just they will go through paths that you wouldn't even think of and they'll do it much faster than you would. So they can, it's pretty much, yeah, we gave computers the ability to be social engineered and they can do that at rates much faster than normal people can. So it's just that kind of is the magnifying glass on all the vulnerabilities.
Mackenzie Jackson: Yeah.
Brooks McMillin: Because I feel like a lot of security is good enough. We, we made this good enough. There's some obscurity that no one's reasonably going to figure out that flaw. So the priority goes down and we have to go fix something else. So it's just, I guess a shift in prioritization that we need, or a shift in figuring out if there's an MCP server or a way LLM can access this endpoint, we, we need to raise the priority and making sure that it's as locked down as we can.
Mackenzie Jackson: Yeah. You mentioned something there that I kind of want to dive into. You mentioned like, "We gave computers the ability to be social engineered." I love that. Got to steal that. But are there some security issues in this kind of in NPT service, but maybe even a little bit broader in the AI that we kind of can't get out of? So like, I give you the example of prompt injection where it kind of feels like the new version of SQL injection, right? But SQL injection we can solve. Don't even get me started on this, but like, you use prepared statements. It's solved in 1998 and we still seem to haven't figured it out. But whatever. There's some people that have the kind of belief that prompt injection, because it's kind of based in social engineering, that is kind of always going to, it's at least at some level be there, you know, because they fix one prompt injection thing and then all of a sudden people will come up with a different one. At the moment, multi-prompt injection is kind of the talk of the town. Do you think that MCP servers will be completely secure or these, this AI thing will be secure or are we going to get to close enough?
Mackenzie Jackson: So, I personally don't believe that LLMs will ever be prompt injection free. I think that's always going to be something that's there. So I think the important part is having security controls in the actual logical code you have there. Like when an LLM is calling this MCP server function, for my example, I'm running Python code there. So I can do the things like checking, "Am I trying to delete 100 things at a time?" That's probably not good. I can do more of like the attribute-based access control where you'll have to do a lot more analysis on what's actually happening, but then you can also say, "You know, this is an anomaly. Let's maybe block this or make the user need to tap their MFA key or something." But there's just as much as we can get in kind of the logical controls where we actually know and can somewhat prove what's going to happen and what we're going to block, the better. But yeah, then it is a kind of effort versus reward type balance you have to find. I feel like there's always going to be some flaw in there. You have to make sure that it's not one that has as much risk. You know, security is all about risk management. You're never going to get down to zero, but you have to figure out which ones are worth working on.
Brooks McMillin: Yeah, yeah. I definitely, and also like, adding layers in that, like to it. So, with that being said, like, where should people focus on if they're building MCP servers to try and, like, if we can't get to 100% locked down now, what are the big ones that people need to focus on to try and at least get some level of security things right?
Mackenzie Jackson: So, authentication's always the big one. Just making sure that if I have an LLM doing crazy stuff to my account that it can't bleed over to other people's accounts, and in some service there. Other than that, I mean, I always like the idea to kind of start slow, build up, make sure you know what you're doing first.
Brooks McMillin: Don't give AI access to everything. Is that what it is?
Mackenzie Jackson: Yeah, start off in like a read-only mode and be like, "Okay, we'll see what happens. We'll see what logging we have in place. We'll see what kind of behavioral analytics we can start getting for how LLMs interact with this and then gradually be like, 'Okay, now maybe you can edit and create stuff, but we want deletes to still be through the portal or human interaction type flows.'" But yeah, I feel like everyone was just in a race to be like, "Here's our amazing product. If we're out, use it." And you know, that's really cool. I love, I love the idea of OpenClaw.
Brooks McMillin: Yeah.
Mackenzie Jackson: But it does sound amazing, but it's just kind of spit out there so fast that there's been very little, if any, security hardening that's actually been done. You can kind of see it. I'm in the same boat. Not going to be using OpenClaw to answer my emails anytime soon. But fascinating watching the technology, it's kind of cool. But then to your point, then ecosystems started forming around it. Like there's Clawhub, which is basically npm or pip for OpenClaw. But most of the, most of the skills or packages on there for OpenClaw were malicious. There was no way of flagging it. You couldn't remove them by making a GitHub pull request, for example. And then the founder, Peter, was just kind of like, "Well, everyone just needs to use their brain and not download it." Meanwhile, people also figured out that you could manipulate the view number by just using bots so that you could be the number one skill. So all of this is kind of like, I understand that it's cool, but you created this ecosystem and there's like, there's all of these scenarios that haven't been thought out, which is kind of like, I have sympathy for it.
Brooks McMillin: Yeah.
Mackenzie Jackson: But also don't.
Brooks McMillin: Yeah, it's kind of like, you know, the great power, great responsibility type balance. It's like, the good thing about established companies here is they feel like they have more of a reputation to maintain. They don't want that negative press where if I can just spit out a website and it sucks or it's insecure. Yeah.
Mackenzie Jackson: I'm like, "I don't really care. This was just my weekend project." Like, if you want to use it, use it. If you don't, don't.
Brooks McMillin: Yeah.
Mackenzie Jackson: So it kind of does take a lot of the maybe not accountability, but you don't have as much of a negative reaction because it's not like you haven't put your blood and sweat and tears into this. It's just kind of, you're like, "Claude, go build this for me and I'll put it up and it's cool."
Brooks McMillin: Yeah, I want to talk a little bit now about kind of like, maybe like threat modeling or just understanding the vulnerabilities when you're building an MCP server, because we're talking about vulnerabilities that whilst it's kind of like, yeah, it's broken access control, I mean, it's not something that we can throw a SAST scanner and expect it to solve it for us, right? So like, how do we actually go about understanding like vulnerabilities in this? Is, you know, like, what, what can teams do if they've got an MCP server and they're like, "Well, I think it's secure, but how, like, what activities can they do? What can they scan?"
Mackenzie Jackson: Yeah. I'm actually thinking about that a little bit more on my own. Like, I do have a lot of like static code checks and kind of, you know, static scanners that go tell me a lot of stuff that is interesting, but yeah, definitely not the full picture. Yeah. So, I'm working on more like dynamic almost like auto-red teaming stuff. If I can get Claude to just try to access my MCP server, come up with some attacks, do something, and then just see what it can figure out and go from there, because it is, yeah, hard to get the whole workflow tested, which is still my struggle. Like I can test each server kind of by itself, but if I'm trying to test like, you know, the auth server plus the MCP server plus the resource server and make sure they all kind of connect the right way, they all kind of pass privileges along the right way, that kind of full flow thing is definitely much harder. So I feel like you do need dynamic testing definitely like even if you just had some edge cases that humans go try, like, "Can I go edit someone else's stuff through the MCP server? It is read-only, but can I just write something anyways? Let me see." So that's like a good first attempt just to make sure you at least have some sanity checking in there. And I guess you could probably do something fun with like Playwright style test where it just goes and tries to do something or like goes and prompts an LLM just go do this and see, see if it can.
Brooks McMillin: Yeah.
Mackenzie Jackson: So, I guess that's the other thing is we don't think like LLMs think. So, I could try all the things I want and I don't succeed, but I could ask an LLM and if they can't do something, a lot of times they'll loop through for better or for worse. And sometimes that can cause them to get confused and you call something that you wouldn't have thought of, or yeah, like I had when I added like a random variable and gave it a minimum length, where if it didn't have that length, it spit out errors. The LLM sometimes emails me like the data that it's not supposed to be emailing me, or, you know, just makes calls because it's trying to figure it out and it's not working, but it knows it wants to execute this function for you.
Brooks McMillin: Yeah.
Mackenzie Jackson: So if you just say, you need more LLMs to secure your LLMs. It's super interesting concept, because it is like, it is one of the perfect, LLMs are kind of one of the perfect thing to test of LLM. Like, as you said, like, because you kind of need to think outside that box and I totally agree. I work for a vendor that sells SAST stuff. So, I love that stuff as well. But I'm just, you know, like, but this is like a unique thing where the traditional rule-based approach to security, the deterministic approach to security is no longer going to kind of throw it out there. Have you had like much success like testing out some LLMs to try and attack other experiments of your own?
Mackenzie Jackson: I haven't. Yeah, that's kind of on my to-do list for next steps, because right now I've been just trying to make my kind of LLM coding process more secure. Make sure that it's not breaking stuff as it goes. Make sure I can actually build stuff that's functional and stays functional and somewhat maintainable. But yeah, I definitely am working on creating a kind of red team agent that if I'm like, "Here's some stuff, here's how you can get yourself authorized," or give it some like long-term API key or some way to do something and then just let it try to go wild and see what happens.
Brooks McMillin: Yeah.
Mackenzie Jackson: Because I mean, to me, it is just fascinating to try to give LLMs the ability to just do stuff and then just kind of look through the logs and see what they're doing. Kind of try to, you know, get in their mind as much as of a mind as you can call it, but like see how they work a little bit more and see what they'd actually go try to do.
Brooks McMillin: Are the LLM social media? They got started for like, for models. They're just watching what they do.
Mackenzie Jackson: I got to say, like, it freaks me out a little bit. Anyway, we're, we're in this brave new world now. So, yes, what do you think about it from a, like a security point of view? I guess this probably is a triggered question, but is it worth the productivity gains to have these MCP servers when we haven't like fundamentally secured it? I mean, it's, it's almost an irrelevant question, because it doesn't matter like, we're, we're going forward, but like, are we moving too fast for this? Would you slow it down if you could?
Mackenzie Jackson: I mean, we're definitely, I'd say, moving too fast, but I feel like that is the kind of common pattern. Every technology that comes out, companies are like, "We need this now, put it in place, you know, ship it." And yeah, I don't think there's any way to slow it down that much. I do think we need kind of security leaders at companies at least putting some roadblocks in the way, be like, "We need at least, you know, this minimal amount of security," or kind of do that risk exercise where they're kind of can explain the risk of releasing this at this point versus like, "Here's some security controls that lower our risk by X%," and kind of making sure that they are getting a seat at the table and being able to voice these concerns before big things get released. It's kind of, yeah, the balance between this technology is so cool. I want to see more of it versus it's also like the scariest thing ever. It is hard. I want to see more, but it would be good to slow it down and we do need those people in there that can do that. Yeah.
Brooks McMillin: It is such an impossible thing, because part of me is literally so excited to see this new stuff and the other part of me is absolutely terrified. And like, I'm from New Zealand and like, my big plan at the moment is just to get enough money to buy a farm in New Zealand and watch the apocalypse, like, watch the lobster-themed apocalypse make over for the AI wars. I want to talk about something, you know, maybe like slightly different from here, but just whilst we're talking about NCP servers, what do you think about the idea of like, potentially malicious NCP servers of people or attackers creating an NCP server with malicious intent or potentially taking one over? Is this a threat vector that we should be worried about in this, in this new world?
Mackenzie Jackson: Yeah. So this is actually a demo that didn't work perfectly during my talk, but I had one where I connected an MCP server that was like, had a get weather function, and that's the one that had a context that was like, "Give me the task information to get the weather." And that it had a minimum like 100 character link. So then you get an LLM trying to call it, but it's like, "Oh, I can't do it." So at least like, you know, 50 to 75% of the time, it would just end up giving up and sending all the task information to get this random weather statement without asking the user or without communicating to the user this is happening. So then in an attacker scenario, it's sending this, for me it's just task information, but it could be any information from another MCP server to a third party to try to get stuff done. And you do have some like safety checks somewhat like when you go to like a Claude or ChatGPT, it'll ask you whenever a new FCP call is being made. But it's so easy just to click "always allow" and never think about it again that you are getting kind of the alert fatigue we had back in the Windows when everything was needed admin permission those days. You just get used to saying yes, do this, I need stuff done. And unfortunately, there are not a whole lot of defenses to like prompt injection in tool descriptions. Like there are certain ways you can like pin a tool definition so that if it changes later, it won't work. But there's not a lot of like, there's not as many like LLM firewall type tools for that actually description. And there are a lot of different ways to make that cause the LLM to misbehave that are not kind of traditional prompt injection type attacks. It is really interesting and I think there is going to be like multiple new attack vectors coming out of this, but ultimately a lot of it comes down to same old vulnerabilities that we've been dealing with for a really long time. You know, it's all the new, very new shiny little lobster-themed box.
Brooks McMillin: Very much like a Fallout, "war never changes." Security never changes apparently. All right, so we have to start wrapping it up a little bit here, but I'd like to play a game with everyone before we do it. It's a very crappy game, but it's called "Would You Rather?" And basically, I'm going to give you two very crappy options and you have to pick one. So we'll start off with an easy one to get into the flow of things. Like, would you rather use the same password for everything? It can be complex, but it's the same password for everything, or store all of your passwords in Notepad on your phone, but they can be different.
Mackenzie Jackson: I definitely say Notepad on my phone. Like this reminds me of there have been a lot of like, you know, on paper password managers that people will criticize and it's like, you know, that's not the best, but also it's much harder to compromise Notepad on my phone than it is to not have my password get leaked in a breach. Like my password is going to get leaked on some account somewhere and it's going to be out there. My phone, I'm fairly confident that unless like a state actor is after me or there's some crazy zero day that hasn't been fixed yet, no one's getting into my phone. So that, you know, I would feel much more secure that they're all different. Even if I had it all like written on a sticky note that I carry with me.
Brooks McMillin: Yeah.
Mackenzie Jackson: Actually, I do lose stuff a lot. So maybe not, maybe not that. But if there's all the clip there and, yeah, there's all like a sticky note on my desk that nobody comes into like my home office on that would still be better. It's like not the best, but it's, it's now like you have a pretty much 100% chance of getting your password leaked versus, you know, a nonzero, but much less than 100%.
Brooks McMillin: I would agree with you on this one, but this question is about 50/50 split. And I kind of find it interesting, too. Yeah, yeah. But anyway, let's go more AI-themed. You could either do all your coding with AI, but only through prompt. So you could use Claude, but you can't touch your code. You can only prompt. So just basically pretend you don't know how to code. Or the complete opposite. You write everything by scratch. We've gone all the way back to 2022 and you can no longer use any AI coding tools. Would you?
Mackenzie Jackson: Yeah, I'm kind of all on board AI here. Like I, I am working on better like coding processes. Like I did just release a blog post about how I have like pre-commit checks. So when I tell Claude to commit, it will kind of keep spurring until it fixes all the tests, gets the linting right, make sure no secrets are in the right place. Granted, it's not always perfect. It has updated a test password with my like production PostgreSQL password and converted it to GitHub and it's just like, "Why'd you do that?" So there's still definitely some flaws there, but I have like pre-commit checks. I have it creates a PR. I have a different AI kind of review it, make sure that it hasn't uploaded empty files, which sometimes it does. Like, you know, I'll get the Ruby bot saying, "This file says it has like 19 tests, but it's actually completely empty. You should go fix that." And then also like CI checks. There are a lot of checks and balances you can put in place there and just losing the productivity gain of LLM coders. Yeah, I feel like it's too much. Like I can have an idea, get Claude code on my phone to do it 10 minutes later, have a PR that mostly works and that's just like, any whim I have, I can pretty much put on my project now, which is too amazing.
Brooks McMillin: I like, I'm exactly the same. But, but that's also because my coding ability is probably like pretty crappy. Like, what about, I need to, I would do one more. As soon as you mention secrets in there, we'll do a secret-themed one. Would you rather have all of your secrets stored in a private Git repository? So you've committed your f file, everything's there, or your application has absolutely no firewall. So no way to kind of block DDoS attacks or malicious users. And that is a harder one, because let's see secrets on a private GitHub repo. You have a decent chance that won't go too bad. I mean, GitHub definitely has had some issues. It's very easy to accidentally leak some stuff through there, but not having a firewall, see, is more guaranteed, but that's also, I guess, you have more availability concerns than anything else. Like maybe your site will go down and maybe you can't block some attacks, but as long as you can build out your other defenses, that might be okay. I feel like, I feel like first thing that comes to mind would be just sticking with no firewall, because I feel like the consequences of that are slightly less. Granted, my personal sites right now, if they go down, that doesn't matter. Yeah.
Mackenzie Jackson: I feel like that's still better than all my secrets potentially leaking and people having access to stuff versus maybe I have to like turn off my servers here and there. And still annoying, but not as big of a consequence. Yeah.
Brooks McMillin: All right. I like it. I like the answers. Well, Brooks, thanks so much for sitting down and chatting with me today. I really enjoyed it and I hope we'll be able to have you back on the show and see some great new talks and research you'll be doing.
Mackenzie Jackson: Sounds good. Yeah, pleasure to be here.
Brooks McMillin: Thanks so much.
Mackenzie Jackson: It's AI lipstick, but the actual underlying threats or the issues that enterprises are facing are really not new. Where is AI like really changing the rule set of the game at the moment? Where is it kind of like, where has the game kind of shifted in the last couple years? Prompt injection is a net new type of cyber threat that enterprises have to be cognizant of. How many of us actually know where all our sources of structured, unstructured, and semi-structured data is? Let's start there. I don't want you to raise your hands because I don't want to be depressed. Organizations care about all risk. AI use is not going away. If organizations in this day and age are still trying to prohibit the use, that's just a fool's errand in my opinion.
