WEBVTT 00:00.000 --> 00:17.560 Welcome to Offensive Embedded Exploitation Getting Your Hands Dirty with IoT and Embedded Devices So, the agenda, before we start with the talk I would like to tell you that I am conducting a training I would like to thank Mr. 00:17.560 --> 00:18.500 Omer and Mr. 00:18.500 --> 00:32.740 Joseph for allowing me to conduct a training with Defcon Red Team Village, which is on Day 1 So, I request you to, if you want if you like this talk, if you want to attend this in a more deeper manner you can attend tomorrow's training. 00:32.980 --> 00:36.940 So, let's start with the agenda of today's talk. 00:36.940 --> 00:55.020 Today, we will first have an introduction to IoT then we will do a preparing the arsenal that is a setting up our requirement then we will have recon, then show time that is a firmware analysis, then getting hands dirty, dynamic testing and lastly we will touch base upon fuzzing, 00:55.020 --> 01:14.340 reverse engineering and exploit development So, let me introduce myself I am Kaustubh Padwad from India also known as Security Beast on Twitter I have dozens of exploits listed on GitHub and CVE details on IoT. 01:14.340 --> 01:37.580 Also, I am a security researcher at Reliance Jio that is Jio Platform now, Jio Platform Limited where we conduct device security testing for all of the Jio Platform devices Also, I am a SINAC Red Team member to keep myself updated and to hack into the toughest infrastructure, 01:37.580 --> 01:51.920 SINAC is a great learning platform and also I do bug bounty there and I like to share my knowledge, so I am a speaker I speak at conferences And now, it's time to get started with the topic. 01:52.340 --> 01:58.460 So, the I have classified IoT in a three style. 01:58.460 --> 02:05.500 One is a industry IoT , second a human IoT and third IoT for others, that is animals. 02:05.500 --> 02:25.080 So, we will see , I have classified here all the industry in this image taken from a source is mentioned Here , I have listed all the industries like manufacturing industry, smart government, mobile network, mobility and Wi-Fi, smart digital citizens, 02:25.080 --> 02:35.140 that is us, then open data, health is a key element in IoT, then smart agriculture and smart building smart transportation. 02:35.140 --> 02:38.600 So, these things are getting smart with the help of IoT. 02:38.600 --> 03:04.060 Major like, for example, a transportation industry, Tesla is building Tesla is the best example for IoT based car even for a logistic, IoT is getting used in very huge manner to track their shipments that to ensure the data, the packages which is shipping should not get tampered they are putting tamper detection based on IoT. 03:04.060 --> 03:16.600 So, it's like simply if someone opens the door, that means it is tampered and as the door is opened, that small IoT device will send generate an alert and send to the respective logistic person. 03:16.600 --> 03:25.320 Manufacturing industries are using IoT to improve their services or to improve their production product qualities. 03:25.320 --> 03:32.720 So, there should be a zero error product development, we can say with the manufacturing industry. 03:32.800 --> 03:43.880 And government, like government should implement IoT In my training, I have an excellent example, which I covered there in my training. 03:43.880 --> 03:53.560 So, let's assume that every city have a street light hundreds and thousands of street lights, which is running from night, which is running whole night. 03:53.560 --> 04:08.200 So, if you install one small IoT module of let's say $5 cost to that light, then that light will become smart and it will turn on only when the vehicle is passing through. 04:08.200 --> 04:12.080 And rest of the time, it will stay in an ideal state, let's say power off state. 04:12.080 --> 04:18.640 So, that $5 module can save your $500 electricity bill for every month. 04:18.740 --> 04:29.440 So, it makes sense of using IoT in government covered areas or government entities. 04:29.440 --> 04:33.860 Mobility and Wi-Fi, they are key provider for the IoT. 04:33.860 --> 04:43.640 As I said in mobility as government needs or let's say if you want to create a IoT environment so, mobility is the best way. 04:43.640 --> 04:49.260 They provide us a NB -IoT, Narrowband IoT and LTE -IoT. 04:49.300 --> 04:53.740 So, these two ways they can provide us IoT connectivity to everywhere. 04:53.740 --> 04:54.980 Health is the key element. 04:54.980 --> 04:56.840 We are discussing this here. 04:56.840 --> 05:07.480 Agriculture, one of my friends have built IoT based water system to his farm. 05:07.480 --> 05:17.860 So, it detects soil dryness, it detects wind speed, it detects temperature and accordingly it turns on his water pump. 05:17.860 --> 05:23.760 So, it will automatically give water to the plants to his farm also. 05:23.760 --> 05:34.520 And smart building, there is an excellent example in the next slide for smart building and transportation as we just talked about Tesla. 05:34.520 --> 05:36.540 Now, in human IoT. 05:36.540 --> 05:40.000 So, devices are getting inside the body. 05:40.000 --> 05:41.740 Like for example, a pacemaker. 05:41.740 --> 05:44.840 Pacemaker is a medical device, medical IoT device. 05:44.840 --> 05:52.520 It's a really critical device in IoT aspect or in any aspect. 05:52.520 --> 05:59.060 And insulin pumps and these are other devices which can be currently using inside the body. 05:59.060 --> 06:02.280 There could be more but as of now I corrected this. 06:02.600 --> 06:12.640 Now, you can trigger insulin shots to your loved ones remotely with this insulin pump. 06:12.640 --> 06:26.180 You can check if there is a what we say abnormal behavior of heart or abnormal behavior inside the body. 06:26.180 --> 06:27.860 These pacemakers are also smart. 06:27.860 --> 06:39.040 They can send data to doctor that it is not behaving good or you can as we know pacemaker is a critical medical device. 06:39.040 --> 06:41.100 It controls your heartbeat. 06:41.100 --> 06:43.700 Now, why cow is here? 06:43.720 --> 06:47.780 So, IoT animals are getting smarter. 06:47.780 --> 06:54.940 So, like if your pet lost direction then there are some patterns which they triggers every time. 06:54.940 --> 07:05.020 If they feel like lost or if they are not let's say you are not with your pet a complete day and suddenly he developed a fever. 07:05.020 --> 07:05.740 Then what? 07:05.740 --> 07:19.520 So, some guys are working on the solution which will be a kind of belt inside their body or inside their neck tied to their neck and that belt will keep analyzing their behavior. 07:19.520 --> 07:20.980 Are they behaving normal? 07:20.980 --> 07:23.160 Are they feeling like lost? 07:23.160 --> 07:25.480 Is their temperature is normal? 07:25.480 --> 07:38.620 So that you can take appropriate care of your loved one pet and you can track your animals also like your pet also that if they are lost or then you can track them. 07:38.820 --> 07:41.820 So, IoT is a major part of our body. 07:41.820 --> 07:48.380 IoT is an emerging field and IoT is too much powerful than we imagine. 07:48.500 --> 07:51.720 So, with the great power, great responsibilities also come. 07:51.720 --> 07:54.820 That we will discuss in a further section. 07:55.140 --> 07:58.040 Now, let's have a look of smart building. 07:58.040 --> 08:02.720 How one can implement IoT in a smart building. 08:10.100 --> 08:12.280 Jing Jing. 08:14.080 --> 08:15.060 Tian Bao Jin Ling. 08:15.920 --> 08:23.600 Tian Bao Jin Ling. 08:29.820 --> 08:33.120 Tian Bao Jin Ling. 08:42.720 --> 08:51.980 The self-check-in machine like the guest mobile check-in like the robot service and Timogeneous voice spatula. 08:51.980 --> 09:00.240 The purpose of this kind of service and technology is to improve the efficiency of the service and the consistency of the service quality. 09:03.120 --> 09:03.700 Jing Jing. 09:12.700 --> 09:14.580 Jing Jing. 09:14.740 --> 09:16.380 Jing Jing. 09:16.380 --> 09:17.760 Jing Jing. 09:17.760 --> 09:18.320 Jing Jing. 09:18.920 --> 09:19.680 Jing Jing . 09:21.420 --> 09:21.640 Jing Jing. 09:21.640 --> 09:22.180 As 09:25.850 --> 09:33.810 you can see, a smart building a brilliant example of smart building IoT in action. 09:33.810 --> 09:38.130 So, I would definitely like to go there and check-in to test the services. 09:38.550 --> 09:42.890 So, with the great news, great responsibilities do come. 09:42.890 --> 09:50.250 So, what I think is why IoT security assessment or why embedded devices security assessment is important. 09:50.250 --> 09:52.410 I have collected some hot news. 09:52.890 --> 10:00.690 This is IoT hot news where we can see multiple threats and risks that currently associated with IoT. 10:00.690 --> 10:04.610 The first and most important risk here. 10:04.930 --> 10:07.870 Risk with IoT in a medical field. 10:07.870 --> 10:23.890 So, when I was a kid, my grandparents used to tell us that there is a witchcraft and there is a black magic kind of stuff which can remotely kill someone. 10:24.070 --> 10:30.030 So, I don't believe on that but here you can see with IoT you can do it. 10:30.030 --> 10:38.310 Let's say, instead of giving 10ml pump shot, if I trigger 100ml pump shot, then who can save you? 10:38.310 --> 10:47.730 Instead of setting your heart rate to the normal heart rate if I set it to 3000 beats per second you will suffer from a major cardiac arrest. 10:48.030 --> 10:54.510 So, as we can see these are inside the body and these are very critical devices. 10:54.510 --> 11:01.730 So, security assessment for these devices must be done in a very aggressive way. 11:01.990 --> 11:09.370 I believe that if such kind of devices are manufactured by a very renowned vendor, it should be tested country-wide. 11:09.370 --> 11:17.690 It should be offered to the expertise all across the globe and then you can ensure that this product is secured or not. 11:17.690 --> 11:21.750 Because everything has a different mindset to test everything. 11:21.750 --> 11:36.150 So, same way Now you brought an IoT product that is a surveillance robot to secure your house and to take care of your loved ones when you are not in the home. 11:36.230 --> 11:40.570 And hackers use that robot for spying you. 11:40.570 --> 11:47.530 Here you can see hackers break into a smart home, play inappropriate music and communicate with a resident via camera. 11:47.530 --> 11:48.990 It's a horrible thing. 11:48.990 --> 11:50.110 It's a scary thing. 11:50.110 --> 11:57.150 If someone is continuously watching you and someone is talking with your speakers only, how would it feel? 11:57.150 --> 11:57.510 Right ? 11:57.530 --> 11:58.650 It's scary. 11:58.650 --> 11:59.810 Super scary. 12:00.290 --> 12:04.530 And this attack it is an industry grade attack. 12:04.530 --> 12:09.790 Someone discovered a remake of Mirai botnet. 12:09.790 --> 12:13.470 It was the OMG attack was discovered by Fortinet. 12:13.470 --> 12:15.430 It was the second Mirai. 12:15.510 --> 12:19.710 So, Mirai is the biggest attack, biggest IoT attack till now. 12:19.710 --> 12:21.150 You can read about it. 12:21.150 --> 12:23.250 It's a really interesting attack. 12:23.590 --> 12:33.670 This is again like you brought a surveillance system to watch your home and that surveillance system is watching is watched by hackers. 12:33.670 --> 12:46.370 So, this device was running one video talk protocol which was sending the audio, which was recording the audio by mic and sending it to the one who connects over video talk to the camera. 12:46.670 --> 12:47.550 It is again scary. 12:47.550 --> 12:48.130 Right? 12:48.130 --> 12:54.190 I believe there should be some system which will ensure that how this product is secure on scale of 10. 12:54.190 --> 12:58.330 So, it will be easy to judge whether we should buy it or not. 12:58.330 --> 13:03.810 Like a product rating, there should be a security rating also should be there. 13:03.810 --> 13:05.430 And this is the major threat. 13:05.430 --> 13:11.510 FDA recalls nearly half of million pacemakers over This is the really critical issue. 13:11.510 --> 13:17.710 So, as you see the life risk is associated with the risk of with the IoT devices. 13:17.710 --> 13:23.770 So, that's why the security assessment of such a product is really crucial and really important. 13:23.770 --> 13:25.790 It should be done right. 13:26.530 --> 13:35.350 Now, my case study for this is can this decent looking IP phone change into a botnet? 13:35.430 --> 13:36.130 What do you think? 13:36.130 --> 13:39.630 You can turn this device into a botnet? 13:39.810 --> 13:43.550 Most of the guys will be thinking how this can be possible. 13:43.690 --> 13:48.550 Or if there are experts who have already played with it, may know the trick what I am going to try. 13:48.550 --> 13:49.030 Right? 13:49.190 --> 13:58.930 Now, one day, one fine day I was thinking about which device should I pick up for the training for this product and which device should I pick up for the brief also. 13:58.930 --> 14:04.650 So, I was staring at IP phone and suddenly it comes in my mind that why not this IP phone only. 14:04.950 --> 14:08.770 As every corporate have IP phone. 14:08.770 --> 14:09.350 Right? 14:09.350 --> 14:13.830 So, let's say our corporate is one of the biggest large corporate. 14:13.830 --> 14:19.910 So, we have at least 40,000 IP phone of same brand inside our office. 14:19.910 --> 14:22.490 And Mumbai is a corporate hub. 14:22.490 --> 14:31.150 So, I guess that there should be more than crores of IP phone will be there in Mumbai of same brand. 14:31.150 --> 14:33.470 I am not talking about multiple brands. 14:33.570 --> 14:42.230 Let's say if vendor X is producing X type of IP phone, that same type of IP phone you will find at least 1 crore IP phone in the city. 14:42.490 --> 14:51.070 And if you target a specific call center, BPO and KPO then their business is IP phone. 14:51.070 --> 14:51.450 Right? 14:51.450 --> 14:55.510 So, if you target that, you will get lots and lots and lots of target. 14:55.570 --> 15:03.090 So, if you are able to remotely compromise one IP phone, you are able to compromise crores of IP phone. 15:03.090 --> 15:08.950 At least same types of crores of IP phone using this technology. 15:08.950 --> 15:21.950 So, if you have hacked two organizations having 50,000 IP phones each, that will create 1 lakh, that creates your 1 lakh bots. 15:22.430 --> 15:24.990 Maybe it could take 8 days, 10 days 15 days. 15:24.990 --> 15:30.170 But within 15 days, you will get 1 lakh computers, 1 lakh bots. 15:30.170 --> 15:32.590 Basically, what IP phone is inside. 15:32.590 --> 15:35.010 It's an ARM machine or MIPS machine. 15:35.010 --> 15:35.570 Right? 15:35.690 --> 15:40.810 So, you may get 1 lakh bots in just 8 to 15 days. 15:40.810 --> 15:47.050 Now, let's say if you target complete city, you may end up with 50 lakhs IP phone. 15:47.050 --> 15:47.530 Right? 15:47.530 --> 15:49.490 In a city you will definitely get. 15:49.490 --> 15:59.970 Now, let's say if you target cities, multiple cities then you can, let's say India have 4 big corporate hubs. 15:59.970 --> 16:03.590 Mumbai, Delhi, Chennai and Bangalore. 16:03.590 --> 16:08.830 So, if you hack even those 4 cities, 4 corporate hubs and Hyderabad also, sorry. 16:08.830 --> 16:15.030 So, these 5 cities, you may end up with at least 5 crores IP phone. 16:15.030 --> 16:27.030 Now, let's assume if that 5 crore IP phone, you are instructing those 5 crore IP phone to make a 10 request per second to the facebook.com So , 5 into 10 is 50. 16:27.030 --> 16:29.530 50 crore request per second to the facebook. 16:29.570 --> 16:32.710 You think how long it can survive? 16:32.850 --> 16:34.410 Let's say any big provider. 16:34.410 --> 16:39.210 Facebook, Google or for how long time it can hold such a load? 16:39.210 --> 16:45.810 Even you can increase a 10 to 20 request per second that is around 100 crore request per second. 16:45.810 --> 16:46.390 Right. 16:46.470 --> 16:48.530 It could be a bigger storm. 16:48.690 --> 16:51.770 And I am just talking about 5 cities of 1 country. 16:51.770 --> 16:59.730 Now, let's say if you target a multiple country with the same attack, you can create a biggest TBPS attack in the history. 17:00.150 --> 17:02.690 So, I build a case study. 17:02.690 --> 17:04.890 How can we make this possible? 17:06.610 --> 17:11.030 But before that, we need to set up our machine to test this. 17:13.370 --> 17:28.670 Most of the time when I give a talk to a conference or seminar or chapters like null chapters or somewhere, they ask me Sir, I want to start with IOT but I don't have enough requirement machines. 17:29.050 --> 17:35.890 So, this is like, you know, you need nothing literally nothing to set up a basic setup for IOT test. 17:35.890 --> 17:42.030 Here I have shortlisted to get started What all you need is a Linux. 17:42.090 --> 17:43.130 Why Linux? 17:43.130 --> 17:49.290 Because Linux is smooth with virtualization of ARM and MIPS devices. 17:49.290 --> 17:56.770 And all IOT devices binary not all, most of the binary work with the ARM technology or MIPS technology. 17:56.770 --> 18:00.430 So, to smoothly virtualize it, you need a Linux. 18:00.970 --> 18:05.630 Secondly, Linux gives you lowest level access to the operating system. 18:05.630 --> 18:18.250 So, if you connect a device to USB port it will definitely give you something like manufacturer, product ID vendor ID, device type ID, something it will give. 18:18.250 --> 18:22.130 It won't tell you like a Windows that unknown device. 18:22.150 --> 18:22.970 Right? 18:23.030 --> 18:24.330 That's why Linux. 18:24.330 --> 18:30.390 And there are more reasons which we are which you may get in a training section. 18:30.950 --> 18:35.110 This device is the JTAGulator. 18:35.290 --> 18:40.750 So, JTAG is an interface which some devices don't have any interface. 18:40.750 --> 18:52.070 No UART no console cable, no USB no LAN port, no WAN port So, in that case what you should use to interact with device. 18:52.070 --> 18:52.250 Right? 18:52.250 --> 18:54.910 Our target is to get into the device. 18:54.910 --> 18:57.450 That is our first target as an IOT guy. 18:57.690 --> 19:06.610 So, in that case what you can do is you can use JTAGulator to connect with the JTAG ports of the device. 19:06.610 --> 19:10.670 Now, you may say why not no JTAG in the device? 19:10.810 --> 19:12.770 Because this is not the case. 19:12.770 --> 19:20.750 JTAG is present in most of the devices because it is used for purely factory debugging process or factory QA process. 19:20.750 --> 19:30.890 Let's say device is an assembly line, it gets manufactured it puts a required data and now before going to production, device needs to run a QA . 19:30.970 --> 19:40.750 So, nobody is going to check manually that hundreds and lakhs and millions of devices with manually checking 1 , 1, 1, 1 pin. 19:40.750 --> 19:41.310 No. 19:41.710 --> 19:50.210 What it do is, it will connect JTAG pins to the device and it will test all the functionality with their JTAG testing suite. 19:50.210 --> 19:51.590 So, JTAG is present. 19:51.590 --> 20:03.070 You may not find the JTAG pins on the device, but you will find a point where you can solder the pins and you can connect a JTAG regulator and identify the appropriate JTAG pins. 20:03.230 --> 20:08.330 Now, as a IoT comes in the mind second thing come is a wireless. 20:08.510 --> 20:10.810 IoT gives you a wireless freedom. 20:10.810 --> 20:17.310 So, like now the device with 2 sensors and 1 server is not connected over wire. 20:17.410 --> 20:19.890 These will be connected with a wireless technology. 20:19.890 --> 20:24.910 For example our ZigBee protocol, Z-Wave protocol. 20:24.990 --> 20:31.890 So, to test this kind of protocol, we need some specific hardware which will identify those frequencies. 20:31.890 --> 20:41.590 So, this API motor is a gadget which can, which allow you to perform a ZigBee test like ZigBee packet injection, ZigBee packet replay attack. 20:41.590 --> 20:47.210 So, you may see building lights, these are controlled most of the lights are controlled by ZigBee. 20:47.770 --> 20:49.650 And connectors, finally. 20:49.650 --> 20:51.350 Seriously, they are life. 20:51.990 --> 20:54.350 Without connector, you cannot test IoT. 20:54.350 --> 21:07.070 We need at least 1 extra LAN card, we need at least 1 WAN card, we need an additional Bluetooth adapter, we need 1 screwdriver set, we need a Skira, because Skira is an all-in-one connector. 21:07.070 --> 21:25.430 So, instead of spending for individual connectors, if you can spend that's fine, but instead of spending on this multiple you can buy 1 Skira connector which supports GPIO communication, which supports JTAG communication, which supports UART communication and also SPI communication. 21:25.430 --> 21:29.470 So, if you buy this 1 product your all problems will get solved. 21:29.470 --> 21:34.410 And lastly to hack the radio frequencies, we need a hack RF device. 21:34.410 --> 21:39.410 So, this is the minimum thing you need to get started with a IoT test. 21:39.410 --> 21:40.250 Ok. 21:41.030 --> 21:44.690 Now, this is a basic setup. 21:44.690 --> 21:46.690 Now, what about advanced setup? 21:47.690 --> 21:48.590 This. 21:50.510 --> 21:52.930 You can buy endless stuff. 21:53.070 --> 21:56.350 As new device will come, you need to buy something. 21:56.650 --> 22:04.790 As new device may have other way to communicate, you have to build your own PCB boards to communicate with that device. 22:04.910 --> 22:11.150 So, there was 1 device which is not directly connected over USB, so there was a mediator chip in between. 22:11.150 --> 22:13.990 So, you have to connect that device to that mediator chip. 22:13.990 --> 22:20.090 That mediator chip was converting those signals into UART and then UART to USB converter and that to laptop. 22:20.170 --> 22:21.770 So, this was the complete setup. 22:21.770 --> 22:24.190 So, there is no limitation for advanced setup. 22:24.190 --> 22:26.690 You can build up to whatever you want. 22:27.510 --> 22:30.390 Now, we are done with the hardware part. 22:30.390 --> 22:31.350 What about software? 22:31.350 --> 22:32.610 Which tools are required? 22:32.610 --> 22:34.170 Are those tools are expensive? 22:34.170 --> 22:35.590 Are those tools are paid? 22:35.590 --> 22:39.570 Are those tools are really too much heavy that one cannot afford? 22:39.570 --> 22:41.970 No, this is not the case. 22:42.130 --> 22:49.070 This I called as a weapons and these are the minimal weapons which are needed for testing. 22:49.110 --> 22:50.270 One is a BinWalk. 22:50.270 --> 22:52.090 So, BinWalk is a great tool. 22:52.090 --> 22:54.510 You can do a firmware extraction. 22:54.610 --> 22:56.690 BinWalk is basically give a firmware to BinWalk. 22:56.690 --> 23:01.670 BinWalk will extract you if there is a uncompressed, sorry unencrypted firmware. 23:01.670 --> 23:02.310 Ok. 23:02.990 --> 23:04.370 We need a Firmadyn. 23:04.370 --> 23:07.410 So, Firmadyn is a collection of multiple tools. 23:07.550 --> 23:20.730 The Firmadyn consists of BinWalk, QMove and Postgres database and it's a properly it's a properly organized framework for emulating the firmware. 23:20.730 --> 23:21.330 Ok. 23:21.410 --> 23:29.610 So, we need a Firmadyn to emulate a device firmware in case you don't have a device and you have only the firmware and you want to test it. 23:29.810 --> 23:32.190 I hope everyone is familiar with it. 23:32.190 --> 23:34.470 It is the great software tool we have. 23:34.470 --> 23:39.110 And we need a Python because most of the tasks we have to do it on repeated basis. 23:39.110 --> 23:43.330 So, to automate that stuff Python is the great and easy to write language. 23:43.450 --> 23:45.790 And lastly, IDA Pro. 23:45.810 --> 23:47.910 So, if you can't afford IDA Pro, it's ok. 23:47.910 --> 23:55.290 You can buy IDA Community Edition or you can use some open source tools like Radare or NSA Ghidra also. 23:55.290 --> 23:58.930 NSA Ghidra is also a great tool to reverse engineer. 23:58.930 --> 24:02.210 But trust me, reverse engineering is the life. 24:02.210 --> 24:08.470 Reverse engineering is the life and reverse engineering is the most important aspect of device. 24:08.890 --> 24:16.410 So, there are few things that comes in the mind when someone asks why you need to reverse engineer the binary. 24:16.410 --> 24:18.570 Hard-coded backdoor account. 24:18.850 --> 24:36.730 Some devices, recently when there is a news called on I forgot the name of that router OS but that router OS is having 7 major issues was recently identified and most of it was a hard-coded backdoor account. 24:36.810 --> 24:38.750 That too listening on a WAN interface. 24:38.750 --> 24:47.850 So, let's say if your device is running a telnet on WAN interface and if there is a backdoor account, you never know how one can enter in your network. 24:48.310 --> 24:50.050 So, this is one aspect. 24:50.050 --> 24:55.890 Second is identifying a critical vulnerability like remote code execution. 24:55.890 --> 24:58.910 As in embedded device, there is very limited space. 24:58.910 --> 25:02.590 So, you have to fit everything in that small space. 25:02.630 --> 25:08.850 So, application logic and application code is inside the web application binary only. 25:09.090 --> 25:31.890 So, to identify that binary the best way is to reverse engineer that binary and get assembly code out of it and then perform assembly analysis to identify where the native vulnerable calls like sprintf or system call fopen, popen kind of calls are in use. 25:31.910 --> 25:35.190 So, to reverse engineer we need a IWP. 25:36.070 --> 25:45.170 Now, let's move towards, once you have set up everything we start with the first stage is always the reconnection of WAN testing. 25:45.350 --> 25:47.890 In IoT also it's not exceptional. 25:47.890 --> 25:49.470 First stage is recon. 25:49.470 --> 25:52.230 I split this recon section into two parts. 25:52.310 --> 25:55.850 First active recon and second passive recon. 25:55.850 --> 26:01.110 So, generally in pen testing we perform active recon first and then passive recon. 26:01.110 --> 26:02.310 Here we have to do reverse. 26:02.310 --> 26:05.630 Like first we have to identify, we have to do a passive recon. 26:05.630 --> 26:16.790 Let's say if you got one device for example this headset and now the manufacturer of this headset is saying that this device does not support a WiFi. 26:16.790 --> 26:18.950 So, how can you ensure it? 26:18.950 --> 26:24.090 Just because he said this doesn't support WiFi, you are going to believe that this doesn't support WiFi. 26:24.090 --> 26:24.830 No. 26:24.890 --> 26:27.330 You have to read their specifications. 26:27.770 --> 26:42.490 So, each device have one unique FCC ID and if you search that FCC ID into the FCC ID database, it will come up with all the specifications are exist with the device. 26:42.490 --> 26:43.010 Ok. 26:43.010 --> 26:49.090 So, sometimes vendor may lie to you that this functionality is not supported at hardware level and they can disable it. 26:49.090 --> 26:56.190 Like this happens with me with one product that vendor was saying, Sir, this device doesn't support WiFi. 26:56.190 --> 27:01.230 And on FCC ID device, they have mentioned that this device supports WiFi. 27:01.410 --> 27:08.970 So, we had a long debate and lastly I ended up with creating custom firmware which loads the WiFi driver. 27:08.970 --> 27:11.050 So, basically they just disabled the WiFi driver. 27:11.050 --> 27:13.990 That's why WiFi is not coming up of that device. 27:13.990 --> 27:14.590 Ok. 27:14.590 --> 27:18.430 So, first we have to do a FCC ID analysis. 27:18.470 --> 27:20.810 Second, documents . 27:20.810 --> 27:24.710 You should ask for as much as possible documents. 27:25.270 --> 27:30.890 So , like that document could be a security architecture document. 27:30.890 --> 27:34.370 That document could be a product data sheet. 27:34.370 --> 27:41.330 That document could be a project description sheet or could be a user manual of the product. 27:41.930 --> 27:42.270 Ok. 27:42.270 --> 27:47.930 So, these are the things that you should do first and then you should touch to the device. 27:48.150 --> 27:53.410 And then once you touch to the device, first thing is to know your device. 27:53.450 --> 27:54.210 Right. 27:54.250 --> 28:01.430 So, if I give you something like you have to test this device, what you will do? 28:01.430 --> 28:11.190 Like in web application, we see what technology it is built on, like LAMP stack is there or what are the directories are in use, what is the server. 28:11.230 --> 28:18.430 So, same way in device security testing or IoT pen testing, we have to identify the multiple entry points to the device. 28:18.430 --> 28:20.830 For example, a LAN port. 28:20.830 --> 28:39.490 In this device, there is a LAN port, there is a console port or there could be a WiFi this IP phone might be using and some like if device is running on Android, there could be a ADB running on it. 28:39.650 --> 28:48.630 Some advanced devices that I told you about Narrowband IoT, they could be using an IDD interface to communicate with the server. 28:48.630 --> 28:50.690 No IP network basically. 28:50.690 --> 28:52.630 No IP data delivery network. 28:52.630 --> 28:53.230 Ok. 28:53.230 --> 29:02.850 And then you can check for the UART, if UART is present, console port is present, if Android is there, then ADB is present. 29:02.950 --> 29:08.850 If classic ports are there, then LAN port is there, console port is there. 29:09.250 --> 29:11.210 So, first thing is to know your device. 29:11.210 --> 29:12.890 How can you interact with that device? 29:12.890 --> 29:16.930 How can your Linux, your pen testing machine can interact with the device? 29:17.210 --> 29:26.350 And once you know that you can interact with device with specific way, you should go through the documents. 29:26.350 --> 29:32.810 So, here are some glimpse that will help you in identifying why document review is important. 29:32.810 --> 29:39.470 So, here in this document, vendor is saying that this device supports SIP version 2 and RTP. 29:39.470 --> 29:43.130 That means this device does not support SIP TLS. 29:43.130 --> 29:44.110 SIP TLS. 29:44.110 --> 29:57.170 So, if someone is able to sit in the MITM attack, he could able to hear your hear your traffic, hear your call which you had word with. 29:57.170 --> 30:00.390 Here you can see this device support TR-069. 30:00.490 --> 30:07.930 So, most of the classic guys who is working on Windows, on Linux, on network pen testing are not familiar with the TR-069. 30:07.930 --> 30:17.010 So, TR-069 is the protocol through which you can provision and reconfigure device completely using ACS server. 30:19.010 --> 30:24.220 And here is a user I am sorry. 30:24.750 --> 30:26.670 Here is a user manual. 30:26.910 --> 30:41.150 That user manual tells us that firmware of device is upgradable, device have a password management, device have a local and remote syslog, device is having auto provisioning using PFTP, HTTP and HTTPS. 30:41.290 --> 30:43.970 And also multi-user level. 30:43.970 --> 30:52.370 So, if owner of device have changed the password from device to admin, admin to admin, admin at 1, 2, 3. 30:52.370 --> 31:02.690 Still, though it's upgradable, still there could be a multiple users like support, like tech, this kind of user you may find generally inside the product. 31:02.690 --> 31:05.210 And their password will be same as the username. 31:05.210 --> 31:10.070 So, this you can identify from the manual itself. 31:10.330 --> 31:13.690 Now, this is one algorithm. 31:14.230 --> 31:19.030 Algorithms, reviewing algorithms is one of the most critical part in IoT. 31:19.030 --> 31:22.630 You may be thinking what we have to do with an algorithm. 31:22.750 --> 31:29.170 So, the practical example for this is, let's say vendor X have decided to produce a router. 31:29.250 --> 31:42.510 So, as per the standard or minimal requirement, all routers Wi-Fi SSID should be unique or Wi-Fi SSID should be random or at least the password to connect that SSID should be random. 31:43.050 --> 31:47.470 So, how you think that for 1 crore devices how you are going to do a password? 31:47.470 --> 31:49.590 You are going to write a C program for that? 31:49.590 --> 31:49.990 No. 31:49.990 --> 31:50.710 Right. 31:50.730 --> 31:57.610 Or even if you write, so you are going to maintain the unique password for every device with you? 31:57.610 --> 31:58.110 No. 31:58.110 --> 31:58.770 Right. 31:58.770 --> 32:03.870 So, what you are doing here is you are using one algorithm to generate a SSID password. 32:03.870 --> 32:18.070 So, basically first 4 digits of your MAC address and last 4 digits of your last 4 digits of your serial number plus current date and time could be a password for SSID. 32:18.070 --> 32:32.130 So, if you search for the Belkin password generation hack password generation algorithm hack, you may come up with a, you may get what I am trying to say here. 32:32.130 --> 32:43.350 So, if they design the poor algorithm just by adding first 4 digits of MAC address last 4 digits of serial number, anyone can generate a password for any device. 32:43.350 --> 32:43.970 Right. 32:44.030 --> 32:46.130 Or MAC address plus date on time. 32:46.130 --> 33:08.430 So, like you know that if vendor X is generating a password based on MAC address and date on time, so what you do is you set a packet capture, you capture a beacon, you get that MAC address first 4 digits and you add a current DDMM format and connect with the password to the SSID if the SSID is on default password. 33:08.430 --> 33:09.030 Right. 33:09.370 --> 33:18.190 So, to ensure that they are not doing such a silly mistake, we have to review the algorithm and lastly, the magic number. 33:18.670 --> 33:20.170 So, what the magic number is? 33:20.170 --> 33:23.310 You know, you found some fault in your device. 33:23.310 --> 33:40.170 For example, set-top box or for example, in any of your device, let's say router, if you are a non-techy guy, you take that router hey man, this router is not working, it's not showing up you take that router to the respective service center. 33:40.170 --> 33:49.050 That service center guy connects to the router and enters some code and in 15 minutes, he will give you that sir, it is working again. 33:49.050 --> 33:51.230 So, how you think it is possible? 33:51.450 --> 34:07.210 So, every device have some specific additional access mode that we called a, what we called it developer mode or debugger mode or engineer mode. 34:07.210 --> 34:13.310 So, to access those modes, you need to enter some secret code which is also generated by algorithm. 34:13.310 --> 34:16.410 So, it calls a magic number generation algorithm. 34:16.410 --> 34:34.230 So, you have to review it like there was one USB which was supporting which is locked to support with specific ISPX for internet provide for internet providing and let's then, you want to unlock it and you want to use it over other network. 34:34.230 --> 34:35.990 So, how you can do it? 34:36.530 --> 34:56.290 You access the engineering mode of that device, you remove that restriction may be a PLM unlock is there, may be some MCC MNC code or white listed inside that device or it could be a single like only name of ISP is written there to latch on this network only if you find. 34:56.290 --> 34:57.910 So, you can easily modify. 34:57.910 --> 35:02.450 So, to access this additional modes, you need this magic number. 35:02.450 --> 35:07.190 So, magic number generation logic should be tough to identify. 35:07.190 --> 35:11.170 Otherwise, once this logic is leaked, you are over. 35:12.070 --> 35:19.270 Now, this is the most interesting aspect of the commentary. 35:20.290 --> 35:22.650 Credentials to access the device. 35:22.770 --> 35:24.170 Here, you can see funny part. 35:24.170 --> 35:27.490 Default PC port connection type is bridge. 35:27.490 --> 35:28.970 Ok, that's fine. 35:28.970 --> 35:34.350 Default username for user mode is admin Sorry, for admin mode, it's admin. 35:34.350 --> 35:35.630 Ok, that's ok. 35:35.630 --> 35:38.430 Default username for user mode is user. 35:38.430 --> 35:40.170 Default password for web is null. 35:40.170 --> 35:40.990 Wow! 35:40.990 --> 35:49.810 Like they set up a complete web UI they set up a user, they set up a password policy and now they are setting password to null. 35:50.010 --> 35:53.430 That means all you need to do is you have to identify the IP address. 35:53.430 --> 35:58.950 Once you identify the IP address, you type admin, you are admin, you type a user and you are a user. 35:58.950 --> 36:00.070 Isn't it so funny? 36:00.690 --> 36:02.970 And here is the default web login port. 36:02.970 --> 36:05.750 So, they are giving you everything in their documents . 36:05.930 --> 36:07.850 So, you should review those documents. 36:07.850 --> 36:11.390 You should search for the word like ENC. 36:11.390 --> 36:14.370 So, if there is an encryption logic, it will pop up. 36:14.370 --> 36:17.650 You should search for the word SECU like secure. 36:17.650 --> 36:24.410 So, security related stuff is there it will pop up because sometimes user manual is of 400 to 500 pages. 36:24.630 --> 36:34.310 To quickly review it as if you are a device tester, you may get limited time of 5 to 10 days to complete one device, a security test. 36:34.310 --> 36:38.230 So, in that case, you need to follow such kind of tricks. 36:39.850 --> 36:42.750 Now, active recon of the device. 36:42.750 --> 36:47.550 So, active recon here is not just the identifying open port. 36:47.550 --> 36:55.930 But when it comes to open port, you should do a port scan of all ports for device because they always use non-standard port. 36:55.930 --> 36:58.150 Here is one device which I scanned. 36:58.150 --> 36:59.710 This was the IP address of it. 36:59.710 --> 37:07.350 On 2017, I did scan on this device Monday and I found this port was open 1380. 37:07.350 --> 37:14.490 After reversing that binary which was associated to this port, I was able to perform a remote code execution on this device. 37:14.530 --> 37:15.970 And this is an end user device. 37:15.970 --> 37:17.910 So, multiple users are having access. 37:17.910 --> 37:26.230 So, I could have executed a code on maybe 70,000 people in a city. 37:26.390 --> 37:31.290 Same way, I discovered this crash on 4046 port. 37:31.290 --> 37:41.990 So, if I fired one command on random IP addresses, wherever it connects to 4046, those devices will get crashed and I could cause a disruptive denial of service attack. 37:41.990 --> 37:50.050 And this was also an interesting crash I identified on 415654 after reversing that binary. 37:50.050 --> 37:52.450 Oh, I forgot to hide this MAC address. 37:52.450 --> 37:53.250 That's ok. 37:54.230 --> 37:56.930 So, this is an active recon. 37:56.930 --> 37:59.930 But, we don't stop here for recognition. 38:00.190 --> 38:04.730 We have to identify what is the underlying OS of this device. 38:05.450 --> 38:09.290 So, let's say you saw a fine working Android TV. 38:09.290 --> 38:11.630 So, you know that underlying OS is Android. 38:11.630 --> 38:13.190 Now, what about IP phone? 38:13.190 --> 38:15.110 What do you think IP phone is running? 38:15.890 --> 38:21.590 IP phone, most of the run, mostly all of this embedded device runs on a Linux. 38:21.810 --> 38:26.310 And they use BusyBox as a kernel and BusyBox to save the space. 38:26.310 --> 38:30.910 Because, as I told you, we have a very short space associated with it. 38:31.290 --> 38:38.210 So, to save space, we have these embedded devices uses BusyBox. 38:38.350 --> 38:41.010 And why BusyBox is false in a recon? 38:41.010 --> 38:43.310 Because BusyBox itself has some vulnerabilities. 38:43.750 --> 38:47.810 So, if you search a CV details for BusyBox, you may end up with a vulnerability. 38:48.010 --> 38:55.970 And underlying operating system will tell you what are the vulnerabilities are associated with that operating system. 38:55.970 --> 39:09.050 So, basically, if the device is using Linux kernel of version 2.10 to 2.15, then in this 5 versions, there could be lots of vulnerabilities which you can exploit later. 39:09.050 --> 39:25.130 So, identifying underlying operating system, identifying BusyBox version, identifying all open ports, TCP, UDP, and apart from this, what we can do is like accessible locations. 39:25.130 --> 39:34.410 Like, let's say, if root console is running without password, with the UART, all you need is to connect one cable using UART to USB converter. 39:34.650 --> 39:38.830 So, this is an active recon for embedded devices. 39:39.490 --> 39:46.270 Now, we will touch base some more aspects of recon in our upcoming training. 39:47.710 --> 40:00.170 Now, the great part of device testing is when you are testing device as a white box approach, you may get with a firmware. 40:00.170 --> 40:03.350 So, there are two types of firmware basically. 40:03.430 --> 40:06.430 Encrypted firmware and Compressed firmware. 40:06.530 --> 40:21.450 So, agenda for this firmware analysis talk is to identify what is firmware, obtaining firmware, ways to obtain the firmware, unpacking firmware, and finding vulnerability inside the firmware. 40:21.970 --> 40:30.090 So, here the best part of device testing, if you are doing a white box, then you get a firmware. 40:30.110 --> 40:41.690 So, that will help you identifying the directories or entry points or network services running on it using the firmware itself. 40:41.690 --> 40:49.550 So, you don't have to do just a brute force using FFUF or you don't have to do a content discovery in a very large way. 40:49.550 --> 40:53.610 Like , you have to perform analysis here, not a content discovery. 40:53.610 --> 41:01.350 So, that section, it really skip from recon and here you if this is a white box testing. 41:01.550 --> 41:03.450 So, what is the firmware? 41:03.450 --> 41:12.970 Firmware is the file which contains a file system of device, a kernel for the device and a bootloader. 41:13.090 --> 41:16.810 And this firmware are of two types. 41:16.810 --> 41:20.950 One is a full firmware, second is a delta firmware. 41:20.950 --> 41:25.450 So, let's say you are using a mobile, like I am using a Samsung mobile. 41:25.450 --> 41:31.470 So, you are using a Samsung firmware version 1.1. 41:31.470 --> 41:36.970 Now, there was a issue when you open a dialer, it gets crashed. 41:36.970 --> 41:40.170 So, this is a small issue, maybe developer messed it somewhere. 41:40.210 --> 41:42.770 Now , Samsung want to send a update. 41:42.770 --> 41:49.110 So, do you think Samsung is going to send you a 3 GB update for complete operating system for one small patch? 41:49.110 --> 41:49.710 No. 41:49.710 --> 41:57.490 What they will do is they perform the respective changes at file system layer if it's a file system level. 41:57.490 --> 42:04.070 Then that delta part they will calculate of KBs and MBs and that will ship to your device. 42:04.070 --> 42:06.030 So, that is called a partial update. 42:06.030 --> 42:07.850 So, that is a delta firmware. 42:07.850 --> 42:14.270 And that firmware you receive over the air to your handset for update perspective. 42:14.310 --> 42:14.970 Ok. 42:15.990 --> 42:19.730 So, these are the types of firmware. 42:19.730 --> 42:24.910 Now, what are the ways to obtain the firmware? 42:25.030 --> 42:28.250 So, here are few ways I listed down. 42:28.250 --> 42:31.690 We are going to touch base on more ways in our training. 42:31.810 --> 42:34.630 So, first is downloading from the website. 42:34.630 --> 42:37.550 Like here you can see the firmware is listed on their website. 42:37.550 --> 42:41.130 You can click on download, you will get a complete firmware. 42:41.290 --> 42:45.830 Second is like you set up a bridge like this is your device. 42:46.090 --> 42:49.210 This is the LAN card of your PC. 42:49.330 --> 42:51.210 This is your additional LAN card. 42:51.210 --> 42:55.330 You set up a bridge connection and this is your ISP cable. 42:55.330 --> 42:58.350 Now, on device end, click on check for update. 42:58.350 --> 43:04.310 If there is a firmware available, start Wireshark capture here on your bridge and click on download. 43:04.310 --> 43:05.530 So, what happens? 43:06.190 --> 43:12.790 That capture will get stopped here and you can download the firmware from the update. 43:12.790 --> 43:14.590 Now, extracting for a device. 43:14.590 --> 43:25.330 I told you like some device don't have literally any way to connect with a JTAG and you can dump the firmware using JTAG. 43:25.330 --> 43:26.750 Then, Google Docs. 43:26.750 --> 43:32.390 So, like if you search index of or FTP of a product name, you may come with a firmware. 43:32.390 --> 43:34.430 And lastly, analyzing device traffic. 43:34.430 --> 43:46.290 So, believe me, some devices most of the devices which we use like smart watch or mobile phone gets a silent update. 43:46.370 --> 43:57.050 So, what that silent update is, device is checking periodically whether the firmware update is available or not with the respective vendor. 43:57.170 --> 44:03.510 So, let's say it on one fine night device checks for the update. 44:03.510 --> 44:06.590 Now, that update requires restart and device is restarted. 44:06.590 --> 44:13.730 So, I woke up with my phone and saying why my phone is restarted as it was charged full. 44:13.730 --> 44:14.390 How? 44:14.390 --> 44:17.330 So, these are the tricks that vendor push the firmware silently. 44:17.330 --> 44:19.030 That is called silent update. 44:19.030 --> 44:24.350 So, to obtain such kind of update, you need to keep eye on device traffic. 44:24.350 --> 44:41.510 So, basically, you can set up one interception server itself so that all the devices which are at your home are connected to that interception server and that server is downloading everything from you can have a track of all the things that is getting downloaded at your home. 44:41.510 --> 44:42.430 Ok. 44:43.050 --> 44:44.650 Now, you got a firmware. 44:44.650 --> 44:45.850 What now? 44:45.910 --> 44:49.070 So, everyone knows that binwalk-e can extract the firmware. 44:49.070 --> 44:49.790 No. 44:49.790 --> 44:54.410 That is the most inappropriate approach to extract the firmware. 44:54.410 --> 44:57.950 First thing you should do is an entropy analysis. 44:58.130 --> 45:02.890 So, some firmwares are compressed and some firmwares are encrypted. 45:02.890 --> 45:06.910 So, if you run a binwalk on encrypted firmware, it will create a garbage. 45:06.910 --> 45:12.530 It may literally fill your GBs and TBs of data with garbage and you will get nothing. 45:12.530 --> 45:20.490 So, first proper way is to perform an entropy analysis on firmware with binwalk-E. 45:20.690 --> 45:22.970 It will generate a graph like this. 45:22.970 --> 45:27.190 As you can see here, a line is completely on the one. 45:27.190 --> 45:30.130 That means the firmware is very nicely encrypted. 45:30.130 --> 45:34.070 But here you can see some part is here is not encrypted. 45:34.070 --> 45:35.230 So, now what? 45:35.230 --> 45:47.310 Now, we can run a DD on this part and we can download this particular information to our device and we see what is there present. 45:47.310 --> 45:58.970 So, believe me, once I found the private key to decrypt that firmware in this part, once I found the password, so that is a fun to identify the firmware entropy. 45:59.310 --> 46:02.830 And with that password, I was able to open that firmware. 46:02.830 --> 46:09.210 Now, sometimes in hexdump only you will see the password of firmware. 46:09.750 --> 46:11.330 It happens to me. 46:11.330 --> 46:14.590 And then you can perform a signature analysis. 46:14.690 --> 46:22.310 So, if you are able to perform a signature analysis, you may come up with knowing which type of file system are in use. 46:22.310 --> 46:24.950 So, like in Windows, we have FAT and TFS. 46:24.950 --> 46:29.410 In Linux, we have XT, XT1234 and Razer FS. 46:29.590 --> 46:36.410 And same way, in device you may never find this FAT and XT4. 46:36.410 --> 46:47.210 You will find operative file system like cramfs, ubfs, squashfs squashfs is majorly I have seen till now and yzfs. 46:47.210 --> 46:52.810 So, these are the very small file systems are in use because due to the restriction of space. 46:52.810 --> 46:53.670 Ok. 46:54.170 --> 46:59.970 Now, once you are able to extract the file system from the firmware. 47:00.150 --> 47:01.830 Now, what to look inside it. 47:01.830 --> 47:02.030 Right. 47:02.030 --> 47:06.810 We are going to touch base details aspect of this in our tomorrow's training. 47:06.970 --> 47:11.150 But, as of now, what are the most critical aspect that you should look. 47:11.150 --> 47:18.750 First, obviously a passwd file to get a credentials and decode that hash to login inside the device. 47:18.870 --> 47:21.370 Second, you should look for the document root. 47:21.370 --> 47:23.110 So, what are the web pages are there. 47:23.110 --> 47:26.110 Some hidden pages which is not listed in GUI. 47:26.110 --> 47:34.230 Those hidden pages may use to access a device core functionality or execute a root level command. 47:34.270 --> 47:43.490 Then, as I told you in this application binary and the docu application logic is built inside the web binary. 47:43.490 --> 47:51.610 So, that binary should be downloaded and reverse engineer for the purpose of identifying vulnerability. 47:51.610 --> 47:55.990 And lastly, this is the first command which I run on firmware. 47:56.030 --> 48:03.030 Find slash name dot sh with type of file and having permission 777. 48:03.070 --> 48:07.830 So, this is the most important aspect. 48:07.930 --> 48:18.090 As you can see there are cron jobs running with a root and that was a shell script and it was having a permission of 777. 48:18.230 --> 48:19.250 What you want? 48:19.250 --> 48:20.370 You are root now. 48:20.370 --> 48:30.270 You can edit that shell script put add user command and once that script is run by cron you get a add user. 48:30.270 --> 48:33.490 Your user is added so you can backdoor that device. 48:33.490 --> 48:39.290 Or as it is 777 and having SS type so you can execute it yourself. 48:39.290 --> 48:40.010 Right. 48:40.070 --> 48:45.030 So, this kind of interesting stuff you can look what are the shell script files are there. 48:45.030 --> 48:47.790 You can look up for their email addresses. 48:47.790 --> 48:51.230 We are taking this in a little deeper manner in tomorrow's training. 48:51.970 --> 48:56.230 So, these are the crucial part of firmware you should look for. 48:57.010 --> 49:05.150 Now, here in document root you may ended up a source code review of a web application completely. 49:05.150 --> 49:14.590 And in application binary itself also you can review a source code review of the application binary to execute a command from a web interface. 49:14.590 --> 49:16.790 Now, getting hands dirty. 49:17.290 --> 49:19.990 First thing is like obvious. 49:19.990 --> 49:22.130 You are running a port scan. 49:22.130 --> 49:29.110 So, once you remember we conducted a document review where we found a default credential is admin. 49:29.150 --> 49:33.490 Now, I ran a port scan on this one fine device. 49:33.490 --> 49:34.730 One fine IP phone. 49:34.730 --> 49:36.210 It was an IP phone. 49:36.210 --> 49:38.570 And I found that telnet was open. 49:38.630 --> 49:42.730 And simply connecting to telnet and running admin admin. 49:42.730 --> 49:44.150 I got this. 49:45.750 --> 49:49.170 Here you can see UID 0, JID 0. 49:49.290 --> 49:53.410 We got a root over this device just by typing admin admin. 49:53.450 --> 49:57.450 Now, we see that ATN 443 is running also. 49:57.450 --> 49:59.870 As we know that web server is running on document. 49:59.870 --> 50:06.730 I found this two new ports from port scan that 7547 is there and 53 is filtered on the device. 50:06.730 --> 50:11.130 So, generally this device don't have a capacity to host a DNS server. 50:11.130 --> 50:14.890 So, they use a very fine utility called DNS mask. 50:14.890 --> 50:19.910 Almost in every device you find a DNS mask which is running on a port 53. 50:19.910 --> 50:24.270 That DNS mask itself acts as a DHCP server also in device. 50:24.990 --> 50:28.810 And I found one new port that is called 7547 port. 50:28.810 --> 50:36.230 So, after studying a lot I come to know that that is a CWMPC port which was doing a device management on 7547. 50:36.230 --> 50:40.210 And here you can see operating system is Linux kernel 2.6. 50:40.210 --> 50:45.490 Just Google about Linux kernel 2.6 exploit. 50:45.970 --> 50:52.650 I believe you may find a 5 to 6 pages of CVE details with the exploit available on the device. 50:52.650 --> 50:57.770 And here is a specific version 2.6.17 to 2.6.36. 50:57.770 --> 51:01.650 So, you may find more critical vulnerability. 51:01.650 --> 51:04.770 And now you have a deeper angle and you have deeper aspects. 51:04.770 --> 51:10.370 So, all you need is to look into 17 to 18 exploits. 51:10.370 --> 51:14.590 Like 18 versions and exploit for that 18 version only. 51:14.590 --> 51:23.910 So, you may use it for a remote code execution if exploit is supporting RC or you may end up with a privileged escalation vulnerability. 51:24.990 --> 51:31.610 Now , obviously, as we seen in a port scan, the device is running web server. 51:31.610 --> 51:34.950 I connected to that device and found this index.asp. 51:34.950 --> 51:36.690 I entered username and password. 51:36.690 --> 51:40.490 Here you can see username is travelling and password is travelling. 51:40.490 --> 51:41.610 But what? 51:41.930 --> 51:44.670 I think something is missing here. 51:44.910 --> 51:46.650 So, what is missing? 51:46.730 --> 51:50.510 That missing part is nothing but a XFrame option header. 51:50.510 --> 51:54.030 Now, you are thinking why I am making a critical issue. 51:54.030 --> 51:56.550 Why I am asking this as a critical issue. 51:56.550 --> 51:58.910 I will tell you in a next slide. 51:59.470 --> 52:03.150 But keep in mind that we have no XFrame option here. 52:03.150 --> 52:07.230 So, that means these devices are vulnerable for click jacking vulnerability. 52:07.590 --> 52:23.390 Then after further accessing or after further obtaining view from this device, I got to this one request that this one request could manage a complete device. 52:23.430 --> 52:29.390 So, I can, with this one request, I can manipulate every parameter of device. 52:29.390 --> 52:43.310 Here you can see user type is admin, username is admin, admin password is admin, then DBID, CLCD language is 0, management use VPN 0, remote web login is 1. 52:43.310 --> 52:46.830 That means remote web login is enabled or disabled. 52:46.830 --> 52:47.690 Ok. 52:47.810 --> 52:52.450 So, you can change it also as you have a, in one request only. 52:52.450 --> 53:06.930 Wireless access 0, LAN port is 80, DBID web port is 80, DBID web SSL port is 443 and remote web, remote legal IP is everything. 53:06.930 --> 53:11.030 So, every remote web is legal IP. 53:11.030 --> 53:18.230 Then remote telnet is 1, telnet security code and telnet, local telnet is 1, telnet port is 23. 53:18.230 --> 53:21.930 Telnet remote legal IP is 0.0.0.0. 53:21.930 --> 53:25.870 So, anything, any any 53:29.630 --> 53:35.590 any characters anyone can connect to device over a telnet. 53:35.590 --> 53:53.130 As this device is listening on 0.0.0.0 and hostname was there, radius access is there, IP for instance, log, enable, device plan So, as you can see here, everything is controlled in just one request. 53:53.130 --> 53:53.830 Ok. 53:54.430 --> 53:57.010 And can you notice something here? 53:58.050 --> 54:01.390 So, this is an interactive session, generally. 54:01.670 --> 54:06.170 I will tell you, there is no uniqueness in this request. 54:06.170 --> 54:09.530 As you can see apart from this cookies, there is no uniqueness. 54:09.530 --> 54:13.770 So, that means this device is vulnerable for request forgery also. 54:13.770 --> 54:18.870 Now, we have a click jacking vulnerability and request forgery vulnerability. 54:18.870 --> 54:21.810 So, we can do a cross-site request forgery to this device. 54:22.370 --> 54:26.010 Now, let's look at last part. 54:26.630 --> 54:45.490 Here, these devices have some one page called diagnostic to perform this kind of operation, like to ping the device or to see whether the device is properly configured in a network. 54:45.490 --> 54:50.410 So, like, you can't do the SSH to the device and ping for the device. 54:50.410 --> 54:54.170 So, these guys generally give such kind of option in web UI. 54:54.210 --> 54:56.410 And here you can see, here was a ping option. 54:56.410 --> 55:00.910 I just put a ID command in backtake and it returns me an ID. 55:01.050 --> 55:08.690 So, basically, we have a remote code execution vulnerability or say code execution vulnerabilities on the device. 55:08.730 --> 55:16.890 Now, we have a click jacking, we have a cross-site request forgery and we have a code execution. 55:17.250 --> 55:25.410 Now, if you put some logic that this is an IP phone, it is connected to the laptop. 55:25.490 --> 55:27.950 Now, laptop is directly connected to IP phone. 55:27.950 --> 55:35.150 In most of the company, wherever you see, IP phone network and laptop network are same. 55:35.150 --> 55:40.490 Generally, IP phone itself gives IP to using that cable to laptop. 55:40.490 --> 55:43.350 So, that means your laptop is reachable to IP phone. 55:43.350 --> 55:56.930 Now, let's make some fancy page to retain this organization employment you have to agree to policy. 55:56.950 --> 56:00.730 Means to continue with employment, you have to agree to those policies. 56:00.730 --> 56:08.570 If you don't want to, if you want to get terminated, you can or in case you want to leave the organization, you can click on ID security. 56:09.010 --> 56:11.970 Now, add a click jacking. 56:12.330 --> 56:18.130 Using click jacking, make a request to the IP phone with the default credential. 56:18.150 --> 56:31.250 It works most of the time and instead of that ID parameter, change that value with a call facebook.com or let's say, let's add a cron job. 56:32.210 --> 57:01.670 Let's add a cron job using command execution vulnerability like for i in 1 is to 100 do curl -ik https://facebook .com or any website for example, .com and once you once this request is fired, that bot is under your control or you can add a backdoor to the device and those will become your destructive bots. 57:01.990 --> 57:03.810 Isn't it easy? 57:03.810 --> 57:09.950 This is how we can turn a simple IP phone into a botnet . 57:11.230 --> 57:13.030 That's all. 57:13.710 --> 57:22.670 Here is the POC which I have done on my laptop and this was connected to a laptop IP phone. 57:22.670 --> 57:31.250 I just clicked on I agree and it executed ID command on the device using this simple way. 57:31.250 --> 58:00.070 Now what I need to use this I need to host this test POC to one server and all I need to do is send that server link to anyone means to send that server link to users so that once users click on that link it will create a request to device and with the CSRF and default credentials and command execution it will authenticate and execute the command. 58:01.510 --> 58:05.630 So this was all getting hands dirty with IoT. 58:05.630 --> 58:09.730 Now we will touch base upon a fuzzing reverse engineering and expert development. 58:09.730 --> 58:23.130 We have a complete one hour section in tomorrow's training or in my training at day 1 of fuzzing on this fuzzing reverse engineering and expert development. 58:23.130 --> 58:28.030 In this brief due to lack of time we are just touching base on this. 58:28.370 --> 58:32.210 So first thing is to get the shell. 58:32.210 --> 58:40.030 Before we start fuzzing or debugging we need to install the debugging tool on the device. 58:40.030 --> 58:47.890 So for that we need to get access to the root or we need at least some shell to device for testing this. 58:47.890 --> 58:55.850 Second what are the ways to obtain this shell it's like one I showed demonstrated just now with web vulnerability. 58:55.890 --> 59:05.810 Instead of id command you can execute npf and lvp on 4444 you will get bind shell to the device. 59:05.830 --> 59:07.930 Second is firmware analysis. 59:07.930 --> 59:23.010 In firmware analysis you may come up with a hardcoded account, backdoored account or you may come up with a way to execute a command some binaries might be there which is listening silently and there is some clients to connect that device. 59:23.210 --> 59:42.330 Third is document review in document dimension that in case of emergency you need to connect on this port by this way or by pressing this button multiple times you may get a shell and last default credential is always good and reverse engineering the binary. 59:42.330 --> 59:53.110 Default credential we used in earlier our telnet server and exploiting web vulnerability also we used right now and lastly reverse engineering the binary. 59:53.430 --> 01:00:02.790 So this looks complicated earlier but when I start exploring this it is not as complicated as it is. 01:00:02.790 --> 01:00:40.270 So there was one fine admin panel, I just put admin on it I intercepted this and I found this these are the request, username logoff, login time login time 0 and login value password, wrong password, password 2 is wrong password this is the input I typed here and again there is a user password is wrong password so I saw multiple fields there as a password and I decided to first make sure whenever you are fuzzing a device you should fuzz each and every request you never know when you got a surprise . 01:00:40.610 --> 01:00:43.550 Then I created this fuzz list here . 01:00:43.550 --> 01:00:58.570 A, 2 times A, 5 times A , 10 times A, 20 times A, 50 times A 100 times A, 200 times A and I loaded it into burst payload and I fired this into that. 01:00:58.570 --> 01:01:01.770 Now here you can see this is a missed part. 01:01:01.930 --> 01:01:05.330 Here you can see the responses is here but here it is missing. 01:01:05.330 --> 01:01:07.690 Again device started responding. 01:01:07.690 --> 01:01:13.430 So let's see what happened in the background here is a logoff device what you can see here. 01:01:13.430 --> 01:01:26.750 Can you see something interesting here so the boa server was running here on the then there is a extra body it got, what it got? 01:01:26.810 --> 01:01:27.530 6er. 01:01:27.530 --> 01:01:30.550 A buffer overflow here, a static buffer overflow. 01:01:30.550 --> 01:01:33.890 Dumping core and flash tmp now what? 01:01:33.890 --> 01:01:42.450 Again boa server started with a different PID 1170, 1169 and what here? 01:01:42.450 --> 01:01:59.050 Extra radiant body, again it got 6er, again dumping core and tmp now again it got crash, again it started so someone might be wondering that if we are able to crash, if the device is getting crash how this binary is getting up? 01:01:59.090 --> 01:02:13.770 It's because there are procmon kind of activities are running inside the device which will keep eyes on process like if the web interface is up or not if the SIP interface is up or not if a LAN interface is up or not. 01:02:13.770 --> 01:02:20.070 So whenever we are crashing this with our payload as you can see here here when we send 01:02:23.270 --> 01:02:48.690 5000 A's as a password to the device device get crash, again we send 10,000 A it is getting crash again we send 20,000 it is getting crash again with the 50,000 it is getting crash so this is how we are getting crashes here so first thing is once you got a server , 01:02:48.690 --> 01:03:12.970 you need to fuzz all each and every request with each and every parameters you may get a surprise anytime so this is a fuzzing with HTTP section we are doing now now you got a crash right , but you have to identify at what level device is getting crash so here you may see when you are sending a 5000 A, 01:03:12.970 --> 01:03:34.490 the device is getting crash so what you have to do now with the MSF you have to generate a payload of 5000 and you have to copy that payload into a request and you have to send that payload to identify those offsets at which point device is getting crash to develop a successful exploit. 01:03:34.490 --> 01:03:45.430 Now how you can achieve it so first thing is as you have a root shell first thing is to grape for the process ID which process is running. 01:03:45.490 --> 01:03:48.770 Now you have to install the GDB server. 01:03:48.770 --> 01:04:12.910 We are taking this in deeper manner that how we are going to install GDB in training and you have to attach the process here with GDB now GDB is listening to this process and then you have to connect GDB we need a GDB multi architecture here to connect this and once you connected to GDB, 01:04:12.910 --> 01:04:15.090 you have to regenerate the crash. 01:04:15.090 --> 01:04:38.470 As the device is crash, you can see here the registers from GDB it's a Pond GDB I used to use here you can see from register S0 to S3 this 4 registers are in our control then here you can see T4 register and T7 register are in our control and also we have a control over return address. 01:04:38.470 --> 01:04:56.310 So once we got this much of access now you know what to do just get a dirty shell code or reverse shell or bind shell and fire it and once you fired it, you will get the device. 01:04:56.310 --> 01:05:20.970 So this is the owning the device so here is an exploit which is a simple exploit I developed here for this IP phone only here you can see username is buffer overflow and password is equal to A into 999 times, this is the padding till T4, then first register comes is T4 then again we have a T7 here, 01:05:20.970 --> 01:05:50.010 then T6 and here you can see S0 register, S1 register S2 and S3 register so all you need to do is you have to host this register here in S0 to S4 and then you have to give some padding here again till return address and some padding and then you have to call the return address and by this way you can own the device without any interaction just by knowing the IP address. 01:05:50.010 --> 01:05:54.190 All you need is IP address once you perform an extensive research to this. 01:05:54.570 --> 01:06:07.970 So as I am available with you from long time on this all, still you have a question you can mail me at incosubatme.com and you can follow me at twitter at securitibill. 01:06:07.970 --> 01:06:14.430 Thanks a lot, hope you like this talk and hope I can see you again for tomorrow's training.