Advanced Paranoia For Developers

um yeah thank thank you for coming everybody um thank you for thinking that this might be more worthwhile than is which is probably true and hello to the familiar Bas um yeah uh just you know um you know my name is Mark I'm a development team lead at gear set which is a company actually based in Cambridge but with an office in Belfast um I'm Mark XA on just about everything social medias andom and all that stuff so if you want to get get hold me at any point where you find me um now I I I don't normally put in an about me slide I normally just get into the content but since I'm not usually in

the cyber security Arena thought put put this in just so you know who I am why hell I'm talking at this thing um so yeah as I said I'm I'm a development team lead now the team I lead in my company is specifically one that works on Enterprise stuff and in particular on the security side of things so on the our back and authentication no that's all we've been working on um another of the things that I do in my role is I'm actually the primary interface between our company and the pentest as we use um so that's what the security side of things I do at the moment uh now I've actually been coding

coding 1970 something was over that but I first was paid to write code in 1987 um I'd originally started as most people in those days did by looking at games and hacking away at games and getting infinite lives you I started on the main frame my dad showed me how to edit the basic code and took it from there um when I started my first job one of the early things I did was to hack the restaurant put and ch ch change the board that they had to to show all the delightful things they had on on that day um as a minor result of that after I got over the the initial sanctions um I

started hacking into Doss um ended up working on bioses and operating systems um probably my Peak for that was when I was sent into a customer to work out why their networking wasn't working ended up going in reverse engineering everything finding a bug in the Windows networking stack patching that sending off the information to Microsoft and actually getting essentially my code into a service pack of Windows and then after that I decided I PE went on just normal web develop rubbish um on the you know on the community side I also turn up at info SEC and I every s often which is that everybody here should do it's great get beer and sorts of things um that's where

this talk came from basically we sitting there and we thought it the title advanc paranoid developers so that's to an abstract talk um I run a couple of meetups of my own on the development and Cloud side and if anybody's been to an IDC that was me and Bill we's idea back in the day still that as well anyway so the talk today um highly structured um I'll be doing a bit of General ranting about things things in general um and then I'll just go through a few things largely inspired by things I myself seen in actual Stu I worked on um where things have been insecure um and then finish at the end probably a bit more

then keep time um right so first first bit um if you're a developer you know you're obviously you know of a very happy gruntled developer you're just typing away doing your code everything's good sometimes you might want to do things the easy way um one day another developer might come along who's a little more dis than you or somebody who's not quite as bad avoiding fishing tax as you are or just somebody who's been in some way compromised um so really when when you're developing video the first thing you need to do when you're a developer is to imagine that all the code you're working on is actually open source that everybody can read it everybody can work with it um

it's so tempting when you're in a Clos source code base just to take shortcuts um it it never goes well some some of them will lie there and be be missed forever but eventually the shortcuts will will be bad um in particular you know if you one day become a dis developer you know you know that those things are in there you could do something so try not to take those shortcuts um which leads me on to this this first point I've called it goids your friend um there are I see far too many cases where it's been assumed that because you can't guess a guid that all you need to do is have a guid in a gr

string or something and that Endo is there secure nobody um now everybody knows security by obscurity very very bad thing um for the reason explained um also because you may think that's a secret but are you absolutely sure that none of the other teams is exposing that that ID somewhere or that particular token that you're using um are you sure that nobody's going to expose it in the future um [Music] so essentially you know what what can happen there is you know you you can put this thing in um happened in the real world you know big attacks been done just because end points been left open where you they they don't actually put authentication on it the only

authentication we got there is the who don't know the ID um what information being being right that um and of course once you've got those IDs you know potentially all sorts of places you caner those you know if your API has a Swagger people can read through they can see where where these IDs go in um and you potentially be reading or writing to things that you absolutely shouldn't be allowed to um so yeah this is yes I'm not going to go into details exposing too much um but this is the sort of thing that can happen if you just rely on obscurity um what was happening here um there was an ID that was used to tag

an endpoint on a back end so the application yes was was able to talk to a g server at the back end and get the information for it um what the attacker in this case managed to do is to find an endpoint which you could use to list things and within that list of things was the ID of the G server that was being used um second mistake they made here was that things were just OB the skated encrypted tokens um but the attacker was able to recognize that as Bas 64 was involved line um but the attacker was able to then reverse engineer the structure of that token stick into that token an ID

that they've extracted reconstruct that token send it off to you know happy smiling administrator who was completely innocent this uh but managed to do some sort of fishing attack to get him to click on an endpoint administrator was authenticated to use that token and because of the re-engineered token they were able to actually get off to send that off and divert it to a hackers the hackers machine which of course had the authentication header for that git server and then was able to take the authentication token and actually access the git repo at the far end consequences you can probably imagine AR that great um so yeah just just an example there you what you can

what can happen if you just rely on obscurity and not proper

authentication oh by the way and feel free to wave and Shout we got back your time have any questions right uh so yeah security security um the next one is in the ual code how you deal with your security rules um it's very easy particularly as you're building a product out to end up with something like this so you know you you this this is an API with work website on the end um your a your your web a sorry your website is going to hit the API there's going to be a whole load of different controllers in there for different end points behind all those controllers are going to be a load of services so you

the Bas orits code to do your your business logic within your application and behind that there's probably some stores as well so things foring different types of objects um you know this can obviously turn up into pretty much spaghetti cone and what's what's very easy to happen is you when you're doing your security checks through here you you very likely go in at you know say the controller level and just say okay is this person an administrator or is this person in this role and bounc there and then further down you know you'll have another check which is saying okay does this person have the read access to this thing or the write access to this thing

and then further down you know in the store there'll be another check to say okay this is you this this level you know which tables do they have access to um if you've got that sprinkled all over the place it gets really really difficult to maintain and to follow and in particular it gets really difficult to keep your your paths consistent so you're never quite sure whether when you went in through that controller did you go through the right service method that had the other check in it and is that then pulling through to the right stall method which has the other check in it and you know you get all these hierarchical Security checks um

so what we really going to be aiming for is to have some sort of Central Security Service um basically still spaghetti but tiar and tasty spaghetti um so really what you should have is a single service which takes in an identity and an object and its ID and what you want to do to it and says you can this user do this thing to that thing um if you've got all that in a single service not only are you not going to have all that sort of hierarchical some of all the checks things going on but it becomes a lot easier when you're actually checking through to see what your security rules are and what you're implementing to

check that that matches what reality should be whatever what the documentation say it should be you becomes a lot easier to read the whole thing um now in terms of you know people yeah

yeah um it's not exactly a broker but it's it's something that you you you know it knows all the rules um and generally speaking as soon as you know you know Pro probably at controller level because you know you know your controller has been given a request to get or post or put or delete or whatever by somebody who's you know been authenticated at that level you and what you want to do to it you that you know as high as you can put in that check just says somebody you this person wants to do this to this thing and you just it's got this on line check which is say which is saying person do this then B

having to go through selection of can this person do things can they do this specific object further

down is that what sir um it it's an availability problem if you're thinking of this as a distributed service so yes if you if you actually having that as a you a separate service that you call up to and ask those questions all then yes but you know generally speaking in a web API it will be just part of the core web API you just run in

in um so yeah I mean the thing about this you know and in terms of actual attacks you know you don't actually need an attacker in this situation um you you just end up with code that's inconsistent um what happens is that you know somebody's somebody just one of your users will find out that if they try and do something one way they can't do it and they find they try and do it another way they can um yes there are certain situations where this has actually happened um you know Cambridge analytica when they got all the information out of Facebook they were essentially going in through a rough roughly through a back door and stucking

out all the information they could because it been left public on that end point even though if you went through the main web interface you wouldn't have been allowed to see that um and of course you the nice thing about this sort of thing is you get lots of reports when people can't do what they to do if they can do something they weren't supposed probably w't um right next one uh dependencies um you may may recognize that may to read it it's great monitor there but uh basically the that is pointing out that is a diagram of as it says all modern digital infrastructure and a little bit on in the bottom right is a project some

random person in Nebraska has been thanklessly maintaining since 2003 um and anybody who's built the system will be fully aware of this you you particularly if you're using JavaScript you you've got so many dependencies and all your npn modules all in there all all down below um I mean to be fair there's only so much you can protect yourself in this um really but if somebody compromises of low Dash trouble going on um but in terms of what you can do about this um I'm going to just got a slight split here between packages and libr packages I'm assuming are sort of open source source based things that you're going to pull in uh libraries are things that you know

usually a commercial entity has built and they're just shipping you a a module that you can plug into your application um so some best practices here um it's best to pin the version of your dependency your packages exactly so that you they're not shifting underneath you and you know what you're doing um use something like renovate or depender box to actually keep an eye on those for you so to monitor your source code monitor what packages you're using and monitor the latest versions of those to make sure that you know when there's a new version um you can then go go and read the release notes for the new version decide whether it's something that you you're happy to take or not and

bump it on um but as long as you're doing that then yes you should be keeping it a relatively recent version of all your packages and you know the whole point depend B is to make sure that you you keep up to date and then older versions which get compromised you don't have um last one is you know don't completely forget about packages you know dep what depend won't tell you is well actually nobody's looking looking after this anymore so yeah keep keep an eye on on all these you know the top level ones and just make sure they you know they get they are getting regular updates and make sure that you're not sitting on

something which is no longer being maintained and might vulnerabilities that people have found since um in the case of libraries then yeah um nobody wants to but do pay for pay for the package which allows you to get updates for those depend for those libraries make sure you get the latest one um again read the release notes um it's also worth in those cases hanging on to the old versions if you got an open source library then old versions are available um but if they introduce the security vulnerability and youve chucked away the old ch the old one can be a lot harder to sort yourself out um quick example again of something I've seen in this Cas now this this was a a

library rather than open source package um but they yes in this particular case there was an application um and it was able to spit out PDFs for you as to give you a summary or account status or whatever it was um so what happens is you know the attacker goes in generates the PDF looks at the PDF and in the PDF was embedded the actual in the headers andu was embedded the actual name the library that had been used to generate it so they went off looked to see what the vulnerabilities would be in that s the vulnerabilities were and then was able to craft a particular input so you know they they build in text box or whatever

in their account status or whatever it was being being generated on and were're able to get that user input into that PDF component and yes compromise the PDF components um particular case I'm thinking of here they didn't manage to actually do anything too bad because they didn't get it quite right but what they were able to do was to crash the the whole system at at will some sort of overflow thing going on they were able toble to break that whenever they wanted Ju Just by you know using this one particular bad components now and this is why I you know was mentioning about making sure that it's still maintained this this particular PDF component was actually

one that nobody was maintaining anymore so you know it been it had been put in way back when it had been working fine but over time the vulnerability had been discovered and there was no patch to it so they had to take that out and completely recode with a brand new PDF component to stop this thing to stop people from being able to crash crash their SES

um next one uh patterns now this I'm talking about patterns here is when when you're trying to sanitize something um so you've got some user input you're trying to sanitize that so you want to check that it's something valid for you know there's a a regular expression um to sort of say like the only things we're going to allow allow in this are sites in my domain so in my.com I don't suppose any body can see a problem with that regular expression it's not terminated yes so basically there's no you know as long as that's found anywhere in the anywhere in the string you pass in that would be fine so what you can actually do is

patch that that will that will match anything on the end as well um similar similar things happen if you just got wild cards particularly when you've got user inputs the things um so you know it's just very very difficult if you're relying on patterns to actually get match what you want so where at all possible use lists um and ideally don't do this at all actually have some sort of proper authentication mechanism that allows you to restrict what the back end is

um so you know this this is a case um Cas and point um in this particular application um there was I think a a backup system which would allow you to take your Source your company information whatever that was and send it off to a backup service um but what it did to yes but what it did was to say okay we're not going to let it off to just any backup service we want to sh that down so we're only going to have it to my yes ones we set up with my company name in in the URL um now that was done with a with a wild card so was you know so they said

you know my company heyen star. storage.com um but what of course that meant is that even though you know of that wasn't a public restriction you know the attacker in this case knew enough about the company to know that that was the format of their URLs and they were able to go off to that stor of service set up their own you know set up their own instance of it with a name that match that URL and then go into the application and say okay back up my customer data to this location and they essentially were able to walk up with all all all the information you know from that I think that's inside probably an inside

job but they were able to extract all the information stick it out to their own storage service um so yeah it's amazing how many times I've seen patterns using that sort of situation for emails and domains like that even though it seems obvious try not to [Music] do um okay the last is just this is just back to me me ranting again this this is something that I see far too often as a developer and particularly in small companies but even large companies sometimes production issue happens you want to find out what the production issue is so the developer goes and connects to the production database and production server and goes in there and does

things no don't go back to your company and say if you're a developer go back to your company and say hi I need to get to the production database because I need to go and look at you know this table find out why we're getting slow Behavior or why this particular object is is causing errors you should not be allowed to do that um for no other reason but you know I I have been that person who has been on a production database and run a tidy up tidy up script and forgotten to highlight the where Claws and tidied up the entire T and that that feeling when your stomach drops out no F at all and you the looks you

get while they're trying to find latest back upore think my worst one production was actually why an entire hard dis on machine slight yes you know you should you should never let anybody need it's just in particular some companies think that developers are these magical people who will always behave always know exactly what they're doing and are just the right people to go and look at that production thing so yeah it's it's not a good idea um if you need if if you're in a situation where you're having to do that start working on your log start working on ways that you can get enough information out of the system without exposing real data to get

what you need even if it's a case of actually instrumenting the application retrospectively and deploying a new version to find out what's going on don't ever ever ever let devop system I mean if you've got if you got a good cloud system then you know you shouldn't ever ever ever be letting any human near production system the only person thing should be allowed to touch that should be your de pipeline St things St new versions of stuff and it's something or backs up your data to somewhere else can get but yeah don't don't let hum at the production and

[Music] um that reasonably quickly time there but uh yeah so so don't don't ever rely on the fact that your code is safe assume that everybody knows just as much about that code Bas as you do make sure that when you're coding you're thinking about how would I break this thing that I am building always always be thinking that um that's where the paranoia comes in just look look to your look to your right look your camera if you're working look look at those people around you and think if they wanted to break into the system what would they do and think with that mindset in particular don't rely on obscurity always have properly authenticated end

points always always have properly authenticated endpoints and always make sure that if somebody had access to your entire list of database IDs and token encryption mechanisms stuff they still wouldn't be able to put something together that they could use without these breaking your authentication whatever system um do make sure that you've got a centralized system for your security rules so that basically for your own sanity so that you don't have to stop holding in your head all the possible ways that things can happen and all the ways all the places the checks are just gets very very complicated very very quickly um keep an eye on your dependencies um try to keep them up to

date try not to let them just die at the end don't don't end up with unmaintained stuff in your system um and do use some as far as possible some sort of automated system depend it's the obvious one but renovating things as well something that keeps an eye on it lets you know and sends you a PR and says update this update this this this um don't use patterns if you told possible and if you are using be very very very very careful about it use user list um don't let anyone ever ever anywhere near production so that's it from me I will take questions also the reason that I'm quite so out depressed and falling over

at the moment as I did the half marathon half marathon the weekend so if anybody's feeling General wants to help particularly good charity then feel free to scan thatr code and me any questions [Music] yes not letting humans into production in a well-run cloud um yeah it's like I say in an ideal situation the only ways you should be able to get into production are via you know a human Ops person who has break class access to that so in your Cloud you know you'll probably have something where you can Elevate privileges temporarily and you need two people potentially to actually authorize that the only other thing that should be allowed in there is like I say

your devop process so whatever it is that's pushing code out there it should be allowed in as well um anything else you know should be done through principles so principles um so really just saying you if there's a system that needs access to it it should have its own access which is in directory and is it own thing and it uses that to authenticate for other things so yeah just basically no no no humans apart from that great class action everything else should be automated any more questions okay that okay