DATA DUPLICATION VILLAGE - Owning GlusterFS with GEVAUDAN
Cáseres, Mauro
Gluster is a free scalable network filesystem. Using common off-the-shelf hardware, it allows the user to create large, distributed storage solution for media streaming, data analysis, and other data and bandwidth intensive tasks, thus providing a nice alternative to create a data replication pool easily. It was acquired by Red Hat in 2011, and merged into Red Hat Storage server in 2012, while still available in the open source world. Gluster itself doesn't have a large vulnerabilities history, having only 6 vulnerabilities reported in the last 6 years (2 of them after being bought by Red Hat). In this talk, we'll focus on the latter two, releasing GEVAUDAN, an exploit for newcomers to the gluster world to learn about it's architecture and security, and the implicancies of proper access managament on replicated data systems. This is a talk for begginers from both fields: data replication schemas and exploits writing, so both fields will have a proper introductory section. A live demo will take place during the talk, and the public can actively participate.
 So thank you for our second talk of the day. This is Maro, he's going to be talking about owner Gluster VS. Make sure you ask him about the exploit he has. Hey, how are you? Well, this is a talk, it's a really beginner friendly talk. It's about exploiting Gluster, CVE 2018-188. It's an authenticated access to every shared storage. This is a talk that I wrote having in mind for those who are new to both boards exploit writing and data duplication in fact. So the entry point for many people into the world of data duplication is Gluster. And I also found that it was really easy to write an exploit for the CVE, so I wanted to share it to everyone who's interested in writing exploits in the future. So I want to ask for your pardon in advance for my pronunciation. Might not be the best, so if something is not understood, write your hand and I'll try to repeat it. So let's start. Brief introduction of who am I and what I'm doing. I'm from Argentina, I was born in the 90s, I work at the government office, I own a really small company related to Infosec in Argentina and well, let's get going. For this talk, I wanted to build a lab on mirror machines but I decided Docker because a recommendation from a friend. So anybody here uses Docker? Fine. For the rest who doesn't, it's really easy going, it's really easy to understand. This talk is mainly a hands-on lab. So I understand many of you won't want to connect to the Wi-Fi network, many of you won't feel comfortable downloading an exploit for a repo. Most of you won't feel comfortable using Docker here in this environment. So it's nice if you don't want to follow it, you can download it later. I'll try to follow that lab here like a live demo. So okay. A quick start on Gloucester for everybody who doesn't use it. Gloucester is a Scalable Network file system. You can use any hardware, any cheap hardware you have to run it. It's, as I said before, it's a really good starting point for those interested in data duplication. You can duplicate almost any data. We have almost any data on any hardware, I mean. We have succeeded using it on really, really humble hardware, Raspberry Pi's and the like, all laptops and so on. And even we have used some USB drives to clone and it worked like a charm. It was acquired by Red Hat in 2011, but it's also available in the free world as an open source tone. So as I was saying before, anything, anything can run Gloucester. It's really hard to see something that doesn't work with it. Call it FreeBSD, NetBSD, OpenBSD, whatever, even Raspbian. Anything you want can run it. In this talk, we'll set up Gloucester as a simple replication service. We won't enter into that hassle of configuring complex things. The bug itself, the vulnerability, it's really, really silly in fact. So we will build a simple lab, nothing complex. Our minimalistic setup will have two Gloucester nodes, a volume for each node, and a single brick for each volume, and a bunch of test files. What does a node mean? Any server or computer that holds one or more bricks? The bricks are the basic basic unit of storage in Gloucester. And a volume, it's a logical collection of those. Every file resides inside bricks. You can think of them like a sort of shard directories. I know it's not the exact definition, but it's for having a simple idea of this. Bricks compose volumes. All operations will occur at node level, and will propagate accordingly. This illustrates basically everything I say before. You have the amount point on your operating system, replicated volume, volume, sorry, and the files on the bricks. A quick start on Docker for those who haven't used it before. Docker is the company driving the container moment. A container platform provides all the pieces enterprise operation requires including security, governance, automation, support, atomization, and certification. This is the definition provided by Docker itself. Let's suppose we have virtual machines. You can have an app like, okay, I will separate them in a VM for the app, a VM for the database, and if you want a VM for the file systems, if you want, containers are different. As they are oriented for microservices, they made the target is to have a minimal functional unit. On a container base infrastructure, your app, the same as before, may look like this. A backend app, just you'll have your custom binaries, your custom libraries, and your app. Nothing else. The web server, you might have a container for Apache, for NGINX, for whatever you want. And the DB container might have just a DB engine. And even it might not hold the database itself, the data files. Here we have a comparison. As you may see, you're just using your custom things, your custom application, your custom binaries, your custom libraries on your container. Everything else that you use online is shared among across all the containers. Okay, a common question is what are my configuration files? We won't use them in this case, but it's a thing that always troubled me when I was learning Docker. If you follow the best practices, you will store them in an external volume. And you can even share all your config files across all your containers. So you can have a better control of your configuration files. Say, okay, this instance is configured that way. Okay, every one, every instance will be following that policy, if we want to call it like that. Okay, there was, Docker uses run C. You might remember a slip container with runs in the same operating systems. They have also features layered file systems. Okay, the binaries, even if you're using Q-Stone ones, the classic unique user land is shared and every label along all the containers. Okay, we'll build our hands-on slab. Once again, I know you may not be comfortable doing this line right now. So, okay, no problem. I'll have a live demo here. The Docker containers. You can easily install, I love doing install, APT install Docker, Git, and last-reference client on that specific version. This obviously works for JOM or DNF based distros. So no problem, even for free VSD. Okay, I have sent out my repo, giveoutdown on git have.com. You can simply build the image, target whatever you want. The target is the name you're giving to the image itself. Giveoutdown cluster. It should be run in a privileged environment because cluster requires to do so. You can run most of the images or Docker files around there without any privileged user. So this will give us an instance ID that you can use it to identify that container. The magic of Docker is that you can run as many instances as you like or as you can of the same product. So if we run this command or Docker run, privileged through, twice, we will have two instances of the lab. If we run it three times, we have three instances and so on. This is really useful when you need to have, obviously, configuring something atop like a file over or like a distribution. Using the command Docker PS, you can see a lab. They're both running with different IDs, obviously, and what they are doing. I would like to share with you the Docker file. So you can see how easy it is. It is built. Sorry. This is our Docker file. As you might see, this is the base. From the stretch, we are pulling an already made image. We just run update, install, without prompting, the vulnerable version. We purge everything that we don't need. Docker points to microservices. So we need to have a minimal setup of every container. And these are the custom configurations to make the cluster volume directory, to have it absolute access for this test, to run cluster and to change the PS1 just to look like the one assured here. Sorry. The PS1 thing is something aesthetic just to have that way here. Okay. As you might see, we have both containers running. We can enter the containers just doing that command. Docker exec TI is for executing on interactive way. Bash. So we have the IP address of every container. How do we set up Gluster for this? As we have two containers, we'll call them server A and server B. We can enter server A and issue the following commands. Gluster prove server B. This is for turning the server A. Recognize that one. Check if that one is running a cluster instance and pair with it. Gluster pierce status. And on the other side, too, Gluster pierce status. We have something like this. As you might see. Prove, yeah, it's working. Starrows, yeah, I have a pier. This is my new pier. From the other side, we don't have to pair it again. Starrows, number of pierce one and a unique ID. So they are recognized as partners. Remember, they are vulnerable versions. They are already patched up. So don't keep these containers for anything more than testing. Okay, let's keep going. We have to create volumes for this. Gluster volume create dev convol replica two, transport TCP, where server A on this mount point. Remember in the Docker file, we stated to create this mount point. It won't create it if it doesn't exist. Then on server A, again, Gluster volume start dev convol. So start this volume. And Gluster volume info from the other side shows to check if it found it. You might see these are the output from the comments. Success, start the volume, restore it. And this one without further interaction knows where it is located and starts to replicate here. This lab is already set up for replicating. So on a client, on a desktop, laptop or whatever we are using outside the Docker, we make our mount point give out on puck. You do mount Gluster FS, where on server A, dev convol, as you might see, we skip it any path, just dev convol. Where, mount it here, where we just make the there. Mount give out on puck. This will create, this will, sorry, this will mount a recently create volume. Then on our desktop, echo data duplication buildage to mount give out on banner.dat. This will make the replication to happen. So we'll cut the file on both nodes and check it has replicated, in fact. As you might see, here we create the file, cut, work it, cut, work it. Not further interaction. It's really easy for people who are newcomers to this world. I am, in fact, a newcomer to this world. So I found it really easy to get myself involved with in Gluster. Now, if everything went the right way, our lab is replicated. But it's not vulnerable, but see, still. So let's destroy it. This for everybody who's not into the container moment or, it's the logic behind Docker or behind any microservice. You run, it fails. Okay. We respond and we keep running. The main point in Gluster is to be recycled, to be constantly reissued for saying it on a certain way. Okay. Let's use give out on to on Gluster. First, I want you to understand what the CV is about. This is a new CV. This is from May. I wrote this talk in June. It was patched just some day, I think, two or three days after it was issued. It was a really silly bag. Give out on Gluster and viral vulnerable authentication for data access and new it's an exploit for Gluster FC 1088 and 1112 right in Ruby. Basically, this vulnerability allows any Gluster client to connect without any authentication to a shared storage volume. In that shared storage volume, it's Gluster on it, resides the task scheduler. And by modifying that specific file from the scheduler, a Chrome file, I think we all know how Chrome works. Okay. It's a Chrome file. You can schedule arbitrary commands and tasks, whatever you like. This allows many actions from the privilege escalation to total data compromise or nuke. As you might see, this is using the tool DevSecand. It tells you what vulnerable packages you have and what are those vulnerabilities that reside in your system. As you might see, these are the only ones we have, Gluster. Both from the client and from the server and from the common. In order to exploit this, the shared storage feature must be enabled. It is not enabled by default now. It was in the first versions. It was vulnerable historically. So you should explicitly run in your server. Gluster volume set all cluster enable shared storage enabled. We checked it started running. Gluster volume get Gluster shared storage. Gluster enabled shared storage. And then the snap scheduler should be enabled. It is a Python script. Snap scheduler in it. As you might see, this might seem like a complex configuration, but in fact, many enterprise sites already are using this. It is, it might seem something complex for someone like me who doesn't use Gluster for something bigger than a simple proof of concept lab. But every environment from media and app uses this feature. So success. Here we see this, the option enabled. We start the scheduler and says, okay, the snap scheduler is running. But it doesn't only cron snapshots. You can cron wherever you want. In fact, if you use any interface or even the command line, you can pass any arbitrary task. It doesn't have to be a snapshot. This feature to this day works like this. You can pass wherever you want. So what happens when I share the storage volume that is totally mined, it is intended to be shared. It is architecture of Gluster allows all clients to mount any volume, including the shared storage volume involved with this vulnerability. If at any point the Gluster snapshot scheduler is enabled, running that Python script you run, you will create a same link in it's cron D. Obviously, on it by root. So anyone who can mount this can scale cron jobs again, passing wherever they want. This is the red hat advisory untouched. It's like they polish it. As you might see, doing another dash L, we see that it's a sim link to bar run Gluster snap cron tasks. So as I can interact with it, I could also attack it using the only nano, B beam, whatever you like, EE if you come from BSD. So by showing the given command, your lab is now vulnerable to get out of that. Okay. We'll use the exploit. The exploit, it's in fact something really simple. I wrote commenting it line by line. So any newcomer to the exploit writing world, I'm no expert at all, but if someone wants to start from a point, it's commented line by line. So everybody understands what every line is doing at any time. You can easily, as I said before, try to hack this using your text, your preferred text editor. But well, here we have the exploit. It comes as a standalone exploit, my preferred method or as a meta exploit module. In most cases, the standalone will be enough and it takes just a few seconds to exploit this. This is the meta exploit version, as you might see it's further custom-isabled and standalone one. In order to use the standalone, you can simply run hem install colorize. Colorize is a gem for having a colored output. You can leave it there outside if you want. And just sudo gavaldanrv and the server, you want to exploit in my case, this one. It won't take more than five seconds and will schedule a new task, being able to shell. You know, it's like a shell but evil and it's fictional. And then we can check the contents on the tampered Chrome file. As you might see, it crons something to run. This output, this is a failure in the line breaking but it's well cron. Okay. Now it's time to check the Docker containers and the result should be similar to this. This should be the output. Gavaldanrv, okay, I am with super user, Gloucester binary located, the server reply to ICMP request, it's a simple request, nothing really forged or common Gloucester ports are open. We're attempting to exploit. We have exploited successfully the Gloucester shared storage. We mounted it here. On the client side, this is automatic. So you don't have to set up anything unless you're using the meta exploit module. Okay. Now we have access. This is everything we have in the volume. If you have any other compromising file, important file, whatever you have, it will be displayed here and will be fetched. The cron file was altered and we inject enable Joe or whatever you want to run. Okay. You can load the exploit at any time. Check line aligned, see how it works. The meta exploit module two, it's not pushed into the meta exploit official repo. Okay. We'll take our time to explain this if anyone has any question. It's really simple. It's really easy going so it doesn't have any complexity behind running with super user. There's a little patch we made. It's Castile, another standalone Ruby script. Why did I take the time to build this? That seems really overkill. We have really, really big farms of servers running this vulnerable version on many clients. In fact, it's my first time testing Gloucester at all. A customer told me, hey, Red Hat issued some advisory about Gloucester. Okay. We used this with Ansible. You know Ansible? Like Jeff or Puppet for poor men like me. It worked. It was okay. Vulnerable, vulnerable option. Or the snapcrone task is assembling, come exploit it. So we have some report to show the customer. It's also in the repo. Also, you can find the Docker file to build the image. Some of these snapshots. Okay. How do I patch this? Like most vulnerabilities out there, the vendor issued its own patch. Simple update, upgrade, whatever you like. It's available across all platforms. Remember, Gloucester is available from Windows to Linux to even VSD. So everybody has its patch already running. Okay. Now, conclusions and questions. Gloucester is not vulnerable per se. It's not something like a Dove Flash player. In fact, in a span of five years, it had less than 10 vulnerabilities. In fact, it had six. Two, the last two are after Red Hat bought them. They were included before being bought by Red Hat, but Red Hat found them. And simple bugs like this can bring a great chaos. So if you don't feel like forking about them, modifying it, translating it, writing something else, be my guest. It's free to use. And it's a nice starting point for teaching someone to write an exploit step by step without having to learn assembler, C, or memory position, something that could be hard to newcomers and could scare them off. Okay. Special thanks to the data application media crew and to my working team. Anybody has any questions? Okay. Thank you.
 So thank you for our second talk of the day. This is Maro, he's going to be talking about  owner Gluster VS. Make sure you ask him about the exploit he has.  Hey, how are you? Well, this is a talk, it's a really beginner friendly talk. It's about  exploiting Gluster, CVE 2018-188. It's an authenticated access to every shared storage. This is a talk  that I wrote having in mind for those who are new to both boards exploit writing and data  duplication in fact. So the entry point for many people into the world of data duplication is  Gluster. And I also found that it was really easy to write an exploit for the CVE, so I wanted to  share it to everyone who's interested in writing exploits in the future. So I want to ask for  your pardon in advance for my pronunciation. Might not be the best, so if something is not  understood, write your hand and I'll try to repeat it. So let's start. Brief introduction of  who am I and what I'm doing. I'm from Argentina, I was born in the 90s, I work at the government  office, I own a really small company related to Infosec in Argentina and well, let's get going. For  this talk, I wanted to build a lab on mirror machines but I decided Docker because a recommendation  from a friend. So anybody here uses Docker? Fine. For the rest who doesn't, it's really easy  going, it's really easy to understand. This talk is mainly a hands-on lab. So I understand many of  you won't want to connect to the Wi-Fi network, many of you won't feel comfortable downloading  an exploit for a repo. Most of you won't feel comfortable using Docker here in this environment.  So it's nice if you don't want to follow it, you can download it later. I'll try to follow that lab  here like a live demo. So okay. A quick start on Gloucester for everybody who doesn't use it.  Gloucester is a Scalable Network file system. You can use any hardware, any cheap hardware you  have to run it. It's, as I said before, it's a really good starting point for those interested  in data duplication. You can duplicate almost any data. We have almost any data on any hardware, I  mean. We have succeeded using it on really, really humble hardware, Raspberry Pi's and the like, all  laptops and so on. And even we have used some USB drives to clone and it worked like a charm. It was  acquired by Red Hat in 2011, but it's also available in the free world as an open source tone.  So as I was saying before, anything, anything can run Gloucester. It's really hard to see  something that doesn't work with it. Call it FreeBSD, NetBSD, OpenBSD, whatever, even Raspbian.  Anything you want can run it. In this talk, we'll set up Gloucester as a simple replication  service. We won't enter into that hassle of configuring complex things. The bug itself,  the vulnerability, it's really, really silly in fact. So we will build a simple lab, nothing  complex. Our minimalistic setup will have two Gloucester nodes, a volume for each node, and a  single brick for each volume, and a bunch of test files. What does a node mean? Any server or  computer that holds one or more bricks? The bricks are the basic basic unit of storage in Gloucester.  And a volume, it's a logical collection of those. Every file resides inside bricks. You can think  of them like a sort of shard directories. I know it's not the exact definition, but it's for having  a simple idea of this. Bricks compose volumes. All operations will occur at node level, and will  propagate accordingly. This illustrates basically everything I say before. You have the amount  point on your operating system, replicated volume, volume, sorry, and the files on the bricks.  A quick start on Docker for those who haven't used it before.  Docker is the company driving the container moment. A container platform provides all the pieces  enterprise operation requires including security, governance, automation, support,  atomization, and certification. This is the definition provided by Docker itself.  Let's suppose we have virtual machines. You can have an app like, okay, I will separate them  in a VM for the app, a VM for the database, and if you want a VM for the file systems,  if you want, containers are different. As they are oriented for microservices,  they made the target is to have a minimal functional unit. On a container base infrastructure,  your app, the same as before, may look like this. A backend app, just you'll have your  custom binaries, your custom libraries, and your app. Nothing else. The web server, you might have  a container for Apache, for NGINX, for whatever you want. And the DB container might have just a  DB engine. And even it might not hold the database itself, the data files. Here we have a comparison.  As you may see, you're just using your custom things, your custom application, your custom  binaries, your custom libraries on your container. Everything else that you use online is shared  among across all the containers. Okay, a common question is what are my configuration files?  We won't use them in this case, but it's a thing that always troubled me when I was learning  Docker. If you follow the best practices, you will store them in an external volume. And you can  even share all your config files across all your containers. So you can have a better control  of your configuration files. Say, okay, this instance is configured that way. Okay, every one,  every instance will be following that policy, if we want to call it like that. Okay, there was,  Docker uses run C. You might remember a slip container with runs in the same operating systems.  They have also features layered file systems. Okay, the binaries, even if you're using Q-Stone  ones, the classic unique user land is shared and every label along all the containers.  Okay, we'll build our hands-on slab. Once again, I know you may not be comfortable doing this  line right now. So, okay, no problem. I'll have a live demo here. The Docker containers.  You can easily install, I love doing install, APT install Docker, Git, and last-reference  client on that specific version. This obviously works for JOM or DNF based distros. So no  problem, even for free VSD. Okay, I have sent out my repo, giveoutdown on git have.com.  You can simply build the image, target whatever you want. The target is the name you're giving to  the image itself. Giveoutdown cluster. It should be run in a privileged environment because cluster  requires to do so. You can run most of the images or Docker files around there without any privileged  user. So this will give us an instance ID that you can use it to identify that container. The  magic of Docker is that you can run as many instances as you like or as you can of the same  product. So if we run this command or Docker run, privileged through, twice, we will have two  instances of the lab. If we run it three times, we have three instances and so on. This is really  useful when you need to have, obviously, configuring something atop like a file over or like a  distribution. Using the command Docker PS, you can see a lab. They're both running with different  IDs, obviously, and what they are doing. I would like to share with you the Docker file.  So you can see how easy it is. It is built. Sorry. This is our Docker file. As you might see, this  is the base. From the stretch, we are pulling an already made image. We just run update,  install, without prompting, the vulnerable version. We purge everything that we don't need.  Docker points to microservices. So we need to have a minimal setup of every container. And these are  the custom configurations to make the cluster volume directory, to have it absolute access for  this test, to run cluster and to change the PS1 just to look like the one assured here.  Sorry. The PS1 thing is something aesthetic just to have that way here. Okay. As you might see,  we have both containers running. We can enter the containers just doing that command. Docker  exec TI is for executing on interactive way. Bash. So we have the IP address of every container.  How do we set up Gluster for this? As we have two containers, we'll call them server A and server B.  We can enter server A and issue the following commands. Gluster prove server B. This is for  turning the server A. Recognize that one. Check if that one is running a cluster instance and  pair with it. Gluster pierce status. And on the other side, too, Gluster pierce status. We have  something like this. As you might see. Prove, yeah, it's working. Starrows, yeah, I have a pier.  This is my new pier. From the other side, we don't have to pair it again. Starrows, number of pierce  one and a unique ID. So they are recognized as partners. Remember, they are vulnerable versions.  They are already patched up. So don't keep these containers for anything more than testing. Okay,  let's keep going. We have to create volumes for this. Gluster volume create dev convol replica two,  transport TCP, where server A on this mount point. Remember in the Docker file, we stated to  create this mount point. It won't create it if it doesn't exist. Then on server A, again,  Gluster volume start dev convol. So start this volume. And Gluster volume info from the other  side shows to check if it found it. You might see these are the output from the comments.  Success, start the volume, restore it. And this one without further interaction knows where it is  located and starts to replicate here. This lab is already set up for replicating. So on a client,  on a desktop, laptop or whatever we are using outside the Docker, we make our mount point give  out on puck. You do mount Gluster FS, where on server A, dev convol, as you might see, we skip it  any path, just dev convol. Where, mount it here, where we just make the there. Mount give out on  puck. This will create, this will, sorry, this will mount a recently create volume. Then on our  desktop, echo data duplication buildage to mount give out on banner.dat. This will make the  replication to happen. So we'll cut the file on both nodes and check it has replicated, in fact.  As you might see, here we create the file, cut, work it, cut, work it. Not further interaction.  It's really easy for people who are newcomers to this world. I am, in fact, a newcomer to this  world. So I found it really easy to get myself involved with in Gluster. Now, if everything  went the right way, our lab is replicated. But it's not vulnerable, but see, still. So let's  destroy it. This for everybody who's not into the container moment or, it's the logic behind  Docker or behind any microservice. You run, it fails. Okay. We respond and we keep running.  The main point in Gluster is to be recycled, to be constantly  reissued for saying it on a certain way. Okay. Let's use give out on to on Gluster.  First, I want you to understand what the CV is about. This is a new CV. This is from May.  I wrote this talk in June. It was patched just some day, I think, two or three days after it  was issued. It was a really silly bag. Give out on Gluster and viral vulnerable authentication  for data access and new it's an exploit for Gluster FC 1088 and 1112 right in Ruby. Basically,  this vulnerability allows any Gluster client to connect without any authentication to a shared  storage volume. In that shared storage volume, it's Gluster on it, resides the task scheduler.  And by modifying that specific file from the scheduler, a Chrome file, I think we all know  how Chrome works. Okay. It's a Chrome file. You can schedule arbitrary commands and tasks,  whatever you like. This allows many actions from the privilege escalation to total data compromise  or nuke. As you might see, this is using the tool DevSecand. It tells you what vulnerable packages  you have and what are those vulnerabilities that reside in your system. As you might see,  these are the only ones we have, Gluster. Both from the client and from the server and from the  common. In order to exploit this, the shared storage feature must be enabled. It is not enabled  by default now. It was in the first versions. It was vulnerable historically. So you should  explicitly run in your server. Gluster volume set all cluster enable shared storage enabled.  We checked it started running. Gluster volume get Gluster shared storage. Gluster enabled shared  storage. And then the snap scheduler should be enabled. It is a Python script. Snap scheduler  in it. As you might see, this might seem like a complex configuration, but in fact,  many enterprise sites already are using this. It is, it might seem something complex for someone  like me who doesn't use Gluster for something bigger than a simple proof of concept lab. But  every environment from media and app uses this feature. So success. Here we see this, the option  enabled. We start the scheduler and says, okay, the snap scheduler is running. But it doesn't  only cron snapshots. You can cron wherever you want. In fact, if you use any interface or even  the command line, you can pass any arbitrary task. It doesn't have to be a snapshot. This feature  to this day works like this. You can pass wherever you want. So what happens when I share the  storage volume that is totally mined, it is intended to be shared. It is architecture of  Gluster allows all clients to mount any volume, including the shared storage volume involved  with this vulnerability. If at any point the Gluster snapshot scheduler is enabled, running  that Python script you run, you will create a same link in it's cron D. Obviously, on it by root.  So anyone who can mount this can scale cron jobs again, passing wherever they want. This is the  red hat advisory untouched. It's like they polish it. As you might see, doing another dash  L, we see that it's a sim link to bar run Gluster snap cron tasks. So as I can interact with it,  I could also attack it using the only nano, B beam, whatever you like, EE if you come from BSD.  So by showing the given command, your lab is now vulnerable to get out of that.  Okay. We'll use the exploit. The exploit, it's in fact something really simple. I wrote  commenting it line by line. So any newcomer to the exploit writing world, I'm no expert at all,  but if someone wants to start from a point, it's commented line by line. So everybody understands  what every line is doing at any time. You can easily, as I said before, try to hack this using  your text, your preferred text editor. But well, here we have the exploit. It comes as a standalone  exploit, my preferred method or as a meta exploit module. In most cases, the standalone will be  enough and it takes just a few seconds to exploit this. This is the meta exploit version, as you  might see it's further custom-isabled and standalone one. In order to use the standalone, you can  simply run hem install colorize. Colorize is a gem for having a colored output. You can leave it  there outside if you want. And just sudo gavaldanrv and the server, you want to exploit in my case,  this one. It won't take more than five seconds and will schedule a new task, being able to shell.  You know, it's like a shell but evil and it's fictional. And then we can check the contents  on the tampered Chrome file. As you might see, it crons something to run. This output, this is a  failure in the line breaking but it's well cron. Okay. Now it's time to check the Docker  containers and the result should be similar to this. This should be the output. Gavaldanrv,  okay, I am with super user, Gloucester binary located, the server reply to ICMP request,  it's a simple request, nothing really forged or common Gloucester ports are open. We're attempting  to exploit. We have exploited successfully the Gloucester shared storage. We mounted it here.  On the client side, this is automatic. So you don't have to set up anything unless you're using  the meta exploit module. Okay. Now we have access. This is everything we have in the  volume. If you have any other compromising file, important file, whatever you have,  it will be displayed here and will be fetched. The cron file was altered and we inject enable  Joe or whatever you want to run. Okay. You can load the exploit at any time. Check line  aligned, see how it works. The meta exploit module two, it's not pushed into the meta  exploit official repo. Okay. We'll take our time to explain this if anyone has any question. It's  really simple. It's really easy going so it doesn't have any complexity behind running with  super user. There's a little patch we made. It's Castile, another standalone Ruby script.  Why did I take the time to build this? That seems really overkill. We have really, really big  farms of servers running this vulnerable version on many clients. In fact, it's my first time  testing Gloucester at all. A customer told me, hey, Red Hat issued some advisory about Gloucester.  Okay. We used this with Ansible. You know Ansible? Like Jeff or Puppet for poor men like me. It  worked. It was okay. Vulnerable, vulnerable option. Or the snapcrone task is assembling,  come exploit it. So we have some report to show the customer. It's also in the repo. Also, you  can find the Docker file to build the image. Some of these snapshots. Okay. How do I patch this?  Like most vulnerabilities out there, the vendor issued its own patch. Simple update, upgrade,  whatever you like. It's available across all platforms. Remember, Gloucester is available  from Windows to Linux to even VSD. So everybody has its patch already running. Okay. Now,  conclusions and questions. Gloucester is not vulnerable per se. It's not something like a  Dove Flash player. In fact, in a span of five years, it had less than 10 vulnerabilities. In  fact, it had six. Two, the last two are after Red Hat bought them. They were included before being  bought by Red Hat, but Red Hat found them. And simple bugs like this can bring a great chaos. So  if you don't feel like forking about them, modifying it, translating it, writing something  else, be my guest. It's free to use. And it's a nice starting point for teaching  someone to write an exploit step by step without having to learn assembler, C, or memory position,  something that could be hard to newcomers and could scare them off. Okay. Special thanks to the  data application media crew and to my working team. Anybody has any questions?  Okay. Thank you.
DEF_CON_26_DATA_DUPLICATION_VILLAGE_-_Mauro_Caseres_-_Owning_Gluster_FS_with_GEVAUDAN_qU-9MsxjW7A_0_527.png DEF_CON_26_DATA_DUPLICATION_VILLAGE_-_Mauro_Caseres_-_Owning_Gluster_FS_with_GEVAUDAN_qU-9MsxjW7A_528_1895.png DEF_CON_26_DATA_DUPLICATION_VILLAGE_-_Mauro_Caseres_-_Owning_Gluster_FS_with_GEVAUDAN_qU-9MsxjW7A_1896_5087.png DEF_CON_26_DATA_DUPLICATION_VILLAGE_-_Mauro_Caseres_-_Owning_Gluster_FS_with_GEVAUDAN_qU-9MsxjW7A_5088_7343.png DEF_CON_26_DATA_DUPLICATION_VILLAGE_-_Mauro_Caseres_-_Owning_Gluster_FS_with_GEVAUDAN_qU-9MsxjW7A_7344_7691.png DEF_CON_26_DATA_DUPLICATION_VILLAGE_-_Mauro_Caseres_-_Owning_Gluster_FS_with_GEVAUDAN_qU-9MsxjW7A_7692_9863.png DEF_CON_26_DATA_DUPLICATION_VILLAGE_-_Mauro_Caseres_-_Owning_Gluster_FS_with_GEVAUDAN_qU-9MsxjW7A_9864_10367.png DEF_CON_26_DATA_DUPLICATION_VILLAGE_-_Mauro_Caseres_-_Owning_Gluster_FS_with_GEVAUDAN_qU-9MsxjW7A_10368_11819.png DEF_CON_26_DATA_DUPLICATION_VILLAGE_-_Mauro_Caseres_-_Owning_Gluster_FS_with_GEVAUDAN_qU-9MsxjW7A_11820_15455.png DEF_CON_26_DATA_DUPLICATION_VILLAGE_-_Mauro_Caseres_-_Owning_Gluster_FS_with_GEVAUDAN_qU-9MsxjW7A_15456_15515.png DEF_CON_26_DATA_DUPLICATION_VILLAGE_-_Mauro_Caseres_-_Owning_Gluster_FS_with_GEVAUDAN_qU-9MsxjW7A_15516_15575.png DEF_CON_26_DATA_DUPLICATION_VILLAGE_-_Mauro_Caseres_-_Owning_Gluster_FS_with_GEVAUDAN_qU-9MsxjW7A_15576_15623.png DEF_CON_26_DATA_DUPLICATION_VILLAGE_-_Mauro_Caseres_-_Owning_Gluster_FS_with_GEVAUDAN_qU-9MsxjW7A_15624_16703.png DEF_CON_26_DATA_DUPLICATION_VILLAGE_-_Mauro_Caseres_-_Owning_Gluster_FS_with_GEVAUDAN_qU-9MsxjW7A_16704_16775.png DEF_CON_26_DATA_DUPLICATION_VILLAGE_-_Mauro_Caseres_-_Owning_Gluster_FS_with_GEVAUDAN_qU-9MsxjW7A_16776_16847.png DEF_CON_26_DATA_DUPLICATION_VILLAGE_-_Mauro_Caseres_-_Owning_Gluster_FS_with_GEVAUDAN_qU-9MsxjW7A_16848_16895.png DEF_CON_26_DATA_DUPLICATION_VILLAGE_-_Mauro_Caseres_-_Owning_Gluster_FS_with_GEVAUDAN_qU-9MsxjW7A_16896_17087.png DEF_CON_26_DATA_DUPLICATION_VILLAGE_-_Mauro_Caseres_-_Owning_Gluster_FS_with_GEVAUDAN_qU-9MsxjW7A_17088_17183.png DEF_CON_26_DATA_DUPLICATION_VILLAGE_-_Mauro_Caseres_-_Owning_Gluster_FS_with_GEVAUDAN_qU-9MsxjW7A_17184_18707.png DEF_CON_26_DATA_DUPLICATION_VILLAGE_-_Mauro_Caseres_-_Owning_Gluster_FS_with_GEVAUDAN_qU-9MsxjW7A_18708_19235.png DEF_CON_26_DATA_DUPLICATION_VILLAGE_-_Mauro_Caseres_-_Owning_Gluster_FS_with_GEVAUDAN_qU-9MsxjW7A_19236_19931.png DEF_CON_26_DATA_DUPLICATION_VILLAGE_-_Mauro_Caseres_-_Owning_Gluster_FS_with_GEVAUDAN_qU-9MsxjW7A_19932_20435.png DEF_CON_26_DATA_DUPLICATION_VILLAGE_-_Mauro_Caseres_-_Owning_Gluster_FS_with_GEVAUDAN_qU-9MsxjW7A_20436_22331.png DEF_CON_26_DATA_DUPLICATION_VILLAGE_-_Mauro_Caseres_-_Owning_Gluster_FS_with_GEVAUDAN_qU-9MsxjW7A_22332_22559.png DEF_CON_26_DATA_DUPLICATION_VILLAGE_-_Mauro_Caseres_-_Owning_Gluster_FS_with_GEVAUDAN_qU-9MsxjW7A_22560_23339.png DEF_CON_26_DATA_DUPLICATION_VILLAGE_-_Mauro_Caseres_-_Owning_Gluster_FS_with_GEVAUDAN_qU-9MsxjW7A_23340_25763.png DEF_CON_26_DATA_DUPLICATION_VILLAGE_-_Mauro_Caseres_-_Owning_Gluster_FS_with_GEVAUDAN_qU-9MsxjW7A_25764_26627.png DEF_CON_26_DATA_DUPLICATION_VILLAGE_-_Mauro_Caseres_-_Owning_Gluster_FS_with_GEVAUDAN_qU-9MsxjW7A_26628_27407.png DEF_CON_26_DATA_DUPLICATION_VILLAGE_-_Mauro_Caseres_-_Owning_Gluster_FS_with_GEVAUDAN_qU-9MsxjW7A_27408_29255.png DEF_CON_26_DATA_DUPLICATION_VILLAGE_-_Mauro_Caseres_-_Owning_Gluster_FS_with_GEVAUDAN_qU-9MsxjW7A_29256_30263.png DEF_CON_26_DATA_DUPLICATION_VILLAGE_-_Mauro_Caseres_-_Owning_Gluster_FS_with_GEVAUDAN_qU-9MsxjW7A_30264_31487.png DEF_CON_26_DATA_DUPLICATION_VILLAGE_-_Mauro_Caseres_-_Owning_Gluster_FS_with_GEVAUDAN_qU-9MsxjW7A_31488_31727.png DEF_CON_26_DATA_DUPLICATION_VILLAGE_-_Mauro_Caseres_-_Owning_Gluster_FS_with_GEVAUDAN_qU-9MsxjW7A_31728_33119.png DEF_CON_26_DATA_DUPLICATION_VILLAGE_-_Mauro_Caseres_-_Owning_Gluster_FS_with_GEVAUDAN_qU-9MsxjW7A_33120_35651.png DEF_CON_26_DATA_DUPLICATION_VILLAGE_-_Mauro_Caseres_-_Owning_Gluster_FS_with_GEVAUDAN_qU-9MsxjW7A_35652_37079.png DEF_CON_26_DATA_DUPLICATION_VILLAGE_-_Mauro_Caseres_-_Owning_Gluster_FS_with_GEVAUDAN_qU-9MsxjW7A_37080_39239.png DEF_CON_26_DATA_DUPLICATION_VILLAGE_-_Mauro_Caseres_-_Owning_Gluster_FS_with_GEVAUDAN_qU-9MsxjW7A_39240_39691.png
So thank you for our second talk of the day. This is Maro, he's going to be talking about owner Gluster VS. Make sure you ask him about the exploit he has. Hey, how are you? Well, this is a talk, it's a really beginner friendly talk. It's about exploiting Gluster, CVE 2018-188. It's an authenticated access to every shared storage. This is a talk that I wrote having in mind for those who are new to both boards exploit writing and data duplication in fact. So the entry point for many people into the world of data duplication is Gluster. And I also found that it was really easy to write an exploit for the CVE, so I wanted to share it to everyone who's interested in writing exploits in the future. So I want to ask for your pardon in advance for my pronunciation. Might not be the best, so if something is not understood, write your hand and I'll try to repeat it. So let's start. Brief introduction of who am I and what I'm doing. I'm from Argentina, I was born in the 90s, I work at the government office, I own a really small company related to Infosec in Argentina and well, let's get going. For this talk, I wanted to build a lab on mirror machines but I decided Docker because a recommendation from a friend. So anybody here uses Docker? Fine. For the rest who doesn't, it's really easy going, it's really easy to understand. This talk is mainly a hands-on lab. So I understand many of you won't want to connect to the Wi-Fi network, many of you won't feel comfortable downloading an exploit for a repo. Most of you won't feel comfortable using Docker here in this environment. So it's nice if you don't want to follow it, you can download it later. I'll try to follow that lab here like a live demo. So okay. A quick start on Gloucester for everybody who doesn't use it. Gloucester is a Scalable Network file system. You can use any hardware, any cheap hardware you have to run it. It's, as I said before, it's a really good starting point for those interested in data duplication. You can duplicate almost any data. We have almost any data on any hardware, I mean. We have succeeded using it on really, really humble hardware, Raspberry Pi's and the like, all laptops and so on. And even we have used some USB drives to clone and it worked like a charm. It was acquired by Red Hat in 2011, but it's also available in the free world as an open source tone. So as I was saying before, anything, anything can run Gloucester. It's really hard to see something that doesn't work with it. Call it FreeBSD, NetBSD, OpenBSD, whatever, even Raspbian. Anything you want can run it. In this talk, we'll set up Gloucester as a simple replication service. We won't enter into that hassle of configuring complex things. The bug itself, the vulnerability, it's really, really silly in fact. So we will build a simple lab, nothing complex. Our minimalistic setup will have two Gloucester nodes, a volume for each node, and a single brick for each volume, and a bunch of test files. What does a node mean? Any server or computer that holds one or more bricks? The bricks are the basic basic unit of storage in Gloucester. And a volume, it's a logical collection of those. Every file resides inside bricks. You can think of them like a sort of shard directories. I know it's not the exact definition, but it's for having a simple idea of this. Bricks compose volumes. All operations will occur at node level, and will propagate accordingly. This illustrates basically everything I say before. You have the amount point on your operating system, replicated volume, volume, sorry, and the files on the bricks. A quick start on Docker for those who haven't used it before. Docker is the company driving the container moment. A container platform provides all the pieces enterprise operation requires including security, governance, automation, support, atomization, and certification. This is the definition provided by Docker itself. Let's suppose we have virtual machines. You can have an app like, okay, I will separate them in a VM for the app, a VM for the database, and if you want a VM for the file systems, if you want, containers are different. As they are oriented for microservices, they made the target is to have a minimal functional unit. On a container base infrastructure, your app, the same as before, may look like this. A backend app, just you'll have your custom binaries, your custom libraries, and your app. Nothing else. The web server, you might have a container for Apache, for NGINX, for whatever you want. And the DB container might have just a DB engine. And even it might not hold the database itself, the data files. Here we have a comparison. As you may see, you're just using your custom things, your custom application, your custom binaries, your custom libraries on your container. Everything else that you use online is shared among across all the containers. Okay, a common question is what are my configuration files? We won't use them in this case, but it's a thing that always troubled me when I was learning Docker. If you follow the best practices, you will store them in an external volume. And you can even share all your config files across all your containers. So you can have a better control of your configuration files. Say, okay, this instance is configured that way. Okay, every one, every instance will be following that policy, if we want to call it like that. Okay, there was, Docker uses run C. You might remember a slip container with runs in the same operating systems. They have also features layered file systems. Okay, the binaries, even if you're using Q-Stone ones, the classic unique user land is shared and every label along all the containers. Okay, we'll build our hands-on slab. Once again, I know you may not be comfortable doing this line right now. So, okay, no problem. I'll have a live demo here. The Docker containers. You can easily install, I love doing install, APT install Docker, Git, and last-reference client on that specific version. This obviously works for JOM or DNF based distros. So no problem, even for free VSD. Okay, I have sent out my repo, giveoutdown on git have.com. You can simply build the image, target whatever you want. The target is the name you're giving to the image itself. Giveoutdown cluster. It should be run in a privileged environment because cluster requires to do so. You can run most of the images or Docker files around there without any privileged user. So this will give us an instance ID that you can use it to identify that container. The magic of Docker is that you can run as many instances as you like or as you can of the same product. So if we run this command or Docker run, privileged through, twice, we will have two instances of the lab. If we run it three times, we have three instances and so on. This is really useful when you need to have, obviously, configuring something atop like a file over or like a distribution. Using the command Docker PS, you can see a lab. They're both running with different IDs, obviously, and what they are doing. I would like to share with you the Docker file. So you can see how easy it is. It is built. Sorry. This is our Docker file. As you might see, this is the base. From the stretch, we are pulling an already made image. We just run update, install, without prompting, the vulnerable version. We purge everything that we don't need. Docker points to microservices. So we need to have a minimal setup of every container. And these are the custom configurations to make the cluster volume directory, to have it absolute access for this test, to run cluster and to change the PS1 just to look like the one assured here. Sorry. The PS1 thing is something aesthetic just to have that way here. Okay. As you might see, we have both containers running. We can enter the containers just doing that command. Docker exec TI is for executing on interactive way. Bash. So we have the IP address of every container. How do we set up Gluster for this? As we have two containers, we'll call them server A and server B. We can enter server A and issue the following commands. Gluster prove server B. This is for turning the server A. Recognize that one. Check if that one is running a cluster instance and pair with it. Gluster pierce status. And on the other side, too, Gluster pierce status. We have something like this. As you might see. Prove, yeah, it's working. Starrows, yeah, I have a pier. This is my new pier. From the other side, we don't have to pair it again. Starrows, number of pierce one and a unique ID. So they are recognized as partners. Remember, they are vulnerable versions. They are already patched up. So don't keep these containers for anything more than testing. Okay, let's keep going. We have to create volumes for this. Gluster volume create dev convol replica two, transport TCP, where server A on this mount point. Remember in the Docker file, we stated to create this mount point. It won't create it if it doesn't exist. Then on server A, again, Gluster volume start dev convol. So start this volume. And Gluster volume info from the other side shows to check if it found it. You might see these are the output from the comments. Success, start the volume, restore it. And this one without further interaction knows where it is located and starts to replicate here. This lab is already set up for replicating. So on a client, on a desktop, laptop or whatever we are using outside the Docker, we make our mount point give out on puck. You do mount Gluster FS, where on server A, dev convol, as you might see, we skip it any path, just dev convol. Where, mount it here, where we just make the there. Mount give out on puck. This will create, this will, sorry, this will mount a recently create volume. Then on our desktop, echo data duplication buildage to mount give out on banner.dat. This will make the replication to happen. So we'll cut the file on both nodes and check it has replicated, in fact. As you might see, here we create the file, cut, work it, cut, work it. Not further interaction. It's really easy for people who are newcomers to this world. I am, in fact, a newcomer to this world. So I found it really easy to get myself involved with in Gluster. Now, if everything went the right way, our lab is replicated. But it's not vulnerable, but see, still. So let's destroy it. This for everybody who's not into the container moment or, it's the logic behind Docker or behind any microservice. You run, it fails. Okay. We respond and we keep running. The main point in Gluster is to be recycled, to be constantly reissued for saying it on a certain way. Okay. Let's use give out on to on Gluster. First, I want you to understand what the CV is about. This is a new CV. This is from May. I wrote this talk in June. It was patched just some day, I think, two or three days after it was issued. It was a really silly bag. Give out on Gluster and viral vulnerable authentication for data access and new it's an exploit for Gluster FC 1088 and 1112 right in Ruby. Basically, this vulnerability allows any Gluster client to connect without any authentication to a shared storage volume. In that shared storage volume, it's Gluster on it, resides the task scheduler. And by modifying that specific file from the scheduler, a Chrome file, I think we all know how Chrome works. Okay. It's a Chrome file. You can schedule arbitrary commands and tasks, whatever you like. This allows many actions from the privilege escalation to total data compromise or nuke. As you might see, this is using the tool DevSecand. It tells you what vulnerable packages you have and what are those vulnerabilities that reside in your system. As you might see, these are the only ones we have, Gluster. Both from the client and from the server and from the common. In order to exploit this, the shared storage feature must be enabled. It is not enabled by default now. It was in the first versions. It was vulnerable historically. So you should explicitly run in your server. Gluster volume set all cluster enable shared storage enabled. We checked it started running. Gluster volume get Gluster shared storage. Gluster enabled shared storage. And then the snap scheduler should be enabled. It is a Python script. Snap scheduler in it. As you might see, this might seem like a complex configuration, but in fact, many enterprise sites already are using this. It is, it might seem something complex for someone like me who doesn't use Gluster for something bigger than a simple proof of concept lab. But every environment from media and app uses this feature. So success. Here we see this, the option enabled. We start the scheduler and says, okay, the snap scheduler is running. But it doesn't only cron snapshots. You can cron wherever you want. In fact, if you use any interface or even the command line, you can pass any arbitrary task. It doesn't have to be a snapshot. This feature to this day works like this. You can pass wherever you want. So what happens when I share the storage volume that is totally mined, it is intended to be shared. It is architecture of Gluster allows all clients to mount any volume, including the shared storage volume involved with this vulnerability. If at any point the Gluster snapshot scheduler is enabled, running that Python script you run, you will create a same link in it's cron D. Obviously, on it by root. So anyone who can mount this can scale cron jobs again, passing wherever they want. This is the red hat advisory untouched. It's like they polish it. As you might see, doing another dash L, we see that it's a sim link to bar run Gluster snap cron tasks. So as I can interact with it, I could also attack it using the only nano, B beam, whatever you like, EE if you come from BSD. So by showing the given command, your lab is now vulnerable to get out of that. Okay. We'll use the exploit. The exploit, it's in fact something really simple. I wrote commenting it line by line. So any newcomer to the exploit writing world, I'm no expert at all, but if someone wants to start from a point, it's commented line by line. So everybody understands what every line is doing at any time. You can easily, as I said before, try to hack this using your text, your preferred text editor. But well, here we have the exploit. It comes as a standalone exploit, my preferred method or as a meta exploit module. In most cases, the standalone will be enough and it takes just a few seconds to exploit this. This is the meta exploit version, as you might see it's further custom-isabled and standalone one. In order to use the standalone, you can simply run hem install colorize. Colorize is a gem for having a colored output. You can leave it there outside if you want. And just sudo gavaldanrv and the server, you want to exploit in my case, this one. It won't take more than five seconds and will schedule a new task, being able to shell. You know, it's like a shell but evil and it's fictional. And then we can check the contents on the tampered Chrome file. As you might see, it crons something to run. This output, this is a failure in the line breaking but it's well cron. Okay. Now it's time to check the Docker containers and the result should be similar to this. This should be the output. Gavaldanrv, okay, I am with super user, Gloucester binary located, the server reply to ICMP request, it's a simple request, nothing really forged or common Gloucester ports are open. We're attempting to exploit. We have exploited successfully the Gloucester shared storage. We mounted it here. On the client side, this is automatic. So you don't have to set up anything unless you're using the meta exploit module. Okay. Now we have access. This is everything we have in the volume. If you have any other compromising file, important file, whatever you have, it will be displayed here and will be fetched. The cron file was altered and we inject enable Joe or whatever you want to run. Okay. You can load the exploit at any time. Check line aligned, see how it works. The meta exploit module two, it's not pushed into the meta exploit official repo. Okay. We'll take our time to explain this if anyone has any question. It's really simple. It's really easy going so it doesn't have any complexity behind running with super user. There's a little patch we made. It's Castile, another standalone Ruby script. Why did I take the time to build this? That seems really overkill. We have really, really big farms of servers running this vulnerable version on many clients. In fact, it's my first time testing Gloucester at all. A customer told me, hey, Red Hat issued some advisory about Gloucester. Okay. We used this with Ansible. You know Ansible? Like Jeff or Puppet for poor men like me. It worked. It was okay. Vulnerable, vulnerable option. Or the snapcrone task is assembling, come exploit it. So we have some report to show the customer. It's also in the repo. Also, you can find the Docker file to build the image. Some of these snapshots. Okay. How do I patch this? Like most vulnerabilities out there, the vendor issued its own patch. Simple update, upgrade, whatever you like. It's available across all platforms. Remember, Gloucester is available from Windows to Linux to even VSD. So everybody has its patch already running. Okay. Now, conclusions and questions. Gloucester is not vulnerable per se. It's not something like a Dove Flash player. In fact, in a span of five years, it had less than 10 vulnerabilities. In fact, it had six. Two, the last two are after Red Hat bought them. They were included before being bought by Red Hat, but Red Hat found them. And simple bugs like this can bring a great chaos. So if you don't feel like forking about them, modifying it, translating it, writing something else, be my guest. It's free to use. And it's a nice starting point for teaching someone to write an exploit step by step without having to learn assembler, C, or memory position, something that could be hard to newcomers and could scare them off. Okay. Special thanks to the data application media crew and to my working team. Anybody has any questions? Okay. Thank you.
authenticated access to every shared storage. This is a talk that I wrote having in mind for for many people into the world of data was really easy to write an exploit for the CVE, interested in writing exploits in the future. So connect to the Wi-Fi network, many of you won't live demo. So okay. A quick start on Gloucester was acquired by Red Hat in 2011, but it's also available in the free world as an open source talk, we'll set up Gloucester as a simple itself, the vulnerability, it's really, really volume, volume, sorry, and the files on the you can have a better control of your point. It won't create it if it doesn't exist. banner.dat. This will make the replication to easy for people who are newcomers to this world. the server and from the common. In order to architecture of Gluster allows all clients to last two are after Red Hat bought them. They were included before being bought by Red Hat, but Red