Infection Monkey Vulnerability Scanner with Daniel Goldberg

Hello, and welcome to podcast dot in it, the podcast about Python and the people who make it great. When you're ready to launch your next app, you'll need somewhere to deploy it, so check out Linode. With private networking, shared block storage, node balancers, and a 200 gigabit network, all controlled by a brand new API, you've got everything you need to scale.

Go to podcastinit.com/linode

to get a $20 credit and launch a new server in under a minute.

And visit the site at podcastinit.com

to subscribe to the show, sign up for the newsletter, and read the show notes. Your host as usual is Tobias Macy. And today, I'm interviewing Daniel Goldberg about InfectionMonkey,

an open source system breach simulation tool for evaluating the security of your network. So, Daniel, could you start by introducing yourself?

So my name is Daniel. I'm a security researcher at a

cyber security company called Guardicore.

In my day to day job, I look at malware,

look at reverse engineer vulnerabilities,

and try and analyze

more weird interesting network threats and the possible defenses.

In my spare time I work on the inflection monkey, which is something that started out from, hey, wouldn't it be cool to and turn it into this rather cool open source project that is pretty we work on actually getting people to

pass the basic bar of security

rather than just focusing all the time on sexy stuff. Other than that, I'm

a programmer by trade and a hobbyist

as well.

This is what I enjoy doing, and, you could say,

as a luck of having my job is is my hobby.

Yeah. I I can relate to that. And, so sometimes I spend more time on the computer than I should. So,

and do you remember how you first got introduced to Python?

Pretty sure, yeah. I remember that. I was 17.

And the firm pretty much told me,

you need to try this thing out. Stop working with all these,

complex,

verbose languages. I was then a c sharp programmer, and he was like, go check out Python.

And he sent some online tutorial to me, and to do this, and then try out writing this kind of stuff in Python, and then try it again in c sharp and I got hooked. This was back in Python 2 something,

and I was pretty much clueless. But I got a lot along with this language.

And as they said, the rest is history.

So a quick follow-up

to the question you asked me. 1 of the advantages of starting out at just that time is I got a really high reputation stack overflow question, it was just being a complete noob question.

But back then, stack overflow was all this new, and every question was like, oh, it's never been a duplicate before.

So I got a way of asking some really silly questions, and these days they're the canonical Stack Overflow answer.

So could say that's the advantage of

starting out,

in the right time, in the right place, I guess.

It's funny how, how often that's the case where you you answer something that you think is simple and that ends up being

massively useful to everybody because it's a problem that everybody passes through at some point. Yeah. It's also like, it got me into

a serious habit of not assuming that my question is stupid. I'll just ask worst case somebody refers me to an answer.

And so,

can you discuss a bit about what infection monkey is and your initial reason for building it? So the infection monkey, the fancy name it's a breach

simulation tool.

What this practically means is

it's a security tool that, that tests what happens when you're actually breached. Blaine in a story ways there's a lot of tools that say are you vulnerable,

to different types of attacks. There's very few tools that say, okay, your network got breached, now what happens?

Attackers got in, what can they get out? What can they do? Where else can they move from? And the idea was to write this simple tool that's gonna check just the basics

and be able to help you answer very simple questions such as, am I reusing passwords?

Am I actually patching systems?

Are my firewall rules actually effective?

Because the security landscape is full, like an enormous amount of tools that are incredibly fancy and check the latest and greatest,

and very few stuff actually works on

is the basics,

up and running?

Are you doing the proper things? Are you even patched? When we started out as a project, it was still a bunch of servers back from 2003 still vulnerable to decade old vulnerabilities.

And now's the prime motivation. Let's get the basics. Let's write a tool that doesn't assume

you're under attack by the NSA,

but

you're under attack by ScriptKitty

and most organizations are not prepared for that. Regardless if they're a fortune 1, 000

or they're a university

in the middle of Washington.

And when you first started working on it, did you have any particular motivation for choosing Python as the language for implementation?

Or was it just because that was something that you were familiar with? Or did it have any particular facility in the problem domain that you were trying to address?

So

the answer to that is pretty,

is a few steps. 1 is, of course it's easier to do it in the language you're most comfortable in. I'm fluent in c and Python, and I'm not gonna write any

complex networking tool in c, that's an invitation to a headache.

And the second is

Python's community approach of

batteries included. There's a package for everything meant I could

really focus on get up and running quickly and not deal with

stuff like a proxy server or an HTTP

handling or anything like that, I could really get

get myself rather quickly to a point where, yeah, I'm attacking, I'm displaying stuff, I'm processing information in the back end. The entire information in the back end. The entire pretty much 95% of the code is written in Python. There's a few lines of c

spread around.

This is in the attacking part itself, and

the key thing is like I can just focus on logic. If I need any type of library, somebody's already built it. The biggest alternative there was to say, am I gonna build this on top of other offensive tools? And the answer was 95% of them are in Python and only 1 of them is in Ruby,

which was then the main alternative. And I was like, no. I'm not switching languages just for that. And do you think that if you were to start the entire project over today that you would make the same decisions in terms of the language implementation

or the overall system architecture of it?

I think today,

for what I would definitely stick to Python, but I would seriously consider

in hindsight

building in Ruby because that would give me the ability to build off

what's considered today the gold standard of attack tools, Metasploit, and it's written entirely in Ruby.

But

overall, the decision to build in Python has been good.

I have been bitten

in a bit by the decision to build it in Python 2 and not start out from scratch in Python 3.

I'm getting less support for stuff I wanna do today which is async communication,

and modern libraries are becoming more and more Python 3 only.

But overall I'm pretty happy.

We are having downsides of just designing it to be quick and dirty. And now as the project grows, you could start paying the price for all these design decisions you made

a few years ago.

And so with that, can you

talk through a bit about how the project

is actually implemented

and some of the architectural decisions that you made early on and how those have evolved,

while you've been working on building and maintaining the project? So

I'll try to touch on this different directions.

The

the infection monkey is built of 2 main components. 1 is the monkey itself. That's the code that actually goes and attacks computers and propagates.

And the other is the monkey island, which is a command and control server in security speak. It configures and controls the monkeys remotely.

It displays a user interface,

to let the user configure the monkey and track what it's doing and see the results.

And

probably the biggest pain that we have is those are 2 probably separate systems. They don't share any code, which it makes it far harder to expand anything. Because

the monkey you wanna have, it has a bunch of capabilities of how it can attack new machines. And probably the biggest design decision I'm regretting today is

it's not very easy to plug in new features.

Modern tools have pretty much like, oh, 0, you just plug in, you leave a single Python file or module in the right place, and your code just knows how to display it and handle it.

We're far off from that. I end up having to modify a lot of files in different places

to get new features in and

to probably get all the way to the user interface.

The user interface itself is also a mix of the back end is entirely Python but we ended up building the front end in React,

which is a JavaScript based lang framework. And

that's been pretty frustrating because we end up having to define the same structures and

the same interfaces

again and again. I'm not sure what would be a better solution, but that's definitely something we're eating a lot of pain over. And

in the particular problem domain that you're addressing with penetration testing, that's typically an area that requires a fairly substantial amount of knowledge and experience in terms of the security practices and the ways that exploits are written and executed.

So I'm wondering what have been some of the most difficult aspects of building a system that is intended to automate a lot of that process

and making it usable and accessible by people who don't necessarily have that same level of expertise.

Probably the biggest challenge is this means saying no to a lot of features that people want us to want me to add or stuff I wanna add.

Because in order to have an easy to use tool,

this needs to be a simple and safe tool. Simple means I don't need to

to involve you as the user with all the little details of what exact exploit am I running, with what parameters, and how exactly do I separate between Windows and Linux and different types of Linux machines. And safe means you need to be able to run this in your network and say, okay,

this is safe to run,

this is good enough,

and you're not worried that it's gonna crash your servers or it's gonna take up too much CPU time. And this means that a lot of the more advanced stuff is just not in the monkey.

I cannot add

latest and greatest complex exploits because

they have a probability of success.

And the difference between

my automated tool and a human penetration tester

is the human penetration tester can call ahead and say, I might crash the server, is that gonna be okay? The probability is 1 in a 1000. If it's an automated tool it can't ask those questions,

So we decide to on the side of caution and say,

I'm not doing that. I'm not adding these

attack exploits because

I don't have a way to get the user's consent

in real time. I don't want to have a situation when telling him, yeah, your network stopped working because you ran

some unsafe feature. The other part is

how do I give the right information? I don't wanna overload the user

with a lot of technical details. I want it to give the user very simple. Here's the to do list of what you need to do in order to fix your,

to fix your network. And that requires a lot of

creativity and how do I phrase the results,

how what exactly am I gonna tell the user. I don't wanna tell him the exact details of how I breached something.

I wanna tell him, this is what you should do. You should patch the server. Here's the exact command you need to run. And in the security space,

in particular, there's a lot of constant motion and evolution in terms of the vulnerabilities that are present in various systems.

And I'm wondering what mechanisms you're using

to keep a deployed instance up to date with new exploits so that you can test for them in the systems that are being

run through the infection monkey? K. Unfortunately, the short answer is currently,

I don't have any sort of auto update system.

This is something I do wanna do later on probably in the next version I'm gonna release of this tool. The reason is twofold. 1, I haven't gotten around to it. The second is it's a lot harder to convince people

to run-in these tools. People are might be happy running open source tools, but if you tell them this is an automated hacking platform and

it's gonna auto update itself remotely,

that a lot of people have talked with have been freaked out of like, how can I trust this? How do I know you didn't put a backdoor? How do I know this isn't gonna suddenly change and start running around in my network? People have a far higher skeptical bar of running this sort of software.

So I'm very

careful on how I how am I adding any sort of communication with the outside world by the monk by this tool.

For example, currently it doesn't talk with the Internet at all. If you install it, it's gonna run on your network

and then most it's gonna do is gonna try and talk to Google to see if it's Internet connected, but I don't do any follow-up of that. So unfortunately, the answer to that is no.

The more interesting answer is security wise,

it's rarely the latest and greatest. We hear again and again of hacks happening

because companies just don't patch their systems in time not with anything up to date but years old stuff.

You might have seen in the news all this not Petya,

stories going around. There's been a recent story going around covering the incident again. Everything that happened there was due to password reuse

and lack of network segmentation. There was no modern

trade craft or latest and greatest exploit happening there. And some of the other systems that I've come across that seem to be in a similar space to what you're doing with InfectionMonkey

are things like Nessus or Nexpose. So I'm curious how the work you're doing with InfectionMonkey

compares or contrasts to those? We're in a similar space

and Nessus is easier to explain.

The biggest difference is Nessus is a vulnerability scanner. It looks at the machine in your network

and goes according to what I can discover remotely,

you're vulnerable. And what that means is that it doesn't do anything active. It just tells you I could've breached in but we don't know what happened.

And the difference compared to what I do is by actually trying to exploit it, I'm not just saying are you patched or not, I'm also asking is your security software working? Because

you might be unpatched, but your security software is good enough to detect and block my attack.

It could also be that

you're all

you're all considered very safe, but because of password reuse, it can still break in.

And once I've broken in which is a default assumption today in security,

then

are your internal security solutions actually working? Like your company today are paying 1, 000, 000 of dollars a year on

so many different security products, and they're not getting their money worth because it's very easy to bypass them.

So the infection monkey goes and says, I'm gonna be the dumbest tool on earth,

and we're gonna see if your software picks it up. And the answer is unfortunately to that is usually no.

A lot of these tools that exist commercially

just don't detect the simplest possible attackers.

And that's a big difference, like I'm not just checking can you breach, but I'm saying, assuming you've been breached, what happens next?

Can you recognize

where I broke into your software? It broke into your system, and I try to scan other machines, and you didn't pick that up.

So

what it gives you a security software because you have to assume at some point somebody's gonna break in. So that's kind of like the difference between

in the infection monkey

and most vulnerability scanners.

And so when somebody is running a scan, what are some of the types of vulnerabilities

and information

that the infection monkey can discover and exploit?

And how does that information then get relayed back to the user once the scan is complete? Okay. The infection monkey

does

a few

different layers of things. 1, it tries to exploit the local machine it finds itself running on by stealing information.

For example,

a password credentials,

SSH keys,

all these types of secrets that you keep on a specific computer. It then tries to scan the local network and attack different machines either through a variety of password reuse mechanisms

over SMB, SSH,

or tries to use classic

well known vulnerabilities

such as Shellshock or Samba Cry or different

web based vulnerabilities I've been in news lately like struts or

now or, we got Oracle WebLogic exploit coming in. Once it gets to a machine, it breaks into a machine.

It asks the question, can I from this newly breached machine communicate back home? Which is a place holder for the question,

can an attacker after he's breached

exfiltrate data without you noticing, without you blocking it? So this is what the monkey ends up doing, and what we display to the user

is some sort of summary saying,

I managed to breach this machine with this exploit,

here are the exact steps you need to do to mitigate that. For example, patch this, block that,

or note, or more high level conceptual notes such as there's password reuse, I discovered a password used on this machine that I could use to break into that machine, and that made makes no sense. To do so, so please change 1 of these passwords. The whole focus is on trying to give the user actual recommendations. Not something generic of, oh just patch your systems. I'm saying exact systems, the exact steps they need to patch, and what exact software is broken or out of date. And then when you report that back to the user, do you use some sort of, like, happy unicorns and rainbows emojis? So that they don't just immediately break down and cry and wanna go hide in a hole with all the things that they have to patch? I need to add the unicorn emojis. I'm gonna bring that up in our chat room.

I am so good. I'm happy that Tati is like, pro having that kind of stuff. What we try to do, when I say we I mean like a bunch of developers working on it, is

to try to have very clear and understandable recommendations. Not saying your entire network was breached, everything here is crap. Find that sometimes being the case, but saying here's a very visual map of what happened

over time,

and here are the exact steps per machine,

and we try to present it in a clear and like not you screwed up or, you're vulnerable to this, but this machine is vulnerable to x y zed issues.

Each 1 of this could be fixed with 123 commands. But yeah, in any large network that report is gonna be somewhat scary.

I think we try to make it better by having it be easy to break down. I have it easy to for like, somebody to read

and understand.

And when you're running the scan and

moving through the various systems

and propagating

throughout the network by

leveraging some of these vulnerabilities.

What are some of the techniques that you use to ensure that you don't accidentally

cripple the system and that you can roll back

the exploit that you're creating on the system?

The answer to that is 2 is twofold. 1 is we try as much as possible to avoid

using anything that's statistical or likely to cause harm.

This is why I'm avoiding

and will continue to avoid adding any,

what's called memory corruption style vulnerabilities because

they are by definition statistical

and I don't wanna ever be in that situation.

The other is to have the monkey

very well documented steps it's doing and to minimize its impact

and not leaving a bunch of files laying around

the the victim machine. It's all very clearly laid out. The monkey lives in this in this file. The log file is here. If you wanna wipe it, we avoid any techniques that could destabilize the system such as adding yourself to startup or running

a CPU intensive computation

on a victim machine.

Anything like that is sent back to

the command and control server,

which

we assume and tell people, like, this should be a server that's actually running just the infection monkey the infection monkey island or a command control server.

And 1 of the other questions I have is in the name, I'm assuming that that's a nod to the simian army approach that Netflix has taken with the idea of chaos engineering.

Yeah. So we start out going a lot from the chaos engineering approach of saying the our basic approach is the same of saying

saying, what happens if you're breached? Don't just assume that's never gonna happen, just assume it's gonna happen.

But we try and shy away from saying, yeah, we're just gonna break your network and and you're gonna have to clean it up because

Netflix can pull it off because it's a huge company that can afford,

to have a few percent,

of what they're doing

stopped working.

Most companies are not that well engineered.

So our approach has been more and more to go, here is the very safe and secure method of running this. Here's the very well defined results of what's gonna happen.

What we do leave open and that's just how their network is gonna be let out is just how far the monkey will breach, how how many steps will it take inside your network, but even that is very controllable.

You can tell

it go up to here and no further or these are the machines you should never touch. You mentioned

that you avoid exploits that are statistical in nature or that have a high probability

of permanently affecting a system.

And it seems that in some cases, that might actually be useful

to run through those tests as long as you can do it in a controlled nonproduction

environment. So have you considered adding some sort of,

flag that you can set to say, you know, with big warning letters, I understand that I'm going to break everything

to give people that additional information about,

whether they're exposed to those particular types of vulnerabilities?

So the

break glass in case you wanna do something features something we've thought about. I'm not saying I'm

in principle opposed to it, but

we're in the end a small open source project. It's not like there's 10 people working on this full time and I think I wanna work on features that people are actually gonna use. And so if something I'm necessarily gonna have to hide behind warning buttons. If somebody's gonna come up and say, hey look I implemented this, here's the pull request. I am gonna take it right away. But I'm currently just thinking there's so many more logical exploits and types of attacks that I've still not near

done with that. I don't feel like I need that to get it around. Networks today are pretty much

full of Swiss they're like Swiss cheese today even without doing anything fancy. And are there any aspects of network security or system vulnerabilities

that infection monkey is unable to detect or analyze?

We pretty much avoid anything relating to what happens on the endpoint machine itself.

This is not a test for your antivirus software.

We focus pretty much entirely on network and pretty much servers because

honestly that's where the interest is. This means I don't have I don't deal at all with IOT machine

devices.

I don't do phones.

This is very much focused on you have your Linux, Windows, data center, and

and that's full of holes before we start working on everything else.

That might be in the future, but I'm saying like

I think this is more than enough to chew off and most people worried really about security are worried about that stuff, like where they keep their their data. Yeah. Once you start branching out into

phones and IoT and edge devices, you might need to,

start,

sub subspecies

versions of infection monkey. Maybe the IoT can be the infection capuchin.

Yeah. I'm like

I'm not

with a lot of stuff, I'm not opposed if somebody comes up and, like,

we were now working,

with the Google Summer of Code we worked over the summer.

And someone came up and said I wanna add some exploits. And I'm like, even if it's not part of the stuff I most want, yeah, come on. Come in ahead. That's the fun part of an open source project.

You can come in and do stuff that fits in and we'll just take it.

But it's like it's not something I'm going for.

I am hoping somebody's gonna fork the monkey and do cool stuff, but that's not happening unfortunately yet.

And for somebody who is interested in using infection monkey in their own environment,

what are the steps involved in setting it up and starting it running?

So the easiest thing to to do would be,

we offer in in our GitHub page,

pre prepared,

Debian,

packages,

which will install the infection monkey command and control server

on any machine. And you just set it up, browse,

configure it with, with your network's

IP address ranges, and just click play. That's gonna be the simplest way to get up and running. And we also ended up packaging

a bunch of versions for like cloud vendors and stuff if people

feel more comfortable with that. But

that the easiest way to get up and running is go to Github, download the package and just get working.

The workflow is pretty much you turn on the web page, you browse to the command control interface, it's all web.

You tell it I want to run it on this and this IP ranges.

You click play

and

starts running up.

Infection monkey is also it's not fully automatic, it's semi automatic. So you're gonna run a scan, you're gonna see results.

Hopefully you're gonna fix them, then you can run it again and again. It's not a complete, leave it in the background. It's something that you run

and see,

something you run, see the results, and go back again.

And does it keep track of historical results so that you can see over time as you progress

to improve the overall security of your system? And then you can see where you started and where you've been so that maybe you can guard against regressions?

That's actually a good idea,

which is a nice way of saying we're not there yet.

We should do that, and I pretty much know how we're gonna do that at the code level. But, no, we currently don't have a way of saying, oh, look at how much you've improved the last,

the last few runs. And when you're running a scan, is it generally done as a black box or gray box where you either don't provide any sort of information or credentials ahead of time, or you can lay out, you know, use these credentials, and these are some of the hosts that I'm targeting?

So you can run it completely black box of telling it, here's the network, go play. But the most effective results is gonna be if you do it a bit gray box of telling it, here are maybe some machines you wanna focus on,

on attacking, and here are some old or unused passwords that we might have not rotated out. Like to precede it ahead of time with some details about your network. But still they're very high level. It's not you don't need to know

what your security is like in order to run the monkey. But the best results are gonna be with still some sort of So what I said before like it's you can run a black box but you're gonna get the best results

by,

by being a bit involved in the process.

And

for the reports that you generate,

do you have any capability

of maybe listing off in terms of compliance

regulations that somebody might need to be,

focusing on that these vulnerabilities

will prevent you from passing these reviews or something like that? The answer is gonna be kinda yes,

but we don't make it a feature in the report. We don't point out

this part is PCI or HIPAA compliance.

I don't think I know enough to say this is definitely gonna fail your PCI audit.

We do have some stuff like that, but not enough,

that pointed out. So I wouldn't say this is not a replacement for a com for a compliance scan, but maybe we'll get there like this is an interesting idea. Might get more people to use it. If I can say this is equivalent to running a compliance.

And are there any particular

areas of expertise

or

knowledge

that you would find particularly helpful for anybody who's looking to contribute to the project? If anyone is planning to contribute, I would

say I would want people who are who know about network vulnerabilities

and know how to implement them.

That's 1 group. The other would be

good Python programmers who know how to use the data we have and analyze it. For example,

the PCI stuff you suggested, we probably collect enough information, but just nobody has bothered

to write up a report

component that's analyzing these results.

And,

and, like, seeing

seeing yes, no on PCI. We're just not analyzing it,

which is a shame. Like, you're right. We should probably do that. Just takes more programmer time.

And what are some of the plans that you have for the future of Infection Monkey, whether in terms of community engagement

or feature additions or bug fixes or anything like that? So in the short term,

we're right now if anybody looks at the pull request activity in the code

is we're working on getting a release out of that's gonna include a bunch of new attacks and analysis.

A lot of it pass the hash and some recent,

web vulnerabilities have been making the rounds, such as, Hadoop remote control attack and stuff like that. However,

long term,

the goal is to just try and keep pace with what people are worried about. We wanna get it to securing Kubernetes

clusters

and understanding more the attack surface and containers of saying, oh okay, here's it. I have access to a kubernetes control panel, what can I do with it automatically?

How can I continue infecting the network? What's gonna happen?

That's a future plan but generally the stuff that we always want is

more exploits, more analysis,

and based off the existing stuff. I would also say if there's anybody who wants to pick up the torch and do a rewrite so we actually can have easily usable plugins The Python level, that's gonna be a code designer we're gonna need somewhere

like, it's not hard. It just takes a lot of code change, and the code change is always hard when you're been

into a project for 2, 3 years. You you start, like, being you start empathizing with your coding. You're like, I don't wanna throw it all away already, but that's probably what should happen. And are there any other aspects

of the infection monkey project or network

security and vulnerability scanning

or anything along those lines that I didn't ask about yet that you think I should have?

I think

the question should be why is such a simple project so effective should always come up. Because the infection market when you get down to it is

really testing the basics of network security. We're not doing anything

that really requires a human pen tester.

And the shameful part is just how many places that I end up seeing this run-in

don't pass the basic security bar. So many of them are just like okay,

we can't even get a handle on our own networks and the infection monkey

without any thinking just blows apart the network. And that's kind of a shame. The infection monkey is pretty much, it's

a really cool project but it's more like kind of a certificate of failure

if it runs and succeeds in your network and that's more I don't know if scary or embarrassing is the right word to put it.

Alright.

For anybody who wants to follow the work that you're up to

and get in touch, I'll have you add your preferred contact information to the show notes. And so with that, I'll move us into the picks.

This week, I'm going to choose a band that I've listened to for a long time that,

it's called Darkest Hour. It's on the heavy metal side, so I'm sure a number of people won't necessarily wanna listen to it. But if that's the kind of thing you're into, they're definitely to listen. They're very technical and precise in their sound, and they've been going at it for a while. So, yeah, go ahead and check it out. And with that, I'll pass it to you. Do you have any picks this week, Daniel? Yeah. I have a pick. I have probably,

the most influential 2 page I've ever read in my life, which is

something I read out that came out of the University of Chicago, which I thought about how complex systems fail, whereas systems are not something that's human or machine necessarily, but they're all interconnected. And the paper is called how complex systems fail. That's just the title.

And so clearly explains so much of what we're seeing day to day that works and doesn't work that it I'm really impressed and has really changed my look at

society in a way. But there's no doubt your music suggestion was way more fun. I'm gonna listen to that. It just depends on your definition of fun. I I I googling it right this minute. Alright. Well, thank you for taking the time today to join me and discuss the work you're doing with Infection Monkey.

I'm definitely planning

on unleashing it on my systems and seeing how afraid I should be. So thank you for that, and I hope you enjoy the rest of your day. Thank you very much. Goodbye.

The Python Podcast.init

Summary

Preface

Interview

Keep In Touch

Picks

Links

The Python Podcast.__init__