Google Ads
This is a transcript for a video linked here: Cybersecurity STRIDE analysis of a Raspberry Pi IoT project.
00:00:00.480 --> 00:00:06.080 in my earlier video i explained the concept of threat analysis and the stride threat 00:00:06.080 --> 00:00:11.440 classification system in that video i looked at the theory but in this video i'm going 00:00:11.440 --> 00:00:16.960 to take a look at how it can be used in a real example using an internet of things iot project 00:00:18.080 --> 00:00:21.680 this is going to be simplified but could help show 00:00:21.680 --> 00:00:26.960 you how to turn the theory into practice if you haven't yet seen my earlier video then you may 00:00:26.960 --> 00:00:31.760 want to click the link at the top of this video or in the description before watching this video 00:00:33.600 --> 00:00:38.240 if you enjoy this video or it provides something useful then please click the like button at any 00:00:38.240 --> 00:00:44.560 point in this video that will help share this with others as a quick recap stride is a monomic that 00:00:44.560 --> 00:00:51.840 describes possible attack vectors against the system s is spoofing t is tampering r 00:00:51.840 --> 00:00:59.680 is repudiation i information disclosure d denial of service and e is elevation of privilege 00:01:02.000 --> 00:01:06.240 you can do the threat modeling yourself or you can use the microsoft threat modeling tool 00:01:06.880 --> 00:01:12.160 there are pros and cons to each approach one of the advantages of using a threat modeling tool 00:01:12.160 --> 00:01:18.640 is that it may identify threats you wouldn't otherwise think about one of the disadvantages 00:01:18.640 --> 00:01:23.920 is that it's not fully aware of your system so may miss some of the important threats the 00:01:23.920 --> 00:01:29.280 threat modeling tool is also only available for windows and its analysis is not so useful for 00:01:29.280 --> 00:01:35.520 applications on non-microsoft platforms in this case it's for a linux running on the raspberry pi 00:01:37.200 --> 00:01:41.760 for this project i did use the tool but i also did some manual analysis as well 00:01:43.040 --> 00:01:47.760 both of these two methods picked up some threats that would have been missed by the other 00:01:51.600 --> 00:01:55.520 the project i'm doing is for my raspberry pi pixel server project 00:01:56.800 --> 00:02:02.960 this is a open source project and it's available on github and w link 00:02:02.960 --> 00:02:09.840 to my project page in the description this started life as a non-iot project 00:02:11.440 --> 00:02:16.400 although it was designed with a web interface it was only initially designed for use on a secure 00:02:16.400 --> 00:02:21.840 network and so didn't include authentication or any of the other security features 00:02:23.840 --> 00:02:28.960 i wanted to be able to connect the project to the internet so i therefore identified this would need 00:02:28.960 --> 00:02:35.440 to include authentication and in particular the aaa security framework so i've performed 00:02:35.440 --> 00:02:41.760 a significant rewrite of the code to add the login authentication and various other aspects 00:02:43.280 --> 00:02:48.560 the threat analysis then becomes important to ensure that i'm not exposing this project or other 00:02:48.560 --> 00:02:55.440 systems to a necessary risk when it's connected to the internet before you start the threat analysis 00:02:56.080 --> 00:03:01.920 you should decide on the scope of the analysis is this just looking at a particular program or the 00:03:01.920 --> 00:03:07.680 overall system if you're restricting the scope then you may still need to consider the overlap 00:03:08.640 --> 00:03:14.560 in this case i'm concentrating on my own code but i do also consider the overall system 00:03:15.280 --> 00:03:19.600 and threats associated between how the code and the operating system are configured 00:03:23.520 --> 00:03:28.000 so to perform stride analysis you normally start with a data flow diagram such as the 00:03:28.000 --> 00:03:35.120 one shown here this identifies where data flows from one system or part of the system to another 00:03:36.000 --> 00:03:41.760 you can then look at each of the data flows and apply the six attack types and identify 00:03:41.760 --> 00:03:48.320 the threats and the risks this example i'm going to be performing analysis on the overall design 00:03:48.320 --> 00:03:53.600 and the application code itself there are more components and also be useful to look in terms 00:03:53.600 --> 00:03:59.840 of the operating system configuration as well but i won't be going into that in much detail here 00:04:00.640 --> 00:04:08.000 i'll be using two different data flow diagrams and i'll be covering a second one later this diagram 00:04:08.000 --> 00:04:14.480 shows the overall design the main part of the program is a web application written 00:04:14.480 --> 00:04:17.120 in python flask which is shown on the right here 00:04:19.360 --> 00:04:27.200 this uses http but with login information going to the application i decided early on that i wanted 00:04:27.200 --> 00:04:34.480 to use https encryption and whilst it is possible to use https on the web application itself 00:04:35.360 --> 00:04:41.120 i decided to use a web proxy instead i've explained why i made that decision 00:04:41.120 --> 00:04:45.440 on my other channel penguin tutor see the link above or in the description 00:04:48.560 --> 00:04:54.720 the central circle is labeled as a web server and this represents the reverse proxy running engine x 00:04:55.680 --> 00:05:02.960 although it's also acting as a web server as well the unencrypted traffic flows between the proxy 00:05:02.960 --> 00:05:08.800 and the web application the reverse proxy could be running on the same computer system 00:05:08.800 --> 00:05:14.240 in which case that traffic would not leave the system but if they are not on the same system 00:05:14.240 --> 00:05:19.840 then the network connection between the proxy and the web application does need to be secured 00:05:22.000 --> 00:05:28.000 on the left you can see the human user and the traffic there is encrypted using tls 00:05:29.280 --> 00:05:34.400 this red line represents the internet boundary and the traffic going to and 00:05:34.400 --> 00:05:39.680 from the user will traverse the internet and this is a significant point for analysis 00:05:43.760 --> 00:05:48.400 first i'm going to look at the http traffic between the proxy and the web application 00:05:49.520 --> 00:05:53.840 so i've already identified this is a potential security vulnerability as the data is not 00:05:53.840 --> 00:06:00.000 encrypted when using http so we already know this is going to identify some vulnerabilities 00:06:00.560 --> 00:06:03.920 my mitigation plan is to ensure that this is a protected network 00:06:04.880 --> 00:06:12.880 the network protection can be provided by securing the physical network eg using a ethernet switch 00:06:14.640 --> 00:06:21.680 wireless network security running a secure wi-fi network or avoided completely by installing 00:06:22.880 --> 00:06:30.960 the web application on the same computer as the proxy although even with these mitigations in 00:06:30.960 --> 00:06:36.800 place we may still need to look through some of the threats that are identified 00:06:40.400 --> 00:06:43.840 the first threat that the tool identified is replay attacks 00:06:45.440 --> 00:06:50.720 this is something i was already aware of it's protected when going over the internet through 00:06:50.720 --> 00:06:55.440 the use of https and it's basically down to the security of the local network for this 00:06:57.520 --> 00:07:02.320 the same for collision attacks 00:07:02.320 --> 00:07:06.240 cross-site scripting is something i've already identified as a possible risk 00:07:06.800 --> 00:07:12.160 this is where scripts could be inserted through unsanitized information i'll mention this in 00:07:12.160 --> 00:07:19.600 more details a bit later weak authentication again i'll cover this in more details later 00:07:20.480 --> 00:07:22.160 this is already something i was looking at 00:07:24.400 --> 00:07:30.000 and then it also lists elevation using impersonation link to authentication 00:07:30.000 --> 00:07:35.440 is something i had already considered both through the authentication but also considering 00:07:35.440 --> 00:07:44.320 network based authentication which is included as an option to mitigate against this then certain 00:07:44.320 --> 00:07:49.760 configuration criteria is needed both for the authentication on the application and on the proxy 00:07:53.040 --> 00:07:58.240 and then look at the main interaction with the user shown here at this internet boundary 00:07:59.680 --> 00:08:04.720 because the way this particular app works then it may be that some of the threats identified here 00:08:04.720 --> 00:08:07.440 should in fact apply to the web application instead 00:08:08.080 --> 00:08:14.640 rather than the web server which is just proxying the request onto the web application 00:08:18.560 --> 00:08:24.240 the traffic over here is over https which is encrypted there's still some threats identified 00:08:24.240 --> 00:08:31.520 especially look at the interaction with the user at this point look at data repudiation this means 00:08:31.520 --> 00:08:38.240 about being able to prove what happened this is achieved through login on both engine x which logs 00:08:38.240 --> 00:08:44.880 urls visited and the web application which logs the user interaction such as successful logins 00:08:49.440 --> 00:08:52.640 cross-site scripting doesn't really relate to this 00:08:52.640 --> 00:08:56.080 as it's a proxy i've already mentioned this for the web application now 00:08:58.960 --> 00:09:06.880 elevation using impersonation again users shouldn't be able to log into the proxy directly 00:09:07.760 --> 00:09:14.080 but this is relevant for the actual server that is running the proxy and in particular the weakness 00:09:14.080 --> 00:09:19.520 of password logins i've already created a video on adding two-factor authentication 00:09:20.240 --> 00:09:26.720 for ssh logins to linux machines which is a good way of adding additional protection 00:09:28.240 --> 00:09:34.800 the next two threats he identified are both denial of service attacks a potential process 00:09:34.800 --> 00:09:42.480 crash in the case of the web proxy then it's using nginx just well of tested application 00:09:43.920 --> 00:09:51.360 and to try and mitigate against that problem on the application that can be done through testing 00:09:53.360 --> 00:09:56.960 there are some things that can be covered through configuration 00:09:56.960 --> 00:09:59.600 it becomes a balance between different security aspects 00:10:01.360 --> 00:10:06.320 and i'll discuss that in more details later when i talk about the password hashing 00:10:08.960 --> 00:10:15.760 the data flow is much harder to protect against but one of the things for this is that this is 00:10:15.760 --> 00:10:23.360 not a critical system if it's unavailable there will not be any harm or real risk 00:10:24.560 --> 00:10:29.760 through a dos attack even if there is a denial of service attack 00:10:29.760 --> 00:10:35.040 against the proxy there's a good chance that it's still accessible to get to the web application 00:10:36.000 --> 00:10:38.560 from the local network without going through the proxy 00:10:40.240 --> 00:10:48.480 remote code execution is not really possible either on the proxy or the web application and 00:10:49.280 --> 00:10:56.320 the mitigation to avoid that is just by sanitizing the data received but it doesn't actually execute 00:10:56.320 --> 00:11:03.120 any of the data received anyway so the next one it comes up with is cross site request forgery 00:11:03.120 --> 00:11:09.440 now this is an interesting one it's something i forgot to include when i did my manual analysis 00:11:10.240 --> 00:11:15.120 although it is something i'm familiar with so it is something maybe i should have been thinking 00:11:15.120 --> 00:11:23.600 about but this is where the tool came in useful an explanation of cross site request forgery 00:11:23.600 --> 00:11:28.160 deserves its own video it i can't really go into the full details of it on here 00:11:28.880 --> 00:11:35.760 but i did some research about the flask module and there is a module available 00:11:35.760 --> 00:11:41.840 which adds protection for the logging sessions and i've enabled that in the web application 00:11:43.440 --> 00:11:51.840 another threat it identified was spoof inhuman user destination the mitigation in this is looking 00:11:51.840 --> 00:11:59.040 at the authentication mechanisms which i'll be explaining later and finally the last threat 00:11:59.040 --> 00:12:05.680 was identified here is that the human denies receiving the data as a repudiation 00:12:06.640 --> 00:12:11.840 there's no data that's really passed to the user that's particularly important on 00:12:11.840 --> 00:12:18.480 here so it's not something i'm really concerned with but i have already added login mechanisms 00:12:19.280 --> 00:12:27.680 as i've already mentioned so that would be the repudiation aspect so i said i created a second 00:12:27.680 --> 00:12:33.040 data flow diagram and this shows the interaction between the application and the local file system 00:12:35.520 --> 00:12:42.400 and there were seven through identified by the microsoft threat analysis tool for this i'm not 00:12:42.400 --> 00:12:47.040 going to list them in full there's just a few that are relevant so i'm just going to pull these out 00:12:48.800 --> 00:12:53.920 and there are three that are directly relevant and the first is about weak credential storage 00:12:54.640 --> 00:13:00.640 usernames and passwords will be stored on a local file system i'm already planned to use 00:13:00.640 --> 00:13:08.960 a suitable password hash and it also needs to be restrictions on who can access that password file 00:13:11.600 --> 00:13:18.960 second was the use of excessive resources the resources available on the raspberry pi are 00:13:18.960 --> 00:13:23.920 very limited and it wouldn't take much to overload that but it's not really a concern 00:13:23.920 --> 00:13:33.840 it's not critical system but the use of resources has influenced some of my decisions when coding 00:13:34.880 --> 00:13:42.000 and the third aspect is weak ass access control for resource 00:13:43.680 --> 00:13:52.240 again thinking about the security the password file the risk is also not just being able to 00:13:52.240 --> 00:13:57.760 access that password file but that someone with edit permissions to the application source code 00:13:57.760 --> 00:14:04.160 could also use that for an elevation of privilege and that's something i've thought about as well 00:14:07.600 --> 00:14:13.600 so after performing that initial analysis the next step is documenting and tracking these threats 00:14:14.160 --> 00:14:20.880 and providing appropriate resources to eliminate or mitigate the risk i'm going to show just a few 00:14:20.880 --> 00:14:25.840 of the things that i've implemented in my project one thing to remember is that this isn't a one-off 00:14:25.840 --> 00:14:30.480 task this is something that they can reviewed at different points in the software life cycle 00:14:32.800 --> 00:14:35.440 so i've already covered some of the ways that i've addressed some of the 00:14:35.440 --> 00:14:39.600 threats but there are four that i think is useful to cover in more detail as an 00:14:39.600 --> 00:14:43.840 example of how this threat analysis is then used to make the system more secure 00:14:46.640 --> 00:14:49.760 so the ones i'm going to look at are cross-site scripting 00:14:50.720 --> 00:14:58.640 weak authentication weak credential storage and weak access control for a resource so these are 00:14:59.360 --> 00:15:06.560 four of the threats that were identified earlier that i just think are going to give a good example 00:15:07.680 --> 00:15:11.840 of how it's influenced the code that i've created 00:15:16.160 --> 00:15:22.720 looking first at cross-site scripting this is where an attacker can send data to the server 00:15:22.720 --> 00:15:28.240 which can then be passed on to other users typically this is done by saving some data 00:15:28.240 --> 00:15:37.760 which includes say html script tags and some javascript code in that so for example a regular 00:15:37.760 --> 00:15:44.160 user they could update their real name field so instead of just showing their name it's got 00:15:44.160 --> 00:15:52.080 some javascript code hidden inside that and then when an admin views their profile then that code 00:15:52.080 --> 00:15:58.000 would be running the admins browser and that could be used to give a user elevated privilege 00:15:58.640 --> 00:16:03.840 or create a backdoor username and password or some other way of doing that 00:16:06.000 --> 00:16:08.480 the first protection for this is limiting who can ed 00:16:09.040 --> 00:16:15.920 edit the user details and in this case only administrators can change any of the details 00:16:17.760 --> 00:16:22.240 if a user is an admin already then it doesn't make sense for them to try and deliberately give 00:16:22.240 --> 00:16:28.080 someone else admin by trying to bypass that they could just use it using the normal admin means 00:16:30.560 --> 00:16:34.320 it may be that i want to give users the ability to update parts of their own 00:16:34.320 --> 00:16:40.080 profile in future so this wasn't the only protection i added so i did look at other 00:16:40.080 --> 00:16:47.840 ways as well i've taken a multi-stage approach to sanitizing the data the first is that flask 00:16:47.840 --> 00:16:53.840 itself automatically strips the html tags from forms unless it's explicitly told not to do so 00:16:55.040 --> 00:17:00.400 but then i've also added additional code in the objects that are updated to check for tags that 00:17:00.400 --> 00:17:06.640 are not allowed and this provides a good form of protection that i'm not only protecting the code 00:17:06.640 --> 00:17:11.520 as it's implemented at the moment but i'm also thinking about the future and some of 00:17:11.520 --> 00:17:18.320 the additional checks that are currently redundant may be required to reduce this threat in future 00:17:22.400 --> 00:17:24.640 also looking at weak authentications 00:17:26.560 --> 00:17:34.400 what are the authentication methods deployed i'm going to use two here and the first one is 00:17:34.400 --> 00:17:42.720 ip address ipdir is something that can be effectively whitelist ip addresses 00:17:42.720 --> 00:17:48.080 and they can have a guest like access they can access the application without having to log in 00:17:49.200 --> 00:17:53.680 this was a decision i made because i wanted to be able to continue to use this with my home 00:17:53.680 --> 00:18:02.240 automation system without needing to authenticate if you're using ip-based authentication then 00:18:02.800 --> 00:18:09.280 the user or computer can interact with the system control the leds but only if they're 00:18:09.840 --> 00:18:16.000 on an approved network so you can configure that just for a local ip address or your local ip range 00:18:17.440 --> 00:18:24.000 and if they want additional access or access out of the network then they'll need to log in 00:18:27.440 --> 00:18:31.680 then using a standard login via username and password 00:18:32.880 --> 00:18:38.320 i've already created videos on the risk of just using username and password authentication 00:18:39.120 --> 00:18:44.960 but it is considered sufficient for this system if your system is storing critical 00:18:44.960 --> 00:18:49.920 information then you may want to look at adding two-factor authentication or something similar 00:18:52.480 --> 00:18:56.800 an important consideration here is that the password should never be stored 00:18:56.800 --> 00:18:59.840 as plain text i'll be covering this next 00:19:00.880 --> 00:19:05.520 also the password should never be transmitted unsecured over a public network 00:19:06.320 --> 00:19:15.680 in this case https is used between the user and the proxy and only ever passed unencrypted over 00:19:15.680 --> 00:19:23.840 the local network i've already said about securing that that's something that needs to have been done 00:19:26.000 --> 00:19:31.200 so on weak credential storage as i've mentioned the password is only ever stored in a hash 00:19:31.200 --> 00:19:38.560 form this means it's possible to check password is valid by hashing the password that the user 00:19:38.560 --> 00:19:46.080 provides but it's not possible to work back to find the original password from the hash i've 00:19:46.080 --> 00:19:51.040 covered some of the flaws in this in another video essentially the security this password is down to 00:19:51.040 --> 00:19:57.760 the algorithm used there are different algorithms available i started by using what's considered to 00:19:57.760 --> 00:20:03.840 be one of the most secure which is argon 2. i implemented that in code but the problem 00:20:03.840 --> 00:20:10.240 was that the system would take a long time to process just a simple login not only that if the 00:20:10.240 --> 00:20:18.640 user tried again thinking it had not accepted their password then with multiple requests 00:20:19.680 --> 00:20:25.200 and this could cause the system to grind to a halt and this was particularly the case on a raspberry 00:20:25.200 --> 00:20:30.080 pi zero which is the lowest spec of the machine that this application is designed to run on 00:20:32.080 --> 00:20:36.960 this meant there's a conflict between the level security and the availability remember 00:20:36.960 --> 00:20:44.320 availability is another of the security requirements in the aaa security framework 00:20:46.000 --> 00:20:53.200 rather than increasing the system requirements so needing a more powerful processor i've added 00:20:53.200 --> 00:21:01.040 a configuration option which allows a security compromise use argon 2 for maximum security which 00:21:01.040 --> 00:21:12.400 is useful on a higher specs computer or sha256 for better performance shelf 256 not as secure but 00:21:13.520 --> 00:21:18.880 it works well on the 32-bit operating system and the low spec the raspberry pi 00:21:21.680 --> 00:21:28.720 and this brings us on to the file permissions restricting access to that file is an important 00:21:28.720 --> 00:21:35.440 step to ensuring it is as secure as possible if someone has login to the system and update access 00:21:35.440 --> 00:21:42.480 to the password file they can also grant any user admin access so it's important to restrict who can 00:21:42.480 --> 00:21:48.400 do that another check that i've included is to check for invalid characters when saving 00:21:48.400 --> 00:21:54.160 the username and passwords it shouldn't be a problem as only admin can add users 00:21:54.720 --> 00:22:00.240 but it does check that nobody is trying to trick the system by adding an extra colon which could 00:22:01.920 --> 00:22:05.120 allow you to insert say a different password in all 00:22:06.160 --> 00:22:12.480 other fields which is kind of similar to how an sql injection attack might be used against 00:22:12.480 --> 00:22:17.440 a database but thinking specifically about the file format in this case 00:22:22.720 --> 00:22:31.040 and then the fourth one is weak access control for a resource and i'm going to cover here a bit 00:22:31.040 --> 00:22:37.280 more than the threat identified by the microsoft threat analysis tool now something to be aware of 00:22:37.920 --> 00:22:43.040 here is that looking at the interaction between the operating system and users of that system 00:22:43.840 --> 00:22:48.400 and in most cases the only users would log on to an operating system for this kind of 00:22:48.400 --> 00:22:53.840 setup would be administrators in which case most of this is not really a direct risk 00:22:55.680 --> 00:22:59.840 it is still good practice though to treat it as though there were multiple users on this system 00:23:00.560 --> 00:23:04.400 and that can also help prevent problems in the event that an attacker 00:23:04.400 --> 00:23:10.800 so manages to get on the system because by setting appropriate file permissions you can prevent 00:23:11.520 --> 00:23:16.800 either information leakage or that user getting a privilege escalation 00:23:20.880 --> 00:23:24.800 it should be very obvious you need to restrict who can read the password file 00:23:25.520 --> 00:23:28.160 even though the passwords are stored as a password hash 00:23:28.960 --> 00:23:35.840 depending upon the quality of the password the users use it may be possible to crack those 00:23:37.920 --> 00:23:44.320 the next thing to consider is the security of the code this is something that should be considered 00:23:44.320 --> 00:23:50.720 for any server as if someone can edit or change the code they may be able to add say a backdoor 00:23:51.520 --> 00:23:56.080 an additional thing to be aware of in this program is it needs to run with root 00:23:56.080 --> 00:24:02.560 admin permissions this is a requirement both to be able to use the port 80 00:24:03.360 --> 00:24:12.560 but also to be able to access the neopixels that are the rgb leds that it uses 00:24:14.880 --> 00:24:21.280 and what this means is that if a regular user is able to edit those executables they 00:24:21.280 --> 00:24:30.080 could potentially gain enhanced privileges there's one idea that could be a potential 00:24:30.640 --> 00:24:35.440 way of mitigating this is that you could monitor the executable files there are some 00:24:35.440 --> 00:24:43.280 tools available such as tripwire which can be used to alert to changes in the program files often 00:24:43.280 --> 00:24:48.640 these tools will alarm when it's too late perhaps when the user has already got escalated privileges 00:24:49.520 --> 00:24:57.760 but in this example as long as you're not running flask in demo bug mode the python code will not be 00:24:57.760 --> 00:25:06.720 reloaded unless the system or at least the process is restarted so that could be a while after 00:25:06.720 --> 00:25:13.920 the users made that change so using a monitoring tool such as tripwire could help with catching any 00:25:13.920 --> 00:25:21.760 malicious code before the system is restarted and before a attacker is able to exploit that 00:25:23.920 --> 00:25:27.840 i'm going to finish this here this hasn't been a complete analysis 00:25:28.400 --> 00:25:35.200 it's only covered some of the risks and i'll put a bit more information on my website so 00:25:35.760 --> 00:25:41.680 look in the description for the link to that the amount of time needed for the threat analysis 00:25:41.680 --> 00:25:48.560 is going to depend upon how secure you need the system to be what is in scope need the 00:25:48.560 --> 00:25:56.080 operating system versus the application and the complexity of the program you're developing i've 00:25:56.080 --> 00:26:00.160 skipped some of the features and some of the analysis that has been done on this project 00:26:01.840 --> 00:26:05.920 but this video has shown some of the steps that need to be performed 00:26:07.120 --> 00:26:10.800 and shown this using a real example rather than just the theory 00:26:11.920 --> 00:26:19.120 so we started with the data flow diagrams identified where there's a potential 00:26:19.920 --> 00:26:27.520 of the data being accessed or been manipulated and then we looked at how we can apply these 00:26:28.800 --> 00:26:36.960 six threats to that data and then looked at what changes we could make in the code to mitigate 00:26:36.960 --> 00:26:42.080 against these there are some of the different models that can be used stride is just one of them 00:26:43.200 --> 00:26:48.160 but whatever method or tools you use it's helpful to have a framework which helps you to focus 00:26:48.160 --> 00:26:54.880 on identifying these potential vulnerabilities and so i hope this video has been useful 00:26:55.600 --> 00:27:02.080 if so please give it a like to help let others know i'll be creating some other cyber security 00:27:02.080 --> 00:27:08.720 videos in future so please subscribe if you're interested in future topics and let me know in 00:27:08.720 --> 00:27:14.560 the comments if there is anything particular you'd like me to cover on cyber security 00:27:16.560 --> 00:27:26.480 thanks for watching and i hope to see you again in a future video
