 Dzień dobry. Mam nadzieję, że jesteśmy wszystkich i przyjeżdżającym w Europiton. Zacznijmy trochę o cybersekuritowaniu. Przede wszystkim, mam 3 dysklamy. Pierwszym, to wszystko mojej opinii. Nasza następna prezentacja to mojej opinii. Nie jestem zbudowany przez żadne z tych kompanii lub ten projekt open-source, żeby oznaczać ich. Trzeba, musiałem wyciągać jakieś części do devops od mojego mówienia, ale są jeszcze w prezentacji blue-color. Możesz mnie zapytać po prezentacjom. Zacznę z nimi. Później mówię trochę o tym, co jest cybersekuritowaniu i dlaczego powinniśmy się skończyć na to. Teraz zacznijmy odpoczywać modelę na aplikację. I zacznę odpoczywać trochę więcej opcji o co zaczęło zacząć z cybersekuritowaniu. Mam jedną prośbę. Proszę zapytać po prezentacjom. I zacznę zapytać po prezentacjom czy po e-mailu po prezentacjom. Nazywam się Piotr Deba. Możesz też zapytać na mnie Piotr. Jestem z Polska, która jest 2,5 godziny z Berlinu. Trochę większa mała, a około 15 godziny z Ruminy. Pracuję na F-Secure Poland, gdzie jestem teamleader i software engineer w projektu rapid-detectioner. Jestem też małym mentorem na Pileides, gdzie teraz mamy do 220 studentów. To jest nasz aktywny. Jesteśmy od 3 lat, a teraz zaczynamy 4-3 roku. I prawdopodobnie will talk a little bit about it more on the flash talks. So, let's start from the scratch. What is cybersekuritowaniu? Cybersekuritowaniu means and protocols for your resources and devices from an attacker. Damage or theft. So, cybersekuritowaniu doesn't start at application level. It starts at hardware. So the policies and protocols for your employees, how to handle equipment, how to handle servers, what are the server's policy access and what can an employee bring to the company. So, it often happens that employees are banned to bring their own pendrives. So, there won't be, for example, a source code leak. And then we can go to hardening our software architecture, software services, which we'll focus on in this talk. Okay, cybersekuritowaniu is becoming more and more important. As you are seeing, the number of leaks and attacks is growing exponentially. The biggest leak happened this year and it was over 1.3 billion user accounts data. It's more than most of the years beforehand. And it's still increasing. Who remembers this screen from just two weeks ago? Yeah, not Petia laid waste on many companies across the globe just in one day. And some companies are still recovering from it. There are two very known, publicly known cases, like TNT, so the courier company and Rayben, the corporate courier company. Rayben is a really nice example of well-executed recovery during which in less than 24 hours company changed their server architecture from Windows to Linux in less than 24 hours. Sounds great, right? But we assumed they were prepared for something like to happen. And this graph shows a number of attacks per day from our public honeypot network which I'm developing with my team. It's two to 16 millions attacks per day. So who knows what a honeypot is? Raise your hand please. Okay, quite a few. For the rest, I will explain. A honeypot is a server that is a trap. Interesting trap for attacker because it should be easy to access where we can monitor and lock the actions of the attacker. But it won't affect our server architecture. It's a disposable server, a trap where we emulate services like SSH, SMTP, HTTP, etc. And in our team we are doing everything in Python purely. And the data we are also gathering. So the username and passwords. I'm amazed how it's mostly both data probably. We assume nobody is trying to lock in SSH to using root-root password. But because the intensity of the scanning with those credentials we assume that some people don't change that. So they are still scanning using the default data for some services. Like Raspberry Pi is quite high, I think it's fifth place. So currently we established that cybersecurity is important. Paraphrasing this nice comics, it's important that we start incorporating the cybersecurity at the beginning of the project, not after we get hacked. One of the basic things that we should start doing when we approach cybersecurity, it's threat modeling. It's an approach for analyzing a security of application or a system. It should be structured and identify, quantify and address the security risks associated with the target of the modeling. Now let's imagine we are a Batman. Everybody knows a Batman. Who doesn't know who is a Batman? One person. I think he's trolling. Anyway. We have four main assets. We have our base of operations. We have our batcave. We have Alfred, our battler who handles everything for us. And we have informations in form of emails and text. Now we have threats. We have three main threats, which is police, our arch enemy joker and the press. Let's quantify the threats. So Alfred is irreplaceable. He's a human being. I do all of our systems and assets. So he will be our highest priority when defending and the highest risk at the same time. Then we have our batcave. But we can rebuild it. It's just equipment. And lastly we have informations or emails and text messages that can show where are we going or what are we doing. But honestly we can mitigate the press or the police because we can handle them. Lastly, let's try mitigating those issues. So we can obscure Alfred's location and his identity. But in current world it's really hard to do. Then the batcave is much simpler task because there are security systems, traps, misleading base of operations. We have a ton of possibilities to handle the problems concerning our batcave. I for the emails and messages we can start encrypting them which is the basic approach and obviously we should be cautious when typing something that may be delicate for us. Now we will start working on our application that we will try to make secure. So as in our batman example we will start identifying our assets purpose of their users. The next step will be identifying our interactions with the third party software and other parts of our service. And then this is one of the most important things the ACL, so access control list. So who can do exactly what. And just by specifying this and using those ACLs during the whole application development you can defend yourself against many other things. One tip, if you are already started developing your application and you have proper development methods you may reuse your data flow diagrams or application emails as a base of the composition of the application phase. Behaviour test and integration test are also useful for just that. There are a few frameworks for application software frame, IASF that should give us a reliable output that should include logging and auditing and just to be on one page auditing is who did what and possibly why and logging is what's happening and those are two different things that we should distinguish and probably have the data in different services afterwards. Then we have authentication and authorization and again to be on the same page because it's often misleading authentication is asserting if the person who claims to be it's the person who it is and authorization is a process of determining who is allowed to do what. Configuration sorry where do we store the configuration and who has access to it then data storing and data storage and data transit so if we are storing the data securely encrypted and if the data and the transit is also encrypted so if we use TLS for example and last managing and handling exceptions and what we should do when an exception occurs the protocols now we need to measure the severity of the threats we may encounter we can approach that by ourselves using using our own mind and figuring what is the most important but we can also use CVSS the common vulnerability scoring system this is based on few factors like attack vector attack complexity and privileges user interaction scope confidentiality, integrity and availability all together can give us a reference point but it's for example hard to measure how much how the attack will be complex we usually don't know that so it's wise to put both values and take an average or leave it as arranged for comparisons and we need to remember that this tool is just a tool to help not an oracle what we should do and as mentioned before use cases, UMLs and abuse cases especially abuse cases UMLs will greatly help us deducating what we should do whether we should start and what are our priorities next we need to address the issue at hand so we have four ways to do that one is to completely remove that's the nice way but not of always possible because of the task at hand we may not be able to remove it at all but we may need to mitigate it because for example it's too expensive to remove it for many different issues then the third option is we can take the risk and address it later for example because if there is an issue for example an outside person an anonymous user can traverse over a file directory with some random names of our user's cuts of pictures of our user's cuts so we don't really care if he get the pictures probably our users don't care also and you need to type some random gibberish just to get the pictures to work on the attacker's side then on ours to achieve anything and fourth option is pretend there is no issue i don't recommend that so for example if an outside person can download our configs or password databases and we don't do anything about it we are just asking to be hacked so let's start making a thread do our simple imaginary application in PHP so as everyone knows PHP is very secure and hack proof language probably as secure as internet explorer was a few years back it was not maybe the best browser for seeing the internet but it was definitely the best browser for internet to see you so of course we will not be using PHP because PHP should stand only for Python has power so let's build an application using AngularJS for frontend signing for backend and PostgreSQL and Linux for other things we will be having a home endpoint for serving the HTML and javascript we will also have longing endpoint dedicated just to that and some list and one instance views for other blogs and users so how can we hack our app considering now frontend there are many possibilities that we should think of every developer that use javascript may find some weaknesses but probably someone did that for us already and of course there is a huge project called application security project OWASP in short and it's good to remember this name because it will be many times in this presentation and it's collaboratively developed by thousands of users it consists not only examples of attack measures the severity but also includes business level communication so also a non-technical person like a project manager to tell the upwards that we need to really do that something about it OWASP is much bigger knowledge than only the threats it also consists information regarding tools books, events and other interesting sites and projects and one thing is very important about OWASP it publishes a list of most commonly used attack vectors in the past years the last one we are seeing here is from 2014 and the second the newest one should come up this year quite soon, they were army from July they have some changes and I will go briefly by all of the attack vectors and explain some of them that are less obvious so injection, who did something about SQL injection ok, most of you, not all so SQL injection is basically to inject your own SQL code into the SQL that is run by our API for example drop tables, users and then we have broken authentication and session management the issue here is that many applications don't store properly their users easy to hijack other user session cross-site scripting this one is really fun because it allows an attacker to run a script on other users' browsers so it will not affect us directly but it may make our other users download some malware or send their credentials to our web page to our attacker server insecure direct object reference who doesn't understand this one there are a few for hands not so many people understand that and we will just move on security misconfiguration is really obvious sensitive data exposure so if we are exposing something more than we want to making functional level access controllers, ACLs I will talk about it a little bit more later cross-site request forgery so who knows Django okay so I think everyone you should remember that when you were using Django template language and designing your forms you were inputting a CSRF token in the beginning of the form someone did not include that in their template raise your hand that's great, wonderful because this minimizes the chances of your form to being abused which is really good if you are not doing that you should start doing that is just one line of code in Django template language on Rujinja that will save you from a lot of trouble using components with no vulnerabilities that's obvious and unvalidated redirects you should validate your form that's just the use case and if you want to play with any of these vulnerabilities by yourself there are two projects the bbox project and the OWAS broken web application project that allows you to run an image of an application that has all of these vulnerabilities and there's even a scoring test and there you can choose even level how hard the vulnerabilities should be to notice and the application is obviously written in PHP so that's why it's really easy to hack Python is a little bit more prominent in this matter and I will talk about it soon now so for our AngularJS there may be an injection coming there but we should validate the injection on the backend so injection won't happen on our frontend directly broken authentication session management may happen it's the javascript so it's not the bug proof completely cross site scripting so XSS definitely may happen and it often happens on javascript part and it cannot happen on the backend part because it's not exposed and that matter and rest of them is more obvious to move forward to the summary AngularJS mitigates most of them by itself out of the box and even handles some of them completely so as long as our developers don't do anything really stupid we are fine when using the basic AngularJS but it's important when we are extending without external libraries that we will review their code and I will also mention that later so Sanyk Sanyk is a python web framework that is using async.io and uvloop so what can go wrong there and of course there can be some python code injection but not really unless you are using eval or exec or pickle with pickle is quite obvious case documentation it's explicitly said not to use pickle with user input the exec and eval also are not the best idea so for python the problem usually exists between char and the keyboard so the developer so it's on your hands to make your application secure on python level but many people wonder czy to use exec or eval I will get back sorry there is a beautiful explanation on why we should why the pickle is so fragile in terms of security and there was even a bug in twist.it in 2011 that you could exploit easily it's fixed but this is a really great example how pickle can be exploited if you are more interested in this part there is a link below I need to minimize my other window because it spoils presentation ok now moving to eval and exec and you can see two codes I'm not sure if my pointer is working they both do the same thing the first one is just simple code the second one is compiled and executed code as you can see it runs 30 or even 40 times faster when executing a compile code then the normally run code even 40 times faster on python 3.5 this is a huge difference in the code execution times that can be used but it can also be abused so we have issue here but also we have advantages for the exec and eval in our code but we just need to do it carefully and for the eval example as you can see implementing that takes a string and do some calculation even a simple equation already needs more than 10 lines of code it probably can be done simple but just to show eval will just take the equation and give you the result of the equation so it's much easier and it also can handle much more complicated equations so we have SQL injections SQL injection should not happen when you are developing your application in python unless you are implementing sql by yourself jungle rm and sql rhemi are quite secure we've tested them additionally and we didn't find any way of explanation by our consultancy team that would allow you to exploit anything in this rms but there is a third option python injection and sql injection and it's possible and it's doable and many people doesn't know that and many people do use pickle as an object storage and when you are using sql database and store a pickle then a user can input your python code there for example this one nice liner which will delete all things on your machine when it's run and just for doing that we can post an object and then refresh the page to read the post and it will be executed and it's possible to mitigate this problem you can approach that issue in two ways by not using pickle and using jason for storing the information that will be needed for a class builder later on if you would like to store a class and for storing dicts and list just them it's better to use jason purely we can also try mitigating that by writing our all anti python pickle injection validation but usually it's hard because this code you can make into base64 and then import base64 and eval the output of the base64 and coding the coding so it's hard below is a simple sql injection that will drop user table and most people use the user's table name even so if not they can also run other code execution that will tell them your database schema just by adding the apostrophe on the beginning so as you can see python has more vulnerabilities than then frontend written in javascript but most of them are already mitigated out of the books by python as I told you before most the main issue is with the developer so on your side it's important that you will care for the careful development and proper means and I will tell you now how you can do that the first thing is when choosing a library try to choose the more common one because it's already being used for more users and if you are not using a common library or python project you should go through the code yourself and see if the data is not being sent on each post for example 2kgb or nsa and then using outdated libraries may also lead to some issues there is a well example of ubuntu 14.04 which has urlip free already installed but this version has the bug in ssl configuration and that can be exploited so just updating will save you from being hacked those are the summaries for the devops it's quite funny because nginx and apache has much less attack vectors but they are still being hacked quite often so let's get back to our blog application so we have free users everyone can access our blog posts and read them registered user can add additional write to the blog admins can manage the users and delete the posts so when we are composing the application in the first table we can see what the user can do from what I said before and now we need to project that on the database interaction so logging only read logout it doesn't need to access the database and so on and for the rest of actions so our api level actions we have getPostDelete someone may need to use put but I will focus only on this free distance for now for the home directory get is sufficient for all users logging only posts and we can extend that only post from anonymous user so a logged user shouldn't be able to log again to your application and for logout it should be also only available for logged users or admins for the rest it will depend how your structure of your project works looks like and what are your company policies for API ok, so we finish the composition phase of the application we have everything we need we can now go to determining and ranking the threats so what is the most valued part of our business it will depend on our business approach it may be our information so the blog post the users or confidentiality so user emails and their passwords depending on our business model it may vary and how can they be targeted someone gets admin access so he can do anything in our application export the data delete the whole application etc someone gets user level access he can spam other users and possibly may access to their emails which can be also another spam attack vector next one are for devops so those attacks server onage so on the infrastructure level next our application source code can also be a target attack when someone gets access to our version control system then place some malicious code there and if we don't have a proper review it will pass quite easily even if we have a proper review he can still just click by himself because he's owner of the version control system even if he gains only read access it will be much easier for him to find a vulnerability in our source code than without knowing the source code ok and as mentioned in the beginning depending on our business level business approach we may have different different priorities and defending for example our users' credit card numbers login password may be much more important than defending our post database because usually we can recover when someone deletes the mined database we usually have a backup but if we lose our username passwords or more credit cards we will not have any user anymore we will all go away so risk mitigation one of the basic things we can do is adding multi-factor authentication for the user admins level access we can try limiting the range of the IPs that can access the admin panel at all and it's a good approach if your application is a microservice so you can move all the admin panel to another microservice it's also a good policy for the spam we can limit post per days which may be not convenient for our users edit per hour, shorter sessions and adding CAPTCHA usually is also a nice idea I will skip the DevOps part because we are running out of time already and part of the mitigation should be done already on unit test level so when you are making unit test don't focus only on happy paths do the wrong paths also so all exception handling and rising exception should also be done on the unit test level it will mitigate some of the security issues and there's one nice project I will mention maybe more for DevOps SSH HTTP that hides our SSH access in plain sight so on the same port we have HTTP and SSH access okay now tooling for automation we have a library called Bandit it analyzed our code using abstract syntax tree can be easily integrated with Jenkins and it will find the most common vulnerabilities in our application like exec and eval should be highlighted it works similarly to PEP 8 tool or pylint it will get nice report after running the application then we have SonarCube this is much bigger project there are 20 languages like JavaScript, HTML and more it has dedicated Jenkins plugin with security gates that will allow you to not pass the code if you have found a vulnerability in our code test I really recommend looking at SonarCube because it's all in one tool it's free, you can host it yourself or you can buy it as a service next we have zapp and burp zapp is created by OWAS project it's free it has Jenkins already plugins and it's dedicated to all web application just first run of the most common issues will probably make allow you to find some security bugs burp is more commercial alternative and it doesn't have Jenkins plugin already it should be coming up soon both of them are web scanners so they will map your site and try execute common attack methods and patterns then we have Metasploit which is more infrastructure based and system based attack framework and SQL map it's for all SQL interactions and our project that could be attacked and lastly we have SCAPI this is Python library that allows us to prepare any kind of TCP or ICMP packages and also UDP datagrams with any payload lastly there is commercial solutions and managed service like Kualizys for the most popular and fsecurator the advantage of managed services that you will receive a report that should not contain any false positives from the scanners because scanners usually bring you some false positives still and ok i will need to go fastly why do we need append testing append test in short it's an auto-resid attack on application or in our infrastructure we should do append testing for removing all the security weaknesses and also for compliance like PCI compliance what's the target of append test so usually when append tester is attacking our application he has two goals one to elevate his access to an admin level best case scenario it should be done by a third party and we should use also the automated tools i mentioned before we should do also it when we end a development cycle or when we have a new big feature that may be vulnerable to attack that other parts of application are not but who is append tester append tester in short obviously is a person who performs a append test it's not a method of append testing it's just a person you can also call them security consultants hackers white hats just remember not to call them crackers or black hats which means basically criminal because they will become sad and you don't want to have a sad hacker on your team really you don't want to have that and red team drill that's more extensive than normal append testing because it starts on security level usually red team drill have budget for physical damages like destroyed locks, broken windows also it covers planting bugs one important thing is that is when red team drill goes undetected there are really big issues because an attacker when he achieves his goals for example bounce a bug and record your conversation with your boss starts being noisy to a level when someone should have noticed it ok there are three major approaches when append testing the white box so our consultant has access to everything including our production servers, configurations source code etc then we have grey box texting we limit his access to our infrastructure he has access basic access to application and possibly a moderator access if it's obtainable by a user and he has still access to our documentation and our source code the attack becomes then targeted because he can find witnesses in our source code and try to exploit them and then there is black box so attacker does not know anything about our application except what is available on the internet public internet he doesn't have access to the source code but he may obtain it during the attack also same goes for the documentation then last thing which is becoming more and more popular CISO which is security information of cyber security sorry chief information security officer that's responsible for many things like in the response teams information risk management information regulatory compliance for example PCI, data protection act or GODO in Poland and also for IT security and security awareness in the company and the last one is currently very important because of the phishing attacks that may happen even on our non-technical stuff and if we are getting hacked there are four circles of being boned one being hacked by a bot or a scriptkid and being attacked by very known vulnerability both of them are very shameful for your company you will be mentioned on the internet in very nice ways and for the security people they probably should rethink their career choices it's that bad really and then being hacked by a quite new vulnerability it may happen we didn't patch our system so we need to improve our protocols and lastly we are attacked by unknown vulnerability or so called zero day which is also approved that our security till this point were that good the attacker needed to use something new two important things not seeing a distorted result of attack doesn't mean we are not hacked or not being owned for a longer period of time because the target of attack may be just to acquire some information and the last year gardener report said that it takes 200 days on average for a company to notice an attack imagine what can happen in 200 days with your infrastructure being owned by an malicious user so internet is changing and a few years ago it was commonly advised for example to move SSH to a higher port now we have mask on so we don't have to there's no point of moving it and actually it may mess your firewalls if you move a protocol to a different number than it should be as mentioned now we are ordering strangers to bring us home this is a curated list of interesting links that may help you go into cyber security some of them were mentioned if something was not mentioned it's on awesome security of github or on the OWAS project site last thing just from yesterday there's a great talk about passwords and why we should not use them on Europeiton I hope I will see it again on YouTube soon it was done by Justin Meyer yesterday in the morning I hope you enjoyed my talk and learned something I don't know how to summon the Dark Lord yet but I will gladly answer your questions we have time for one question so if you ask a pentester to pentest your system you said there are three ways which one because in the white box you just give everything and the black box you don't give anything what would you suggest if you have a system and you want a pentest which of these approaches would you take honestly it vastly depends on your budget and your ability to sustain your servers during a pentest when black boxing because black box testing is quite demanding because it's done on the production system so unless you can scale up to handle the black box testing maybe grey box will be more and if not white box testing also all of the tests should bring you different results so when you are having for example periodically pentesting it's wise to change the methods so we will get a different outcome