Antti Rössi: How your PHP application can get hacked and how to prevent that from happening? @PHPCon

I should otherwise thank you so we're going to start the day by talking about security serious serious things seriousness yes I'm from Finland I'm serious and that's why I talk is serious as well we don't really smile there how your PHP application can get hacked and what you can do to prevent that from happening it's the title of my talk couple of words about me first so you know who on earth is talking in here and why am I talking to you about security my name is on piercing I come from Finland and by trade I'm an IT entrepreneur so I've been running my own company for the last six or seven years roughly and basically main focus of my days has been developing software a lot with PHP laravel vanilla PHP JavaScript all kinds of web technologies in the recent couple of years however I've also sort of stepped in the into the cyber security scene and I'm nowadays an offensive security certified professional I'm trying to remember how that how that were to go so I'm basically one foot in development and the other fruit in penetration testing and information security and that gives me a sort of unique perspective I would argue regarding PHP and security when you have a PHP developer and a hacker in the same box that's why I'm here now I strongly believe that the fate of our users is in our hands as developers and admins it's simply not feasible to expect for the majority of projects that you would have special security personnel available when our clients our bosses are our users mostly first and foremost our users when they use software that we have built they expect it to be secure they don't really care who makes it secure but usually it's it's you get the spec you get you get to build it you get to test it together hopefully before you release that's usually a good good thing to do and then get to maintain it you get to run it in production there's no specified step usually where you would have some magician testing and making sure that everything is secure and if not something wasn't secure you could blame somebody else no that doesn't happen usually so it's all on us if we write our code properly and if we know how to deal with PHP and securely stuff is going to go pretty well on the other side if we don't our users are going to be in trouble so our users clients and employers expect that we know about security that's why I'm really really happy to be here today talking to you about security now hackers on the other hand let's look at that girl's perspective hackers love each cases and quirks of technologies as a developer most of the time you're you're really thinking about the user flaws of the of the user stories and the designs and specs that you're working with so you focus on things going the way they should go where on the other hand hackers think completely completely different and that's why when a hacker looks at an application we're constantly thinking if you write the pen tester in an engagement for example you're constantly thinking to yourself how can I break this application in a way that developers have never even thought of are there some features new features or old features in these languages or frameworks that the original authors have no idea about that I could use against them that's how a hacker thinks that thinks and that is specifically why we as the developers need to know about these specifics they might not be useful for building features faster but you're gonna see in a minute what I'm talking about and why they are super super important to know about so here's the deal if you know the basics of hacking I urge you to hack yourself first before somebody else does when you hack yourself first you have a chance to do that in a controlled environment where no data is going to get breached nobody's going to get hurt no one is going to get fired and you get to patch those vulnerabilities before an actual malicious actor exploits them and that's going to be the core idea of this talk so I want that you walk away from this talk having a couple of new ideas and a lot of motivation to learn more about PHP and security that's my goal of this talk before we go into the actual hands-on examples however there's a disclaimer that we always must have I am not endorsing anyone to hack anyone else's websites as a rule of thumb that is illegal now I don't know about laws in other countries except Finland really but especially in Finland even even trying to hack somebody else's website will get you in jail even if you don't succeed so even if you don't know what you're doing and you go out doing stupid stuff like this you're gonna get in jail so please don't do that the reason we go through hands-on examples is that hacking and these vulnerabilities and exploiting them should not be taboos we as developers need to exactly know what it looks like what the hackers do and when they succeed what what happens how can we detect that because even know about that in very very specific details then you're helpless well one might ask then if you get some good tips from here and you get excited you want to learn hacking where can i practice this then if I can't just randomly go around and attack servers and companies out there I'm practicing like that so that's an excellent question you can download these examples from my github page you can find a link there from my Twitter my Twitter is well I'm not going to pronounce it you can read it from there or if those examples are not enough there are certain brilliant services out there online such as hack the box it's a great company that provides a free set of vulnerable machines some of them here to be some of them other technologies where you can practice these skills in a controlled lab environment without breaking the laws or causing harm to anyone okay let's get our hands dirty majority of you have most certainly heard about sequel injection I would expect since you're here we're going to look in sequel injection next deep down in sequel injection there's actually also no sequel injection by the way so no sequel doesn't mean no problems in this context either like it doesn't in many other contexts in sequel injection attacks the attacker injects malicious queries malicious sequel queries into some form of an input device and in our case it's most usually is going to be HTTP requests since we deal with web a lot with PHP and if sequel injection attacks if they succeed majority of the time you get the whole database content out through that hole all of your data because of one single mistake now here's a very basic example this is using eloquent which is levels or am hopefully you heard about don't pass unsanitized variables in R or arrays blah blah blah all of that basic jargon that hopefully when you get started with PHP you get taught now this is one example that will make you vulnerable to sequel injection but the problem is that certain edge cases can be really really hard to test and hard to hard to find you don't necessarily spot them in code reviews because sequel injections when they happen in the wild and big companies get trouble because of those those vulnerabilities they are not easy to spot and that's the problem because there are certain edge cases when you have highly abstract at a nested code around your repository classes for example that you just simply can't spot in a code review unless you're like a specific PHP penetration tester or something that there are sometimes really really hard to spot the biggest danger however usually lies within our attitudes so it's it's not even the biggest problem is not even that there's sometimes hard to spot but these are some some quotes that I've either personally thought or said out loud in the past and I've heard some some developers say out loud so in certain cases you might have an API endpoint that theoretically might be vulnerable to sequel injection but a developer might say that but there's we're not even returning errors so there's no way for you to do anything with it even if it was vulnerable because there's no data coming back how can you get data out when there's no data coming back I've heard people argue that and try to sell themselves why this is not a problem another case and this was actually my thinking from three years ago before I got into penetration testing and cybersecurity I was thinking that mani even if you have a vulnerability which is really really hard to find a really hard to exploit there theoretically no one would export it if it takes you a year to get anything out of it because sometimes exploiting blind TV injection vectors are super super hard to do blindly that's what I thought but guess what I had never even seen what the sequel injection actually looks like when somebody performs it and sequel injections are actually really easy to test for with proper tooling so it's not only us the developers that use tools hackers have their own frameworks and tools as well and the tools that test for sequel injection also make the exploitation process really easy for you and we're going to do that next here so I will show you what I mean because I truly believe personally my eyes opened when I saw this thing happen for the first time that's why I believe it's not enough that we just talk about these things theoretically so to make our life a little bit easier I pre-recorded this last night you can see well prepared there multiple weeks in beforehand so within this example application but you can also download we have a very simple API endpoints so it's returning Jason nothing fancy in here you can see there is a Europe Ram can you actually see this laser yeah that's pretty cool I've never used this before so yeah okay nice there's your parent you are a pram called sort that takes in a string value and you can specify a column to sort the data by basically so very basic stuff now the developer of this application however probably for convenience reasons you can see if you specify - and the name of the column it inverts the sorting order which price price represents exactly how raw sequel queries work for example so hacker when they see that they might think oh there could be a row sequel query behind this endpoint now we're going to be using a tool called sequel map I hope you can see the font because I can't actually zoom it a little bit a lot because it's a it's a video so sequel map takes in the URI sorry the URL of the endpoint we want to test together with the parameter that we found the only thing we need to do besides that just to make a little bit faster we're gonna tell it but the database management system is my sequel so that doesn't test for ms ms SQL and oracle DB because we happen to know we just want that to go a little bit faster and the bad flag says don't ask any questions just run now this part of the video has been sped up the 3,000 percent or something so sequel map what it does for us it actually performs hundreds and hundreds of different types of tests against this API endpoint and well in this video in very fast in reality depending on the server's response times it might take twenty minutes or so it comes back with the result and we can actually see that yes sequel map found three different injection style attacks but this endpoint is vulnerable to and they're all blind boolean blaze boolean based blind error based blind plan based blind so we have a blind injection fact they're very very painful to exploit manually in information security if you claim if you go and claim that there's a vulnerability somewhere as a rule of thumb you need to provide a working proof of concept you need to prove that that vulnerability not only exists but that it's exploit Abel and that's the reason why sequel also does that part for us so let's change the batch flag and say tell us the current database of the application and it starts running running running okay vulnerable underscore app it's the database that the application is running let's go deeper let's go into the database vulnerable app and ask for the tables it's going to run it's going to search them one by one it's going to come back with the tables now obviously just to go as deep as we can here there's an interesting table called users let's have a look at that could we get could we dump the contents of users with this tool without actually having to write single line of code or to hack anything manually yes we can we can get like I said earlier the whole database out through this hole without having to do anything manually now a 12 year old kid can use this tool they can install this tool with home brew brew install seek warm up on their Mac but I'm run it and hack you if you haven't tested your own API endpoints with this tool and since it's so easy to use and so easy to hack stuff with it's not an excuse that you don't know how to do it now you do you've seen alive how it happens and that's usually a way how sequel injection vulnerabilities get exploited the second exploit that we're going to look at andover vulnerability that we are going to export is called object injection now raise your hand if you have heard about PHP object injection before in your career okay less than 5% of the room that's good and bad thing and news at the same time good news is that you're going to learn a lot from this next section bad news is that if you haven't heard of this you most probably haven't been able to check is your application vulnerable to this so we're going to go from far DC realization to remote code execution next quick theory lesson first however since we have some potentially foreign concepts but we have to mix quite many not really complicated but potentially weird PHP concepts together in order to find this exploit and this vulnerability so stream Preppers in PHP provide us with a really nice abstraction over different protocols like rar SSH FTP in this context we are going to be exceptionally interested in the far stream wrapper that's going to be in the very core of this vulnerability now for files are basically single file bundles that have a complete PHP application in them composer for example is distributed as a far file so you download a single file you have everything you need in it you can run binaries out of it you can version it distribute it easily so it's actually very similar to you've probably at some point of your career use jar files in the Java context for example so far fast jar files very very similar concepts and surprise surprise the far extreme wrapper allows us to read PHP files from a PHP archive that's what it's for so it allows us to use for files within our code to easily read and write into them or or from them now object serialization which is the other part of this vulnerability on the other hand means the process when you turn an object into a string and obviously the other side of the process is the DC realization process where you turn that string back into an object now here's an example let's take this arbitrary class called hulagur that has a couple of attributes and a couple of methods in it let's new it up and print out the serialized version of this instance this is what we get so we get a string now this string contains all the bits and pieces we need in order to put together that very same instance of this class that we serialize so it has the name of the class that's being that mostly realized it has all the properties of the class and their values and well their length and that's basically all you need no methods are included however in the serialized objects which is actually a brilliant move security wise because that would be horrendous if you could actually just go there and manipulate the constructor of the object to do whatever open a reverse shell to you when you new up the class that would be horrible and the reason why it would be horrible is because when you t serialize an object it's injected into your current application scope from where you do that the serialization from and that's bad news is that object contains malicious code in it here's the catch number one even though we can't control the methods of the object that gets serialized there are two magic methods that get called nevertheless first one is related to the process of D serialization that's when the wakeup is being called and destructor the object destructor is called just before garbage collection when there are no more references to that object in the application run times memory basically so in theory if we could find a class that looks something like this this is a very very crude overly simplified example to just highlight the point if we could find a class that works something like this so it would run some potentially dangerous function and we could influence the R arguments of that function using the attributes of that class now that would mean if we have a serialized version of that object in of an instance of that object so if we have a see realized object like that we could actually target this attribute that's been passed into the system call and we could change it at the very moment when you would unsee realize this object in the application run times memory this would happen we will get code execution now this kind of cases are so-called gadgets so an exploit development we call these gadgets and gadgets out basically chains there they usually come and change but they're pieces of code that allows us to circumvent some security measurements and execute something or read read a file or write to a file usually that's what we do with gadgets now here's the catch number two PHP archives contain metadata which doesn't have to be but can be in a serialized format I know this was a completely new part to me personally any file operation on the PHP archive will cause the page we archive metadata to be unsee realized once you realize this the name of the function but these you realize this that grammatically correct term to use for that any file operation now here are some file operations that you've probably used hopefully maybe when I'm using these methods personally or at least before I knew about this vulnerability I would never ever imagine that there's any potential danger in calling file size on a file regardless of what actually goes into that function I personally couldn't imagine how could you exploit a function like file size what can you do with it it doesn't really it doesn't execute anything that you could control you can't hijack the control anyhow but with the catch number three with four stream rapper it doesn't give a crap about what file types you pass into it if it finds PHP archived within the input stream you pass into it it's going to read it now if we put these pieces together this ought huzzle of different contexts and concepts if we take an image file we plant a plant a malicious Farr file within that image we hide it in it we're going to call file size on that image for example which is a very common thing if you have some some web application with avatars user avatars for example that there might be like a file size check within the uploader method which usually gets called for example so getting this far it's not really hard the object that's inject that's hidden in the metadata of our malicious archive is going to be injected in the applications runtime when that happens and our gadget if we have a working gadget at that point the gadget is going to kick in on this truck which usually happens immediately since there are very frequently there are no more references to those objects left in the memory so the D structure just basically runs in the end of the PHP lifecycle before the responses returns so this in theory is how an export would work this in practice is how an exploit like that will work I love the silence everyone's freaked out what are you doing well be using a tool called pitch be GGC for the generation of our payload it's an open source tool anyone can can use it anyone can download it so p2p GGC allows us to easily create surprise surprise gadgets and gadget chains it has a set of ready-made gadget chains so we don't actually even need to go and look for gadgets within our vendor dependencies manually we'll be using this guzzle remote code execution gadget in this example and you can actually see it's it's a it's patched in the latest version of guzzle but it still exists in four months old version of guzzle so if you haven't updated your dependencies in four months you are most likely running something vulnerable with in production right now it uses the destructor vector and because hackers are lazy they bundle everything into this one tool so you can do from start from from beginning to end everything with the single tool it also allows us to embed these payloads into images directly know how convenient is that so let's take an image I have an image of my cat here obviously because he's a bit malicious so I like to use him as an example his name is morning so a regular jpg there's nothing cheesy going on with the image it's it's basic image so we'll pass that image into PHP GGC specify payload and what we can control here is that we want that the gadget chain ends with a call to function called pass through which works exactly the same as system or shell exec in PHP does and the input argument to this function is going to be I D which if you know some Linux command line stuff is going to show us the current user ID of the user that's running the process then we pass in the image of money and we say that let's just call it ID attach a pack that malicious image that comes out and it does its magic really fast if we open that image in chrome you can see the image looks exactly the same from the surface you can't tell that there's anything going on with it if you look at the stream content of that file however and you grip for ghazal you can see that in the middle of that image lies our payload that's our gadget chain that's what's going to get injected into the applications current application scope if we manage to exploit this vulnerability now there is an API endpoint for uploading files within this example application that you can download and play around with which has all the basic file size validations etc in place so you can see a regular file type validation won't do no good it won't detect this there's nothing wrong it's it's a valid JPEG so it goes through success now there's another API endpoint where we can get some details of our uploaded files and we'll pass in the name of the file in this method or in this API call we can see in the response there are a couple of attributes like the size or last modified that could be using PHP files filesystem methods hmm now I'm going to spoil this a little bit and just show you the code before we actually run the exploit so you know what is what is actually happening under the hood here so yes it's it is calling filesystem size which and filesystem last modified which resolves under the hood into the actual PHP file size call so we can see that this is a vulnerable vector or very potential vector Oh No now instead of passing in the plain image name like we just did let's see what happens when we pass in a far stream wrapper prefixed name of an image oh no before the JSON output starts we see the output of our comment so we have remote code execution on the machine and trust me it gets even worse what the hacker does the very first thing they do when they get remote code execution is the day they won't have a shell they won't start an actual shell and usually you can start that up always there is a way to start that if you get remote code execution now this example is running in a docker container so that's why I'm writing a docker alias here let's trigger a TCP connection from the target machine using netcat it's going to dial back to our attack attacking machine about 1337 and with the e flag we're going to pass in a bash shell into that TCP connection we'll call that image reverse dot jpg it's the very same image image of mo'ne again we'll just upload it to our example application identical process now in another pane before we actually trigger this exploit we have to start the listener so that we're ready for the incoming reversal connection so we'll use net cut on our end as well to open a listener so we'll be listening on all interfaces and port 1337 it's going to be a TCP listener then let's trigger the exploit and now you don't you don't see anything it doesn't actually tell you even on a Mac for some reason that a new connection came in but if we start to issue comments into this netiquette listener the server responds Mac we have a shell so basically that server got pretty much completely owned through this one simple mistake that the developers were not checking and sanitizing there's no reason for you to be able to pass in slashes into file name attributes for example simple mistake dramatic results absolutely dramatic results now you're probably thinking well okay that's that's pretty bad that's pretty bad let me tell you it's gonna get even worse it's going to get even worse the last section or the last exploit before we start to quickly go through some countermeasures against these attacks are going to be about a technique called privilege escalation in previous escalation the attacker exports a bug the design flaw or configuration floor to access resources that they should not have access to like you saw from the reverse shell yes we had shell to the machine but we're not satisfied yet we're not admins yet we're not route we want to be rude usually when you're escalating privileges if you don't have an admin hash or you don't have an admin password there's simply no way for you usually to start the new admin process so it's much easier to find an already running process with sufficient privileges and exploit that so find something that's already running as root and exploit it and if you manage to hijack the execution flow of that process without crashing it you can redirect it anywhere you want you can redirect it into a new shell for example now for this exact very few things should ever run as ruled on your host machine production machines your host machine staging machines any machine very very few things should ever run as root your scheduler and queue workers are most certainly not one of these things the problem is however when you spin up a new virtual private server depending on the cloud provider by default some of the message you in with root access and if you don't explicitly set up user accounts with different privileges and set this up running with those privileges you're accidentally going to execute stuff as root that's a problem we're going to find out why so we'll continue from where we left so we have a shell so we open their listener again we just restart the shell now don't worry about these comments unfortunately we don't really have time to go through everything I would love to this would take the whole day this presentation but we are going to have to configure our shell to actually behave like an actual shell since it's it's just a random TCP connection that doesn't really have all the benefits of shell you can't use arrow keys you can't use interactive comments and stuff so in a nutshell what we're doing in here is that we're wrapping that shell in a Python PTY and then we're configuring some variables to make sure that our target machine and our local machine are in sync so that when we're running interactive comments each knows exactly how many columns and how many rows does our terminal have so that our output doesn't just get absolutely mingled so after those a couple of quick hacks we can finally it even looks like a shell you can see from here we see the user and stuff we can actually run comments on the server and we can run comments such as vmon which means we can edit files on the server now this example application is built using a laravel and in levels context the laravel scheduler is being operated from a class called console kernel so we open the console kernel with vim and let's have a look are there any comments scheduled in here that we could tamper with ok the scheduler method is empty we only have something that's commented out which looks like basic stock code basically now how the process scheduling in this context works is that you either have a scheduled schedule what what on earth do you caught and Windows scheduled service I think system service that runs the scheduler of your application that then in conjunction runs this stuff or in Linux you're using the crontab system to execute this very same same piece of code let's execute the comment let's try what would happen now by the way as a rule of thumb if you can execute PHP you're going to find a way to execute system of all comments as well most of the time there is a way for you to get there now scheduler it makes it really easy for us because it has an exit method so we're like whoo we don't even need to circumvent this let's try something that looks quite familiar let's see what happens if you're on net cut from the scheduler and I are back to our attackers machine our machine in two different port this time let's see what happens before we actually execute this we're gonna have to open a new listener obviously on new tab so we got the listener running we're gonna save the file on the server and then let's wait we know that the smallest interval that you can configure with Linux cond up is once every minute so the Linux chrome tab runs once every minute so let's wait for a minute to pass seven seconds so we know that crontab at least executes and reads the cron DEP okay cron top has executed now depending on the configuration most probably the applications scheduler class has already exit also executed and you can see we have shell access but this time we're not www data were route because the scheduler was configured to run in routes crontab so now we can say as a hacker or a pen tester now we're happy the machine has been completely compromised there's nothing you can do if you get a domain controller or just a regular machine admin level user you're screwed it's it's game over already so the game should never go this far but as an attacker we were successful so the but she got absolutely smashed now the important part how do we make sure that what we just witnessed doesn't happen to us and our servers and our applications and our users in production rule number one do not trust input of any format you cannot be selective in your security best practices you cannot think that all because we're using like I thought back in the day there is no risk in calling file PHP file size so why sanitize if you can't hack through this why bother only do it for the important parts no don't do that sanitize everything cookies reading from files everything because hackers find a way to tamper with a input and you're not prepared that's gonna cause some trouble and also sanitize so you can disarm code you can disarm remove certain marks from there to make the code not operate basically tip number two don't run outdated software in production and now the concrete reason why this matters like you saw with in the guzzle gadget chain example you can't exploit an object injection vulnerability if you don't have a working gadget now how do you make sure that there are no working gadgets within your application you keep your application updated if you don't update your app it's most probably going to be full of working gadget chains and that's only one vector and one problem there's there's if there's a myriad of other problems that this like come from not running patched versions of software out there the whole web is full of exploitation scripts that anyone can google the elasticsearch version this and this and just download the script and run it and if you haven't patched their systems they take it in without even knowing what they're doing they're gonna get in that's why security people talk about this all the time tip number three and especially for beginners well for for all of us follow for all of us this is super important do not run anything that you don't understand in production a lot of examples that I've found from Google I have a lot of different examples I always gather three or four different the per speech usually I have some examples with file uploads and bypassing file upload validations and stuff and I've researched quite a bit of different ways to upload files with PHP for example and 30 to 40 percent of guides and tutorials out there if you google Larry Bell uploading files or soon funny uploading files they focus only on the file uploading part and don't even mention the file type validation and now what happens if a beginner goes out and finds those tutorials copies the code you're screwed you're absolutely screwed and the only reason is that you didn't it worked you copied something alright it worked but you didn't know why and that's why you need to take time to actually understand what you're running copy pasting is fine if you can understand every line if there's a weird looking line and the weird-looking function and you're like I've never seen this function of I don't even know what it does but this works let's ship it that's probably that line is probably there for that specific reason because an attacker was thinking to themselves like what features could I use that the developers don't even know about and that's where the process starts from tip number four for the principle of least privilege so instead of starting from root you start from not having access to anything anything not having access to any place basically so you give processes and users people only the bare minimum access that they actually need and you never give administrative access to anything it's a very very dangerous thing to do like you just witnessed so do not go take the shortcut and just make everything run this route because then we don't have to worry about file permission problems and all of that nasty stuff and that applies not only to your application in production but also your staging environments your own workstations they are as vulnerable if you run a vulnerable application on your laptop your laptop is going to be vulnerable to that sort of attacks we just witnessed so it's not just that one production server is all of your systems you need to follow the same principles and tip number five I highly encourage developers to learn the basics of hacking and to learn to think about hacking because when I got introduced to the cyber security scene I was gobsmacked because I expected that all the hackers and security personnel would have development background and I went there I went to conferences I went to meetups and I was talking to people and know very few of them actually do and they were like what do you mean what developers like no we don't we only code because we only go to code the bare minimum because we have to code and I was like Oh mobile that that's weird okay then I also noticed that there were no developers around it those conferences and I've started to realize that there's actually a massive gap between the cybersecurity world and the community and the software development community and that's why I'm trying to tie this gap sitting here between one leg in the different group and the other like in different group and talk about these things because these should not be taboos we as developers should know the basics of hacking we don't need to be excellent hackers or certified pen testers or anything like that it's enough that we know the basics but we need to learn to think like a hacker we need to know what's out there that we're fighting against closing words before questions say yes yes so I will publish the slides and there will hopefully also be a recording available if the Payette tech doesn't fail us like happen in the beginning of the talk if there's only one or two things that you remember from this talk please let it be these last slides security is not a one-time project or sprint or effort that you just do and say that now I'm secure or now my company is secure or my application is secure security is a process and a mindset and it's an infinite process and you have to pay attention to it every time you run code you write code or your maintain code and even if you don't touch the code it gets outdated so whenever there is code and you as a professional developer are involved you need to take security in account security is never done and it's not a matter of do you have enough of it it's it's a matter of what is the level of risk that you can handle the risk is never zero but you need to control that by working on this consistently every single day remember with great power comes great responsibility you've learned some tricks like I said in the beginning of my presentation the purpose of these tricks is to teach you how to write more secure code and how to keep your users and your customers and your clients safe do not use this information improperly use it well thank you do we have time for questions yeah do you have questions you have one okay you're gonna get the box from there okay want to yeah it works have you checked if for example this vise with the injection will pass the virus scanners of some kind or not have a check yeah what type of file scanners are you talking about let's say this example JPEG with the far injection mm yeah so virus scanners will pass them or will will be screaming that it depends completely on the scanner there are some scanners like mail attachment scanners for example that do pick these things up but you don't regularly use them in your applications after I've shown these examples the first time I think it was maybe in Madrid or Amsterdam earlier this year people got a bit scared and they a couple of guys went out and actually built like libraries to do verification and validation for for these sort of things so there are tools to check for malicious PHP archives within images but it's absolutely 50/50 depends completely okay yeah I climb a way maybe I'm maybe if I'm not mistaken at least some versions of the two spot postings because it seems it is pretty robust yes okay yeah thanks any other questions I have a question is this possible to remove this payload from the image for example by the ginni laya library or otherwise does manipulation with GD library removes this payload I don't see why not technically yeah and and if you can detect it if you can find it with strings that easily of course you don't know what to grep for if you don't know what's in the gadget chain but I do believe that yeah you should be able to do that it's not going to be very easy but it's going to be doable definitely and that would actually be the best of both worlds so you disarm the image but the image still stays operational so that that would be a really good approach I said that removing that payload from the file will be too problematic is better to sanitize everything and well yeah the best thing is not to like when you find that there's something wrong with it from security perspective of course the best thing is just to keep your hands away from it like throw it away like don't touch it tell your users that whatever you're trying to do is not okay come back with a proper payload but for usability reasons that's not always possible so it's a balancing act always you can't go full security because security if you go full on security security becomes the enemy of usability and developer experience and life in general so it's a bit a balancing act really always any more questions in the very back row we have a gentleman there and the Box went the other way okay hi this fired jpg file does it Nick doesn't need execution permission for it to to work if I uploaded this JPEG and it doesn't have the the execution would still work as this is fire protocol I'm not 100% sure but I would say yes because you're not technically executing that file you're reading from that file and the execution happens within your PHP process so therefore to my knowledge you wouldn't it doesn't really matter that's the image have execution permissions or not so okay yeah there's a question at the back okay so just to comment on the trying to catch those veins to the list of the functions was pretty long yeah so basically any trying to catch those things in this file will actually execute that composer and farag so yeah so that's why what you need to do is that whatever you pass in into any function not just file system functions you should just sanitize it so if you use levels let's say or most of you maybe heard about fly system storage driver for examples if you use fly systems storage driver abstraction that for example by default strips out the slashes from your parts which basically disarms all the stream wrappers and that in itself is enough for you it will never allow you to pass anything malicious in these context militias in the doors functions but I'm sure that this is not the only weird and complicated attack vector for PHP out there this is just something that has been recently surfacing again there are most certainly vectors similar to this that publicly we don't know about that only hackers underground know about so that's why you have to sanitize everything not just file system Co arguments any other questions No all right I think it's coffee time then thank you [Applause] [Applause]

Channel: Conferia

Views: 3,958

Keywords: Rössi, Anamus, php, PHPCon, Poland, Szczyrk, Orle Gniazdo, security, attacks, prevention, hacking, cracking, defense, xss, csrf, sql injection, rce, man-in-the-middle, lfi, Laravel, Linux

Id: 4ZH52QFdOAI

Length: 50min 38sec (3038 seconds)

Published: Sat Dec 28 2019