 Melissa, I love you. So big, my doom. That's not actually the worst poem ever invented. It's the name of the four first big viruses that ever came out. Melissa, in 1999, infected an estimated 20% of computers worldwide. The following year, I love you came out. Who remembers I love you? I'm showing my age, as are a couple of you. We had my doom in 2003 and in 2004. Sorry, we had it so big in 2003. 2004, we had my doom, which caused an estimated $38 billion of damage worldwide. Viruses are nasty. So I'm going to be one of those people that asks you all to stand. I mean it. So because we're talking about a virus today, I need you all to take a pledge. So I'd like you to repeat after me. I, insert your name, pledge to use the following information for good. If I fail to uphold this pledge, I promise to commit 200 hours of community service. Now please remain standing for a second. I want to use this opportunity to thank the organisers, Michael and the team, for an absolutely fantastic conference. There's no small feat to put that kind of thing together. Thank you very much. I'm going to post that photo later and say I got a standing ovation. It's fantastic. So I don't want to go, my slideshow is very short. I want to give you a demo. I'm going to actually write a virus for you today and take you through the processes. But before we do that, let's have a quick think about what a virus is. So a virus essentially has three main components. You have the infection mechanism. How does the virus get into a system? You have a payload, which is the actual virus that you want to infect a system with. And then you have a trigger, which is a mechanism by which the virus then actually gets actioned in order to take over a system or get information out of a database or whatever it is that you're trying to do. Now if you're a virus writer, which you all are, right, if you're a virus writer you're going to be concerned about the systems that detect viruses. Antivirus is a huge big global industry, as evidenced by the number of options out there and the number of viruses we still get infected by. So what do they do? Essentially some of the ways that they will look for a virus is by detecting a spread. So files being updated, a network socket being opened in order to write files to separate systems that perhaps is out of the norm. They will look for analysis detections. Instead of writing to files, maybe lots of files being opened and read and being analysed, maybe they're trying to exfiltrate information out of your systems. Are they stealing resources? Has your CPU usage just skyrocketed because this thing is running in the background? Or if you run out of memory because this massive, probably badly written script is running out of control? So in order to escape these kind of mechanisms, what we'll do is we'll know that we're looking for patterns. So the best security defence mechanisms will look at patterns in order to monitor whether or not something is stray. You'll find this often in airports. There are often people around just monitoring people, how they walk around, the kind of activities they're doing, who they're talking to, whether they have multiple laptops, which a lot of conference presenters here may or may not be flagged for in certain country security databases. But by trying not to stand out from the crowd in our script, we can try and evade that system. We can also adapt and evolve. Maybe the script changes over time, a script that changes and doesn't look the same every time as harder to detect. We can obfuscate ourselves by making it look less like a script or an attack. In fact, sometimes we can even from scramble ourselves completely and today we'll be using encryption to make sure that it's not actually possible to tell what the virus is. The best way to get into a system is to act benign. If you see a big wooden horse outside your door, of course you're going to invite it in. Who wouldn't? It's a big wooden horse. But once it's in, the wooden horse lays dormant for a while. It also turns into a cat. Who doesn't like cats? So you lay dormant for a while and when you do activate, you take it slow, don't stand out. So that's enough about that. Let's actually write a virus. So I have... I better stop the presentation so that comes up. I have... Stop the presentation so that doesn't come up. Excellent. I like it when computers listen to what you're doing. So let's have a look over here. So can everybody read that at the back? Can anybody not read that at the back? That's probably a better question. No, good. All right. I'm going to crane my neck a little here while I try and see what I'm doing. So I've got a number of steps here that I'm going to take you through the process that I wrote a virus. So quite aptly, I believe, I call the virus boom.php because we're going to make something go boom. So let's have a look at what we have to start with. I have to stay here because of the microphone and the recording. So let's have a look here. What we've got is we've got a system that's going to look for all the PHP files in the system. It's going to go through to those files and it's going to open it in read mode. Now, the reason we're opening it in read mode and not write mode, because remember we're writing a virus to this file now, is that sometimes there can be issues with going into read mode on certain file systems. We want to make sure that we don't have a conflict or the ability for a system to pick up the fact that we're modifying files. So we're going to read the file. It's quite a normal operation. So what we're going to do is we're going to go through and we'll see here that we're going to open another file with the same file name but with .infected on the end. So essentially the process here is we're going to read from one file, we're going to write into another file, but the other file is going to be infected with some kind of payload. So down further at the bottom of the screen here, we can see that we put into the string an infection, which at the moment is just a comment essentially. So we've put in a PHP tag there with a comment file infected. It's pretty inane at the moment, but we'll make it a bit more interesting later. Down at the bottom here, after we've written the first line to the infected file, we then go through the input file and we write all of the other files out. So essentially what we've got now is we've got our original file, we've got our new file into the new file, we've written the infection, and then line by line we copy the whole original file into the new file. So then if we scroll down a little, we'll see that after we've finished writing this in, we then close both of the files, we delete the original and we rename the infected file to the original file name. So now we've effectively replaced the original file without having opened it in read-write mode. We're just going to reduce the likelihood of a antivirus system detecting the fact that we changed a file. Hopefully, we'll see. So let's have a look and see how that works. So I have in here, so we've got our boom file, which we just looked at, and I also have a file called example.php, which is very complicated. I'll just run it because I don't want to go through every line of code. So we have there the numbers 1 through 9. That's exactly what we expected. So let's run the boom file now, and nothing happens. That's as expected. As a virus writer, you want to make sure there's no visual side effect to the fact that you've disinfected a system. And now if we run the example file again, it's still like those numbers 1 through 9. But if we look at the example file, we can see at the top there the file has now been infected. It's the infection mechanism that has worked. Let's have a look at step 2. So this is pretty much the same file except now, I've wrapped the whole thing into an execute function. The reason for this is that I don't just want to put a comment in saying file infected, because that's kind of boring and it doesn't serve any purpose for an evil packer like me. So I actually want to pass in the virus that's going to be run or inserted into the destination files. The rest of the code down here is the same except down here we write the virus in to the new file, the dot infected file. And then down at the bottom we have the renaming of the files, but then right at the end here we have an extra four lines. So what we're doing is we're creating the virus variable, which is the contents of the current file. Double underscore file, double underscore is a reference to the file that's currently running. So boom.php is going to get the contents of boom.php and it's going to add it to the, assign the data to the virus variable, and that then gets passed into execute down here. Now, one of the issues with that is that we have a start php tag at the beginning and a close php tag at the end, and we've got a whole load of other code in there that we actually don't want to infect the file with because that's going to break the original php file. If you have an open php tag followed by an open php tag and two closed php tags, that's going to break, or at the very least it's going to provide an output that alerts the user or the person running the script that something slightly dodgy is going on. So you'll notice here that we're looking for a line that says virus start and virus end. We scroll up to the top again, you'll see that I added a virus start at the top. We scroll to the bottom, you'll see virus end. So essentially what we're doing is we're finding the positions of these two markers and we're making sure that they are now the start and the end of the actual virus. So we're cutting out everything outside of it. We've now got control of exactly what goes into the file. Is that making sense? So if we have a look at our example file again, it's uninfected at the moment. If we run our boom file and we look at our example file again there, we've got the virus and you can see the virus start is up there but the original php open tag isn't. If you scroll down to the bottom, you can see that the end virus tag is there but the original code still exists. So now we have a virus in the example script. So let's create a new file, foo.php. Did I get that right? I did. Typing in front of conferences. Always tricky. Right, so if I run foo, we should get hellophp.conf Asia. If I run example, we still get one through nine. Now if we look at foo, foo has now also been infected. So it's actually a proper virus now. It's infecting and it's infecting and it's infecting again. So the next step that we want to do is that script is obviously, like if you looked at that or you had any kind of semantic analysis in an antivirus system, look at that code. Notwithstanding the fact that the word virus is all the way through it, you'd probably be able to guess that it's a virus. There's certain aspects of that that an antivirus system would pick up on. So let's encrypt the virus completely so that an analyser that wasn't able to decrypt. Yes. Boom.php will also be infected again. And we'll come to that in the next step. It's a great question. So because boom.php infected example, an example then infected foo, example would also have reinfected boom and it would have reinfected example. And in step four, we'll find out a way to stop that issue happening. But before we do that, I'm just going to go through the encryption process. So that goes back to the right place. So what are we going to be doing here? So the virus that was passed through at the top there is still being passed through. And then you'll notice down here where we're adding the virus into the file. We're passing it through another method, another function called encrypt virus. We want to take the virus and we want to encrypt it. And then further down in the code, we skip down, we'll see the encrypted virus. I won't go through too much on exactly how encrypt works. And for those of you who are into security and encryption, you'll probably know that encrypt is not the best function to use nowadays for encryption. But at the end of the day, we're not actually doing this because we want to encrypt data for security. We're encrypting it because we want to obfuscate it against antivirus systems. So we're going to create ourselves a key. We're going to create an initialization vector and we call the encrypt encrypt function to create an encrypted version of the virus. So if any of you have ever worked with encryption before, you'll probably know that the information that gets put into that encrypted virus variable is not actually ASCII anymore. It's going to be a binary data blob, essentially. And that's a very hard thing to put into a file that could traverse different file systems to be able to interpret and decrypt in certain ways. We want to provide an encoded method of passing this information around. That can also be put into an ASCII file without drawing too much attention. If you have a whole data blob inside a PHP file, that's probably going to draw attention to antivirus systems as well. And remember, we want to lay low. So what we're going to do here is we're actually going to base 64 encode all three variables. We're going to take the encrypted virus, the initialization vector and the key. Now, if I wanted to send you a secure message, we might have a pre-shared key or maybe we're using public-private encryption. I would send you the encrypted data only. I wouldn't share with you the key that I used to encrypt it in a public channel because obviously then anybody could decrypt it. So if you're writing a secure system, don't publish the key. But if you're writing a virus, it's totally fine. So we're going to take these, we're going to add them into these encoded variables here, and then we're going to generate a string. So remember, we want to write a string into every PHP file in the system that is a virus. So at the moment we have a load of data that we need to put into the virus, but we don't actually want to run it at the moment. So what we're going to do is we're going to create a string which is basically PHP within a string which will later get evaluated. Eval is evil. It's why a lot of viruses get through. So don't enable Eval unless you actually need it on your production environment. But in here we're going to pass in the three variables we've just encoded and we're going to write the decryption PHP into the string. So it's not actually decrypting at this point, it's just generating the code that will later decrypt the virus again. So that makes sense. And then we basically, we also include in there the Eval and the Execute that again in the strings that's going to get run later and we return the new payload. So the virus that now gets inserted should be encrypted. So if we look at our example file again, it's just echo one through nine and if I run boom, we now have this instead of the original virus. So we've got the encrypted virus, the IV and the key, which are base 64 encoded bits of information. And then we determine that the virus can be decrypted by using the key, the encrypted virus and the IV, all gone through the base 64 decode method. So it gets turned back into the binary equivalence of what we needed. And then we have virus now contains the original string of the virus, which was the original file from boom.php. We can then evaluate that, which means that we now have an execute function in memory and we can execute the virus, which will then infect the other files. But by looking at this, again, other than the fact that the word virus exists everywhere in there, you can't tell readily that it is actually a virus. I would recommend if you do plan on doing this and putting it into production, first of all, don't tell me, don't tell anybody else, but also don't call it encrypted virus. It's a dead giveaway. So the question that I had earlier was what happens to boom.php. If we look at boom.php now, we can see that the encrypted virus is at the top because boom.php infected itself. And if we scroll down a bit further, you can see that the original text is in there because that was the original unencrypted virus that was in boom.php in the first place. If I edit foo.php, I'm going to make my life easier this time. So now if I run... So we know that boom is double-infected. We know that example has been infected. We just saw that. We've now got foo, which has not been infected yet. So if I run example, I'm just going to clear that to get it at the top, it helps if I type php properly. You can see that 1 through 9 has come out. We've got no side effects, so the original intent is there. We know that there was an encrypted virus inside example.php. And if we now look at foo.php, we can see that foo has been encrypted as well. But if we look at example alongside it, we can see that there's the encrypted virus there once, and if we scroll down a bit further, there's the encrypted virus there again. Which means that if I run example again, do we know what's going to happen? Execute has been defined twice now because it's in there twice, it's been decoded twice, and then suddenly you can't have the execute function in the same namespace twice. So we get an error, and obviously that's something we don't want to do. We've now got a virus that will infect your whole system, but echo errors everywhere. So how do we get around that? We get around that with step 4 of course, that's the answer. So let's have a look at what we do in step 4. So we've got the execute function here at the top here. We're going through all the php files and we go through them. We want to check that it's not infected. So what we do is we get the first line of the script, and the idea is we're going to put a marker in there to define whether or not it's been infected. We then generate a hash, which is an MD5 of the file name, and that's basically going to be what we use as a marker. And if the first line of the virus contains the hash, or in this case because it's false if it does not contain the hash, we can assume the file has not been infected. So if we scroll down, we'll then see that what we're going to do is we create the infected file as we did before, and then we write a first line here, just check some, followed by the virus hash. So we're going to write that in as the first line on the infected file. And then we write in the first line from the infection. Now, because we read the first line before we were doing this, we were adding in the first line, and then we were basically doing read, write, read, write, read, write. But because we've read the first line already, that's been consumed, therefore the file point is now pointing to the second line. So the first line that we got from the original file, we need to make sure we put that into the new infected file first before we lose it. And then we can carry on with our loop. So we put in the checks and we put in the infection and then we put in the first line that we grabbed just up at the top there. And then we can carry on through the rest of the file and write that into the new infected file. We close the files, we delete the original and we rename the infected one. So now if we look at the output of PHP boom, we get nothing. We look at the content of example and we can see the virus in there. If I run PHP boom again now, this is actually an issue because boom.php didn't have the checks on the top. But if I run example again, because example does have the hash on the top, we can run that as often as we want and it's not going to reinfect itself. If I edit foo, check coding, there we go. So foo at the moment just echoes out an et. If we run example, again we don't get any errors. We look at example, there's only one virus. We look at foo, there's only one virus. We run foo, there's no errors. So we've now got a virus that's infected to both example and foo. They're not infecting themselves again, in fact because foo ran and example was already infected it also didn't reinfect the example file. So I think we've got a pretty robust virus here now that we can try and upload into a system that's not going to cause any side effects in terms of the user realising that something's going on. Anything that infects will carry on doing exactly what it did before, whether it was numbers 1 through 9 or an et or whatever we're looking at. I think the best thing to do is to try and find the infection mechanism there. We've got the virus, we've got the payload. We'll look at a trigger soon. We need an infection mechanism. To do this I wrote a, because every good developer writes everything from scratch themselves, right? By the way, you'll notice here the directory name, vagrant. I'm running all of this in a virtual box. I've learnt from experience when writing viruses that infect PHP files not to do it on your host machine unless you're absolutely sure that everything's committed to git. If there's one lesson I can give you today, that's probably the one. I have this very simple gallery system, which you can see right here. So simple it uses Bootstrap because I'm not a front-end developer. It contains three files. We've got our index file. What I wanted to do by creating this very simple gallery was to create something that used a lot of best practices in terms of security to make sure that nothing can get in that shouldn't be able to get in. In order to generate the front page, we've got a whole lot of HTML here, but the main point of interest is this part here. So we've got a 4 each here, which goes through gallery images, which is a directory that's outside of the document root. You'll notice the .dob slash. So you can't actually get to these images directly through the browser. So it goes through all the files in that directory and grabs out the image name. And then it'll pass that image name into the show image PHP file as a parameter called file name. So we're making sure that we're using, because obviously the browser can't access the file directly, we need to help a PHP script to grab the data and send it back to the browser. But in that PHP script, we'll be able to put some more validation in to make sure that the image is something we actually want to display. Let's have a look at that file. So we have a system here. The first one is going to check the referer. If you're submitting a file from another system, we don't want any cross-site image injection. I think I just coined a new term, cross-site image injection. Is that a thing? It is now. So we check that the referer is who we're expecting it to be. We then make sure the file name is same. So we're going to make sure it's only got alphanumeric letters, dots and dashes and stuff, but no slashes. So you can't escape out of directories by passing in .dob slash dot dot slash whatever else. And then we make sure that the gallery images directory is prefixed in front of it. So you've got your file name. We make sure there's no silly characters in it. A known good pointer to an image that should exist in gallery images. We make sure that the file mime type is what we're expecting. So we take the image type from the file name and we check it against... Where do we check it? Maybe it's a bit further down. What we do is we take the mime type and we echo it out as a header. So we actually check the mime type is something we like when we upload the image. But we take the image and we say, make sure that header is sent to the browser first because obviously a PHP script is going to return an HTML mime type header by default. So we make sure the mime type is correct for the image and then we include the file name which is basically going to take the data of the image and push it straight out of the browser. Yep. So let's just have a look at how files are uploaded. Similarly, we have our acceptable mime types up here. So we've got PNG, JPEG, GIF and a few others. We make sure that first of all the file has been uploaded. There's no point in trying to process a file that doesn't exist. We check the mime type. We make sure that it's in this acceptable mime types array. We then use the same regular expression to make sure the file name is sane and we move the file into the gallery images directory. And then we send the person back to the home directory, the home page. All make sense? Nice and secure? No bugs in there at all? Well, says Rasmus. Well. So let's have a look at what happens. So we'll jump over to... Actually, the first thing we need to do is I have this image called bread.jpg and if we look over here... I need to click on the browser button, Benjamin. So we have in talks, files, images, bread. So you can see that in the preview we've got bread.jpg. But the first thing we're going to do is we're going to do infected. How many people here understand the file format of a jpg file? A couple. So I'll show you. Interestingly, Vim doesn't autocomplete jpg when you're trying to edit a file. But I am going to Vim... Hmm? Minus B? Where am I going? Do I want to edit it in binary mode? I just want the autocomplete. So I still want to edit it in ASCII mode. So I'm going to Vim files, images and yet autocomplete for bread doesn't work because apparently they think that you don't want to edit binary files in non-binary mode in Vim. But here we have in ASCII mode our jpg file. Now you'll notice at the top there's a first line which contains JFIF and a whole lot of other information. You've got the creator jpg. You've got somewhere in there it might be off the end of the line. The quality, like 70% or whatever quality that's basically the first line header and everything after that is the binary data for the jpg file itself. So one thing you can do is if I grab our boom file so I'm currently on the first line there I'm just going to hit paste. I'm going to stick a PHP script directly into the jpg file. Now some of you might think well that's all very well because I imagine at some point it's probably going to be executed and it'll be taken out again by the PHP interpreter which means that the jpg will still run fine but the thing that I found interesting when I was creating this is that if we just go back just to make sure it's refreshed the preview of that file still looks like bread. So even with a PHP in there and this works on Linux as well they haven't tested on Windows but Linux and Mac OS will still preview the file without any issue so you can affect an image give it to somebody else and you might not even know there's got an infection inside it which I think is kind of cool. So let's select that file and upload it and here now we have bread so bread file has been successfully uploaded moved into the gallery images directory gallery images we now have bread.jpg in there if we look at bread.jpg which is not in that directory we can confirm I think it just slid off the top there well this is a fun presentation look at that everybody's going a little bit there we go there's the code so we've got our infection in the jpeg file if we now go back into the www directory and look at the index file we can see there's a virus in there because as the bread file got uploaded it then got displayed on the main page and got infected can anybody think why that executed I used include so even though I checked the mime type so I put it outside the file directory the document root include will actually execute any PHP in the file that it brings in as well as then echo anything out to the browser so you can be secure by one small misstep and often we can find this in everyday applications nowadays WordPress gets a lot of bad rep WordPress core itself is actually pretty well it is a pretty well written tool but the problem with WordPress and a lot of systems like it is a good party plugin community so the plugins themselves again are perfectly well written most of the time but as soon as you get two plugins that kind of clash with each other you can get some really interesting side effects and I found one about four or five years ago where there was an image manipulation tool and a whizzywig editor and because of the way that they used data in different ways and escaped data in different ways you had an injection attack vulnerability similar to the way we have bread.jpg here with PHP in it and it will get executed so it wasn't that WordPress was insecure it wasn't that either of the plugins themselves were insecure but the combination of the three written by three different sets of development teams is what caused the issue so we have to be very... how many people here will take a third party library through NPM or Composer or whatever platform you are using and do a full code audit through their security team on it here nor me even though the premise of this script there's some fallacies in the fact that sure include an average developer might notice that that's the issue we can't always know what other scripts are running in our ecosystem within our applications so what I like to do now that we've got an infection in there is have a bit of fun with it so you might have noticed that I actually loaded boom from step five I put an extra bit of code in step five's boom which means that I can now run things like let's go to browser so I'm not sure if you can read that at the back but it'll come up in larger text soon but essentially I'm passing in a query string with a key of eval and the value of PHP info so essentially the code that I've uploaded has a little switch in there saying if the eval parameter is passed then evaluate whatever's passed in which is a perfect virus because then you can run whatever you want here so you can see their PHP info at the top left that's basically exactly what came in WordPress not the vulnerability that I was testing the other day which I'm still trying to get into this demo the other thing you can do is something like this now this takes a little while because I don't actually have a mail server running on my virtual machine at the moment but in a second it should fail and tell you that I just tried to send an email to myself so I'm sending myself spam so if you infected a whole load of servers you could then use it as an email spam mechanism as long as they obviously had SMGP mail configured but the most fun one is probably hijacking a website altogether so this one here doesn't do anything visual other than the fact that it prints it out at the top there because my virus prints it out but your virus doesn't have to print out the fact that it's affecting something but if we follow this through essentially we're going to create a new file called a.php because remember again I was saying before sometimes you can't actually edit a file on certain file systems in this case because index.php is actually in memory an opener file there might be a file lock on it so we can't edit the file itself that's running so we create an a.php file to start with and we create a variable called header and into that we put in location 218.php.flotAsia and then into index.php we write that as the header so a.php is now going to contain php and that php is going to change index does that make sense so now if I go to a.php it doesn't look like it's done anything because that script that we just saw up there doesn't have any side effect other than editing index.php but if I now go back to the home page I'll completely hijack the website and take those to the php conference website and you could use this to just do whatever you want to any of these websites there are certain precautions you can take such as making sure that the files aren't writeable by the web directory by the web user but yeah that's the virus in a nutshell and I'll press the wrong button which means it started the presentation from the beginning again we can probably take one or two questions in a second so payload ideas we've already just had a look at the eval now you could have one eval that basically runs whatever you like but you might want to contain the virus and constrain what it can actually do so some other ideas that some people at other conferences have come up with was a dedicated DDoS system which basically will request files from a remote system so you've got this drone attack to take somebody else down the most interesting idea was somebody saying well why don't you just host a JSON file it contains a whole load of commands so that these drones just basically pull a command list and execute those and you can have a switch statement in there saying if the command is DDoS then DDoS that so you could mix that with a whole load of evals and create a JSON or YAML for viruses which could be kind of cool we should standardise that I think that needs some RFCs around it but ultimately why am I telling you this we all took a pledge at the beginning writing viruses is not the best thing to do if you want a harmonious and peaceful life and humanity so why am I telling you about writing viruses the reason why I started doing this was because I talk about security and privacy quite a bit and one of the things that I've always tried to do is to help people to understand how best to secure the systems and I thought well if we can actually think like a hacker if we can think like an evil person surely that's going to give us the opposite side of the coin we can think if I wanted to break the system how would I do it and protect yourself in that way and all the layers of security which is not a bad thing but they can tend to be in areas that maybe aren't the most risk the areas that you need to to fix of highest risk there might be higher risk areas somewhere else so evaluating your system from a negative mind space, head space can allow you to think of areas to focus your time and attention on in bad ways but ultimately the main reason I did this is because I want to get my hands dirty and I think as developers we can often day to day get stuck in the work we're doing and sure we get some R&D time every now and then but we need to play with other things and I think by writing a virus that's not something we would do in our day drop does anybody write viruses as their day drop yeah cool does anybody write viruses as their day drop but they don't want to admit to it so I think we need to play more we need to go outside of our normal day to day box if it's a new language or even a new construct or a new way of thinking I'd like to encourage you all to take that mind space especially through this conference when you're seeing other talks in areas that perhaps you haven't touched on before take that learning away and play in ways that you haven't before after you leave the conference so remember your page and thank you very much so in order to protect myself is there any kind of I don't know how do it but like any way to check some each of your PHP files so that prior to execution there'd be a checksum to verify that the file has not been altered so if you want to protect your file from change the first best way to do it is to make sure that the web user can't change the files if you're in a situation where you can't do that for certain reasons one reason for example that people keep their WordPress files writable is because WordPress has a self update mechanism that you've then got the question of do I want to stay up to date and secure or do I want to make sure that nobody can change our files because there's a balance there that you need to take into account if you did have a mechanism for putting a checksum into a file to check before execution you have to remember that the virus could change that checksum if it's aware of the system that's in place one method that I have seen used if you're looking at wanting to keep your files writable because you want automatic update systems a colleague of mine many years ago ran a WordPress hosting platform and essentially he would keep like a gold server the main top level server that was the most up to date information and that would not be accessible via the web and it had files that were writable by the www data user when WordPress came out with an update it would automatically update it and it would commit that into the get repository and then all of the slave web servers would pull from that get repository into a document root that wasn't writable by the www data user which meant that they were getting the benefits of the real time updates but if a virus did infect those systems they wouldn't be able to infect the files so there are ways around it in terms of deployment processes but I probably wouldn't recommend going down just because that adds extra maintenance and overhead potentially another security vulnerability in that isn't like a eval usually disabled by default or something like in most shared it depends on the PHP version you're running it also depends on the hosting environment if you're in shared hosting environments for example then perhaps it could be different but if you have total control of your environment sure you can probably guarantee that eval is disabled but again eval isn't the only way of getting a virus into the system either it's just the way I used it one last question anyone? any budding virus writers around here? no? yes? well I'm going to be around for the rest of the conference anyway so come up and have a chat with me that would be great