[00:00.000 --> 00:03.000]  Welcome to Offensive Embedded Exploitation
[00:03.000 --> 00:07.140]  Getting Your Hands Dirty with IoT and Embedded Devices
[00:08.380 --> 00:12.180]  So, the agenda, before we start with the talk
[00:12.180 --> 00:15.180]  I would like to tell you that I am conducting a training
[00:15.180 --> 00:18.880]  I would like to thank Mr. Omer and Mr. Joseph
[00:18.880 --> 00:21.120]  for allowing me to conduct a training
[00:21.120 --> 00:23.880]  with Defcon Red Team Village, which is on Day 1
[00:23.880 --> 00:27.140]  So, I request you to, if you want
[00:27.140 --> 00:30.580]  if you like this talk, if you want to attend this in a more deeper manner
[00:30.580 --> 00:32.740]  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:39.160]  Today, we will first have an introduction to IoT
[00:39.160 --> 00:41.900]  then we will do a preparing the arsenal
[00:41.900 --> 00:44.320]  that is a setting up our requirement
[00:44.910 --> 00:47.560]  then we will have recon, then show time
[00:47.560 --> 00:51.720]  that is a firmware analysis, then getting hands dirty, dynamic testing
[00:51.720 --> 00:54.320]  and lastly we will touch base upon
[00:54.320 --> 00:57.100]  fuzzing, reverse engineering and exploit development
[00:57.100 --> 00:59.980]  So, let me introduce myself
[00:59.980 --> 01:02.020]  I am Kaustubh Padwad from India
[01:02.020 --> 01:04.760]  also known as Security Beast on Twitter
[01:04.760 --> 01:08.140]  I have dozens of exploits listed on
[01:09.260 --> 01:11.740]  GitHub and CVE details
[01:12.320 --> 01:16.440]  on IoT. Also, I am a
[01:16.440 --> 01:18.520]  security researcher at Reliance Jio
[01:18.920 --> 01:21.340]  that is Jio Platform now, Jio Platform Limited
[01:21.340 --> 01:23.880]  where we conduct device security testing
[01:23.880 --> 01:27.360]  for all of the Jio Platform devices
[01:27.360 --> 01:30.660]  Also, I am a SINAC Red Team member
[01:30.660 --> 01:33.060]  to keep myself updated and to
[01:34.260 --> 01:36.140]  hack into the toughest
[01:36.140 --> 01:39.160]  infrastructure, SINAC is a great
[01:39.160 --> 01:41.500]  learning platform and also I do bug bounty there
[01:42.130 --> 01:45.300]  and I like to share my knowledge, so I am a speaker
[01:45.300 --> 01:46.900]  I speak at conferences
[01:46.900 --> 01:50.960]  And now, it's time to get started with the
[01:50.960 --> 01:53.080]  topic. So, the
[01:54.240 --> 01:57.080]  I have classified IoT in a
[01:57.080 --> 02:00.100]  three style. One is a industry
[02:00.100 --> 02:02.900]  IoT, second a human IoT and third
[02:03.440 --> 02:06.140]  IoT for others, that is animals. So, we will
[02:06.140 --> 02:09.240]  see, I have classified here all the industry in
[02:09.240 --> 02:11.910]  this image taken from a source is mentioned
[02:12.960 --> 02:14.820]  Here, I have listed
[02:14.820 --> 02:18.020]  all the industries like manufacturing industry, smart
[02:18.020 --> 02:21.140]  government, mobile network,
[02:21.140 --> 02:23.340]  mobility and Wi-Fi, smart digital
[02:24.160 --> 02:26.860]  citizens, that is us, then open
[02:26.860 --> 02:29.940]  data, health is a key element in IoT, then
[02:29.940 --> 02:33.140]  smart agriculture and smart building
[02:33.140 --> 02:35.740]  smart transportation. So, these
[02:35.740 --> 02:39.160]  things are getting smart with the help of IoT. Major
[02:39.160 --> 02:42.060]  like, for example, a transportation
[02:42.060 --> 02:44.460]  industry, Tesla is building
[02:45.060 --> 02:48.020]  Tesla is the best example for IoT based car
[02:48.020 --> 02:51.360]  even for a logistic, IoT is getting
[02:51.360 --> 02:54.300]  used in very huge manner to track their shipments
[02:54.620 --> 02:57.440]  that to ensure the data, the packages
[02:57.440 --> 03:00.320]  which is shipping should not get tampered
[03:00.320 --> 03:03.280]  they are putting tamper detection based
[03:03.280 --> 03:06.140]  on IoT. So, it's like simply if someone
[03:06.140 --> 03:08.980]  opens the door, that means it is tampered and as the door is
[03:08.980 --> 03:11.940]  opened, that small IoT device will send
[03:11.940 --> 03:14.980]  generate an alert and send to the respective
[03:14.980 --> 03:17.980]  logistic person. Manufacturing industries are
[03:17.980 --> 03:20.460]  using IoT to improve their
[03:20.980 --> 03:23.680]  services or to improve their production
[03:23.680 --> 03:26.220]  product qualities. So, there should be
[03:27.260 --> 03:30.160]  a zero error product development, we can
[03:30.160 --> 03:33.160]  say with the manufacturing industry. And
[03:33.160 --> 03:36.000]  government, like government should implement IoT
[03:36.000 --> 03:39.240]  In my training, I have an excellent
[03:39.240 --> 03:41.800]  example, which I
[03:41.800 --> 03:44.800]  covered there in my training. So, let's assume
[03:44.800 --> 03:47.600]  that every city have a street light
[03:47.600 --> 03:50.680]  hundreds and thousands of street lights, which is running
[03:50.680 --> 03:53.560]  from night, which is running whole night.
[03:53.560 --> 03:56.760]  So, if you install one small IoT module
[03:56.760 --> 03:59.680]  of let's say $5 cost to that
[03:59.680 --> 04:02.060]  light, then
[04:02.060 --> 04:06.280]  that light will become smart and it will turn on only
[04:06.280 --> 04:09.240]  when the vehicle is passing through. And rest of the time, it
[04:09.240 --> 04:12.080]  will stay in an ideal state, let's say power off state.
[04:12.080 --> 04:15.240]  So, that $5 module can save your $500
[04:15.240 --> 04:18.640]  electricity bill for every month.
[04:18.740 --> 04:20.180]  So, it makes sense
[04:21.400 --> 04:24.060]  of using IoT in
[04:24.060 --> 04:27.200]  government covered areas
[04:27.200 --> 04:30.020]  or government entities. Mobility
[04:30.020 --> 04:33.140]  and Wi-Fi, they are key provider for the
[04:33.140 --> 04:36.420]  IoT. As I said in mobility
[04:37.260 --> 04:38.820]  as government needs
[04:38.820 --> 04:41.680]  or let's say if you want to create a IoT environment
[04:41.680 --> 04:45.300]  so, mobility is the best way. They provide us a
[04:45.300 --> 04:48.300]  NB-IoT, Narrowband IoT and
[04:48.300 --> 04:51.900]  LTE-IoT. So, these two ways they can provide
[04:51.900 --> 04:54.240]  us IoT connectivity to everywhere. Health
[04:54.240 --> 04:56.840]  is the key element. We are discussing this here.
[04:56.840 --> 04:59.980]  Agriculture, one of my friends have built
[04:59.980 --> 05:01.980]  IoT based
[05:04.420 --> 05:06.020]  water system
[05:06.020 --> 05:08.520]  to his farm. So, it detects
[05:08.520 --> 05:11.800]  soil dryness, it detects wind
[05:11.800 --> 05:14.840]  speed, it detects temperature and accordingly
[05:14.840 --> 05:17.860]  it turns on his water pump.
[05:17.860 --> 05:20.480]  So, it will automatically give water to the plants
[05:20.480 --> 05:23.760]  to his farm also.
[05:23.760 --> 05:26.900]  And smart building, there is an
[05:26.900 --> 05:29.520]  excellent example in the next slide for smart building
[05:29.520 --> 05:33.140]  and transportation as we just talked
[05:33.140 --> 05:35.800]  about Tesla. Now, in human
[05:35.800 --> 05:38.940]  IoT. So, devices are getting inside
[05:38.940 --> 05:41.740]  the body. Like for example, a pacemaker.
[05:41.740 --> 05:44.840]  Pacemaker is a medical device, medical IoT device.
[05:44.840 --> 05:47.940]  It's a really critical device
[05:47.940 --> 05:50.740]  in IoT aspect or
[05:50.740 --> 05:53.700]  in any aspect. And insulin pumps
[05:53.700 --> 05:56.280]  and these are other devices which can be
[05:56.280 --> 05:59.740]  currently using inside the body. There could be more
[05:59.740 --> 06:02.280]  but as of now I corrected this.
[06:02.600 --> 06:06.240]  Now, you can
[06:06.240 --> 06:08.680]  trigger insulin shots
[06:08.680 --> 06:11.780]  to your loved ones remotely with this insulin
[06:11.780 --> 06:14.720]  pump. You can check if
[06:14.720 --> 06:17.960]  there is a
[06:17.960 --> 06:20.900]  what we say abnormal
[06:20.900 --> 06:23.080]  behavior of heart or
[06:23.960 --> 06:26.740]  abnormal behavior inside the body. These pacemakers
[06:26.740 --> 06:29.760]  are also smart. They can send data to
[06:29.760 --> 06:32.960]  doctor that it is not behaving good
[06:32.960 --> 06:34.700]  or you can
[06:35.760 --> 06:39.040]  as we know pacemaker is a critical medical device.
[06:39.040 --> 06:41.980]  It controls your heartbeat. Now,
[06:41.980 --> 06:44.800]  why cow is here? So, IoT
[06:45.660 --> 06:47.780]  animals are getting smarter.
[06:47.780 --> 06:50.540]  So, like if your pet lost
[06:50.540 --> 06:53.600]  direction then there are some patterns which
[06:53.600 --> 06:55.980]  they triggers every time. If they feel like lost
[06:56.580 --> 06:58.620]  or if they are not
[06:58.620 --> 07:02.620]  let's say you are not with your pet a complete day and
[07:02.620 --> 07:05.740]  suddenly he developed a fever. Then what?
[07:05.740 --> 07:08.820]  So, some guys are working on the solution
[07:08.820 --> 07:11.800]  which will be a kind of belt inside their
[07:11.800 --> 07:14.920]  body or inside their neck tied to their
[07:14.920 --> 07:18.080]  neck and that belt will keep analyzing
[07:18.080 --> 07:20.980]  their behavior. Are they behaving normal?
[07:20.980 --> 07:23.920]  Are they feeling like lost? Is their
[07:23.920 --> 07:26.880]  temperature is normal? So that you can take appropriate
[07:26.880 --> 07:30.000]  care of your loved one pet and you can track
[07:30.000 --> 07:32.680]  your animals also like your pet also
[07:32.680 --> 07:34.420]  that if they are lost or
[07:34.420 --> 07:39.400]  then you can track them. So,
[07:39.400 --> 07:42.280]  IoT is a major part of our body. IoT is
[07:42.280 --> 07:45.200]  an emerging field and IoT is too much
[07:45.200 --> 07:48.380]  powerful than we imagine.
[07:48.500 --> 07:51.200]  So, with the great power, great responsibilities also
[07:51.200 --> 07:54.820]  come. That we will discuss in a further section.
[07:55.140 --> 07:57.260]  Now, let's have a look of smart
[07:57.260 --> 07:59.720]  building. How one can implement
[08:00.180 --> 08:02.720]  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:44.520]  The self-check-in machine
[08:44.520 --> 08:47.220]  like the guest mobile check-in
[08:47.220 --> 08:49.060]  like the robot service and
[08:49.060 --> 08:51.980]  Timogeneous voice spatula.
[08:51.980 --> 08:53.780]  The purpose of this kind of service and
[08:53.780 --> 08:56.260]  technology is to improve the efficiency
[08:56.260 --> 08:59.280]  of the service and the consistency of the
[08:59.280 --> 09:00.240]  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:28.650]  As you can see, a smart building
[09:29.530 --> 09:31.690]  a brilliant example of smart building
[09:31.690 --> 09:34.670]  IoT in action. So, I would definitely
[09:34.670 --> 09:38.130]  like to go there and check-in to test the services.
[09:38.550 --> 09:41.410]  So, with the great news,
[09:41.410 --> 09:43.730]  great responsibilities do come. So, what I
[09:43.730 --> 09:46.490]  think is why IoT security
[09:46.490 --> 09:50.250]  assessment or why embedded devices security assessment is important.
[09:50.250 --> 09:52.410]  I have collected some hot news.
[09:52.890 --> 09:55.790]  This is IoT hot news where
[09:55.790 --> 09:58.710]  we can see multiple threats and risks that
[09:58.710 --> 10:01.990]  currently associated with IoT. The first and most
[10:02.650 --> 10:04.610]  important risk here.
[10:04.930 --> 10:07.870]  Risk with IoT in a medical field.
[10:07.870 --> 10:09.850]  So, when I was a kid, my
[10:10.650 --> 10:13.950]  grandparents used to tell us that there is a witchcraft and
[10:13.950 --> 10:16.470]  there is a black magic kind of stuff
[10:16.470 --> 10:19.690]  which can remotely
[10:21.770 --> 10:22.370]  kill
[10:22.370 --> 10:26.050]  someone. So, I don't believe on that
[10:26.050 --> 10:28.830]  but here you can see with IoT
[10:28.830 --> 10:32.010]  you can do it. Let's say, instead of giving
[10:33.030 --> 10:34.730]  10ml pump shot, if I trigger
[10:34.730 --> 10:38.310]  100ml pump shot, then who can save you?
[10:38.310 --> 10:41.150]  Instead of setting your heart rate to the normal heart rate
[10:41.150 --> 10:43.650]  if I set it to 3000 beats per second
[10:43.650 --> 10:47.730]  you will suffer from a major cardiac arrest.
[10:48.030 --> 10:50.190]  So, as we can see
[10:50.190 --> 10:52.910]  these are inside the body and these are
[10:52.910 --> 10:55.870]  very critical devices. So, security
[10:55.870 --> 10:58.810]  assessment for these devices must be done
[10:58.810 --> 11:01.730]  in a very aggressive way.
[11:01.990 --> 11:04.930]  I believe that if such kind of devices
[11:04.930 --> 11:07.930]  are manufactured by a very renowned vendor, it should be
[11:07.930 --> 11:11.170]  tested country-wide. It should be
[11:11.170 --> 11:13.670]  offered to the expertise all across the globe
[11:13.670 --> 11:17.690]  and then you can ensure that this product is secured or not.
[11:17.690 --> 11:19.970]  Because everything has a different mindset
[11:19.970 --> 11:22.950]  to test everything. So, same way
[11:25.010 --> 11:25.690]  Now
[11:25.690 --> 11:29.190]  you brought an IoT product that is
[11:29.670 --> 11:32.110]  a surveillance robot to secure your house
[11:32.110 --> 11:35.090]  and to take care of your loved ones when you are not in
[11:35.090 --> 11:37.990]  the home. And hackers use that robot
[11:37.990 --> 11:41.150]  for spying you. Here you can see
[11:41.150 --> 11:44.310]  hackers break into a smart home, play inappropriate music
[11:44.490 --> 11:47.530]  and communicate with a resident via camera.
[11:47.530 --> 11:50.110]  It's a horrible thing. It's a scary thing.
[11:50.110 --> 11:53.510]  If someone is continuously watching you and someone is talking
[11:53.510 --> 11:57.150]  with your speakers only, how would it feel?
[11:57.150 --> 11:59.810]  Right? It's scary. Super scary.
[12:00.290 --> 12:02.170]  And this attack
[12:02.170 --> 12:05.430]  it is an industry grade attack. Someone discovered
[12:07.050 --> 12:08.670]  a remake of Mirai
[12:08.670 --> 12:11.570]  botnet. It was the OMG attack
[12:11.570 --> 12:14.190]  was discovered by Fortinet. It was the
[12:14.190 --> 12:17.030]  second Mirai. So, Mirai is the biggest
[12:17.030 --> 12:19.710]  attack, biggest IoT attack till now.
[12:19.710 --> 12:23.250]  You can read about it. It's a really interesting attack.
[12:23.590 --> 12:25.470]  This is again like
[12:25.470 --> 12:29.150]  you brought a surveillance system to watch your home
[12:29.150 --> 12:31.650]  and that surveillance system is watching
[12:32.190 --> 12:34.850]  is watched by hackers. So, this device
[12:34.850 --> 12:38.090]  was running one video talk protocol which was
[12:38.090 --> 12:41.110]  sending the audio, which was recording the audio by
[12:41.110 --> 12:44.370]  mic and sending it to the one who connects
[12:44.370 --> 12:47.550]  over video talk to the camera. It is again scary.
[12:47.550 --> 12:49.990]  Right? I believe there should be some system
[12:49.990 --> 12:53.250]  which will ensure that how this product is secure on
[12:53.250 --> 12:56.350]  scale of 10. So, it will be easy to judge
[12:56.350 --> 12:58.330]  whether we should buy it or not.
[12:58.330 --> 13:02.430]  Like a product rating, there should be a security rating
[13:02.430 --> 13:05.430]  also should be there. And this is the major threat.
[13:05.430 --> 13:08.210]  FDA recalls nearly half of million pacemakers over
[13:08.210 --> 13:12.310]  This is the really critical issue. So, as you see the
[13:12.310 --> 13:15.590]  life risk is associated with the risk of
[13:15.590 --> 13:18.370]  with the IoT devices. So, that's why the
[13:18.370 --> 13:21.510]  security assessment of such a product is
[13:21.510 --> 13:24.390]  really crucial and really important. It should be done
[13:24.390 --> 13:27.470]  right. Now, my
[13:27.470 --> 13:30.030]  case study for this is
[13:30.030 --> 13:32.430]  can this decent looking IP phone
[13:33.210 --> 13:36.130]  change into a botnet? What do you think?
[13:36.130 --> 13:39.630]  You can turn this device into a botnet?
[13:39.810 --> 13:42.330]  Most of the guys will be thinking how this
[13:42.330 --> 13:45.530]  can be possible. Or if there are experts who have already
[13:45.530 --> 13:48.550]  played with it, may know the trick what I am going to try.
[13:48.550 --> 13:51.290]  Right? Now, one day, one fine day I was
[13:51.290 --> 13:53.990]  thinking about which device should I pick up for the training
[13:53.990 --> 13:57.210]  for this product and which device should I pick
[13:57.210 --> 14:00.350]  up for the brief also. So, I was staring at IP phone
[14:00.350 --> 14:03.250]  and suddenly it comes in my mind that why not this
[14:03.250 --> 14:06.330]  IP phone only. As every corporate
[14:06.330 --> 14:09.350]  have IP phone. Right?
[14:09.350 --> 14:12.350]  So, let's say our corporate is one of the
[14:12.350 --> 14:14.910]  biggest large corporate. So, we have at least
[14:14.910 --> 14:17.590]  40,000 IP phone of same brand
[14:18.170 --> 14:21.630]  inside our office. And Mumbai is a
[14:21.630 --> 14:24.430]  corporate hub. So, I guess that
[14:24.430 --> 14:27.510]  there should be more than
[14:27.510 --> 14:30.030]  crores of IP phone will be there in Mumbai of
[14:30.030 --> 14:33.470]  same brand. I am not talking about multiple brands.
[14:33.570 --> 14:35.750]  Let's say if vendor X is producing
[14:36.310 --> 14:39.250]  X type of IP phone, that same type of IP phone
[14:39.250 --> 14:42.230]  you will find at least 1 crore IP phone in the city.
[14:42.490 --> 14:44.370]  And if you target a specific
[14:44.990 --> 14:48.230]  call center, BPO and KPO
[14:48.230 --> 14:51.450]  then their business is IP phone. Right?
[14:51.450 --> 14:54.210]  So, if you target that, you will get lots and lots
[14:54.210 --> 14:57.130]  and lots of target. So, if you are able to remotely
[14:57.130 --> 15:00.170]  compromise one IP phone, you are
[15:00.170 --> 15:03.090]  able to compromise crores of IP phone.
[15:03.090 --> 15:05.230]  At least same types of crores of IP phone
[15:06.450 --> 15:08.950]  using this technology.
[15:08.950 --> 15:11.550]  So, if you have hacked
[15:12.130 --> 15:14.910]  two organizations having 50,000
[15:14.910 --> 15:17.910]  IP phones each, that will create
[15:17.910 --> 15:21.950]  1 lakh, that creates your 1 lakh bots.
[15:22.430 --> 15:24.390]  Maybe it could take 8 days, 10 days
[15:24.390 --> 15:26.510]  15 days. But within 15 days, you will get
[15:26.510 --> 15:30.170]  1 lakh computers, 1 lakh bots.
[15:30.170 --> 15:33.630]  Basically, what IP phone is inside. It's an ARM machine
[15:33.630 --> 15:35.570]  or MIPS machine. Right?
[15:35.690 --> 15:38.810]  So, you may get 1 lakh bots
[15:38.810 --> 15:42.070]  in just 8 to 15 days. Now, let's say if you target
[15:42.070 --> 15:45.130]  complete city, you may end up
[15:45.130 --> 15:48.250]  with 50 lakhs IP phone. Right? In a city
[15:48.250 --> 15:51.250]  you will definitely get. Now, let's say
[15:51.250 --> 15:53.630]  if you target cities, multiple cities
[15:54.150 --> 15:55.850]  then you can, let's say
[15:56.850 --> 16:00.950]  India have 4 big corporate hubs. Mumbai,
[16:00.950 --> 16:03.590]  Delhi, Chennai and Bangalore.
[16:03.590 --> 16:06.190]  So, if you hack even those 4 cities, 4
[16:06.190 --> 16:09.090]  corporate hubs and Hyderabad also, sorry. So,
[16:09.090 --> 16:12.210]  these 5 cities, you may end up with at least
[16:12.210 --> 16:15.030]  5 crores IP phone.
[16:15.030 --> 16:18.150]  Now, let's assume if that 5 crore IP phone, you are
[16:18.150 --> 16:21.410]  instructing those 5 crore IP phone to make a
[16:21.410 --> 16:25.470]  10 request per second to the facebook.com
[16:25.470 --> 16:27.370]  So, 5 into 10 is 50.
[16:27.370 --> 16:30.130]  50 crore request per second to the facebook.
[16:30.130 --> 16:33.410]  You think how long it can survive?
[16:33.410 --> 16:36.510]  Let's say any big provider. Facebook, Google
[16:36.510 --> 16:39.990]  or for how long time it can hold such a load?
[16:39.990 --> 16:42.630]  Even you can increase a 10 to 20 request per second
[16:42.630 --> 16:45.810]  that is around 100 crore request per second.
[16:45.810 --> 16:48.530]  Right. 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:54.730]  Now, let's say if you target a multiple country with the same
[16:54.730 --> 16:57.690]  attack, you can create a biggest TBPS
[16:57.690 --> 16:59.730]  attack in the history.
[17:00.150 --> 17:03.750]  So, I build a case study. How can we make
[17:03.750 --> 17:04.890]  this possible?
[17:06.610 --> 17:09.150]  But before that, we need to set up our machine
[17:09.730 --> 17:11.030]  to test this.
[17:13.370 --> 17:14.430]  Most of the time
[17:14.430 --> 17:17.250]  when I give a talk to a conference
[17:17.250 --> 17:20.150]  or seminar or chapters like
[17:20.150 --> 17:22.970]  null chapters or somewhere, they ask me
[17:22.970 --> 17:25.690]  Sir, I want to start with IOT but
[17:25.690 --> 17:28.670]  I don't have enough requirement machines.
[17:29.050 --> 17:32.090]  So, this is like, you know, you need nothing
[17:32.090 --> 17:34.530]  literally nothing to set up a basic setup
[17:34.790 --> 17:38.210]  for IOT test. Here I have shortlisted to get started
[17:39.130 --> 17:42.030]  What all you need is a Linux.
[17:42.090 --> 17:45.610]  Why Linux? Because Linux is smooth with
[17:45.610 --> 17:49.290]  virtualization of ARM and MIPS devices.
[17:49.290 --> 17:51.070]  And all IOT devices binary
[17:51.070 --> 17:53.990]  not all, most of the binary work with the
[17:53.990 --> 17:56.770]  ARM technology or MIPS technology.
[17:56.770 --> 18:00.430]  So, to smoothly virtualize it, you need a Linux.
[18:00.970 --> 18:02.910]  Secondly, Linux gives you
[18:02.910 --> 18:05.630]  lowest level access to the operating system.
[18:05.630 --> 18:09.230]  So, if you connect a device to USB port
[18:09.230 --> 18:11.490]  it will definitely give you something
[18:11.490 --> 18:15.070]  like manufacturer, product ID
[18:15.070 --> 18:18.250]  vendor ID, device type ID, something it will give.
[18:18.250 --> 18:20.490]  It won't tell you like a Windows that
[18:20.490 --> 18:24.330]  unknown device. Right? That's why Linux.
[18:24.330 --> 18:27.030]  And there are more reasons which we are
[18:27.030 --> 18:30.390]  which you may get in a training section.
[18:30.950 --> 18:33.050]  This device is
[18:33.050 --> 18:35.110]  the JTAGulator.
[18:35.290 --> 18:39.010]  So, JTAG is an interface which some devices
[18:39.010 --> 18:41.430]  don't have any interface. No UART
[18:42.050 --> 18:45.030]  no console cable, no USB
[18:45.950 --> 18:48.550]  no LAN port, no WAN port
[18:48.550 --> 18:50.670]  So, in that case what you should use
[18:50.670 --> 18:53.690]  to interact with device. Right? Our target is to get
[18:53.690 --> 18:57.450]  into the device. That is our first target as an IOT guy.
[18:57.690 --> 19:00.050]  So, in that case what you can do is
[19:00.050 --> 19:02.870]  you can use JTAGulator
[19:02.870 --> 19:06.610]  to connect with the JTAG ports of the device.
[19:06.610 --> 19:09.110]  Now, you may say why not no
[19:09.110 --> 19:12.030]  JTAG in the device? Because this is
[19:12.030 --> 19:15.230]  not the case. JTAG is present in most of the devices
[19:15.230 --> 19:18.290]  because it is used for purely factory debugging
[19:18.290 --> 19:21.070]  process or factory QA process. Let's say
[19:21.070 --> 19:23.430]  device is an assembly line, it gets manufactured
[19:23.970 --> 19:26.790]  it puts a required data and now
[19:26.790 --> 19:30.330]  before going to production, device needs to run a
[19:30.330 --> 19:34.010]  QA. So, nobody is going to
[19:34.010 --> 19:36.090]  check manually that hundreds and
[19:36.090 --> 19:39.330]  lakhs and millions of devices with manually
[19:39.330 --> 19:42.370]  checking 1, 1, 1, 1 pin. No.
[19:42.370 --> 19:45.050]  What it do is, it will connect
[19:45.050 --> 19:48.650]  JTAG pins to the device and it will test all the
[19:48.650 --> 19:51.590]  functionality with their JTAG testing suite. So, JTAG
[19:51.590 --> 19:53.650]  is present. You may not find the JTAG
[19:53.650 --> 19:56.510]  pins on the device, but you will find a point
[19:56.510 --> 19:59.830]  where you can solder the pins and you can connect a JTAG
[19:59.830 --> 20:03.070]  regulator and identify the appropriate JTAG pins.
[20:03.230 --> 20:05.890]  Now, as a IoT comes in the mind
[20:05.890 --> 20:08.770]  second thing come is a wireless. IoT
[20:08.770 --> 20:11.570]  gives you a wireless freedom. So, like now
[20:11.570 --> 20:14.590]  the device with 2 sensors and 1
[20:14.590 --> 20:17.630]  server is not connected over wire. These
[20:17.630 --> 20:20.450]  will be connected with a wireless technology. For example
[20:20.450 --> 20:23.750]  our ZigBee protocol, Z-Wave
[20:23.750 --> 20:26.550]  protocol. So, to test this
[20:26.550 --> 20:29.590]  kind of protocol, we need some specific hardware
[20:29.590 --> 20:32.190]  which will identify those frequencies. So, this
[20:32.190 --> 20:35.230]  API motor is a gadget which can, which
[20:35.230 --> 20:37.790]  allow you to perform a ZigBee test like
[20:38.190 --> 20:41.590]  ZigBee packet injection, ZigBee packet replay attack.
[20:41.590 --> 20:44.270]  So, you may see building lights, these are controlled
[20:44.270 --> 20:47.210]  most of the lights are controlled by ZigBee.
[20:47.770 --> 20:51.350]  And connectors, finally. Seriously, they are life.
[20:51.990 --> 20:54.350]  Without connector, you cannot test IoT.
[20:54.350 --> 20:57.070]  We need at least 1 extra LAN card, we need
[20:57.070 --> 21:00.070]  at least 1 WAN card, we need an additional Bluetooth
[21:00.070 --> 21:03.590]  adapter, we need 1 screwdriver set,
[21:03.590 --> 21:06.270]  we need a Skira, because Skira is an all-in-one
[21:06.270 --> 21:08.290]  connector. So, instead of spending for
[21:09.830 --> 21:12.070]  individual connectors, if you can spend
[21:12.070 --> 21:15.090]  that's fine, but instead of spending on this multiple
[21:15.090 --> 21:18.110]  you can buy 1 Skira connector which supports
[21:18.110 --> 21:21.130]  GPIO communication, which supports JTAG communication,
[21:21.130 --> 21:24.090]  which supports UART communication and also
[21:24.090 --> 21:27.270]  SPI communication. So, if you buy this 1 product
[21:27.270 --> 21:29.990]  your all problems will get solved. And lastly
[21:29.990 --> 21:33.230]  to hack the radio frequencies, we need a hack RF
[21:33.230 --> 21:36.230]  device. So, this is the minimum
[21:36.230 --> 21:39.410]  thing you need to get started with a IoT test.
[21:39.410 --> 21:40.250]  Ok.
[21:41.030 --> 21:42.110]  Now,
[21:43.210 --> 21:46.690]  this is a basic setup. Now, what about advanced setup?
[21:47.690 --> 21:48.590]  This.
[21:50.510 --> 21:53.510]  You can buy endless stuff. As new
[21:53.510 --> 21:56.350]  device will come, you need to buy something.
[21:56.650 --> 21:59.850]  As new device may have
[21:59.850 --> 22:02.410]  other way to communicate, you have to build your own
[22:02.410 --> 22:05.330]  PCB boards to communicate with that device. So, there
[22:05.330 --> 22:08.210]  was 1 device which is not directly connected over
[22:08.210 --> 22:11.150]  USB, so there was a mediator chip in between.
[22:11.150 --> 22:14.150]  So, you have to connect that device to that mediator chip. That
[22:14.150 --> 22:17.130]  mediator chip was converting those signals into UART and
[22:17.130 --> 22:20.090]  then UART to USB converter and that to laptop.
[22:20.170 --> 22:23.030]  So, this was the complete setup. So, there is no limitation
[22:23.030 --> 22:26.690]  for advanced setup. 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:33.230]  What about software? Which tools are required? Are those tools
[22:33.230 --> 22:36.170]  are expensive? Are those tools are paid? Are those tools
[22:36.170 --> 22:39.570]  are really too much heavy that one cannot afford?
[22:39.570 --> 22:42.390]  No, this is not the case. This
[22:42.390 --> 22:45.410]  I called as a weapons and these are the minimal
[22:45.410 --> 22:49.070]  weapons which are needed for testing.
[22:49.110 --> 22:51.650]  One is a BinWalk. So, BinWalk is a great
[22:51.650 --> 22:54.510]  tool. You can do a firmware extraction.
[22:54.610 --> 22:57.630]  BinWalk is basically give a firmware to BinWalk. BinWalk will extract you
[22:57.630 --> 23:00.230]  if there is a uncompressed, sorry
[23:00.230 --> 23:03.510]  unencrypted firmware. Ok. We need
[23:03.670 --> 23:06.610]  a Firmadyn. So, Firmadyn is a collection of multiple
[23:06.610 --> 23:10.030]  tools. The Firmadyn consists of BinWalk, QMove
[23:10.030 --> 23:12.750]  and Postgres database and it's
[23:13.810 --> 23:14.390]  a properly
[23:16.350 --> 23:18.670]  it's a properly organized framework
[23:18.670 --> 23:21.330]  for emulating the firmware. Ok.
[23:21.410 --> 23:24.390]  So, we need a Firmadyn to emulate a device firmware
[23:24.390 --> 23:27.610]  in case you don't have a device and you have only the
[23:27.610 --> 23:29.610]  firmware and you want to test it.
[23:29.810 --> 23:34.470]  I hope everyone is familiar with it. It is the great software tool we have.
[23:34.470 --> 23:37.490]  And we need a Python because most of the tasks we have
[23:37.490 --> 23:40.430]  to do it on repeated basis. So, to automate that stuff
[23:40.430 --> 23:43.330]  Python is the great and easy to write language.
[23:43.450 --> 23:46.590]  And lastly, IDA Pro. So, if you can't
[23:46.590 --> 23:49.710]  afford IDA Pro, it's ok. You can buy IDA Community Edition
[23:49.710 --> 23:52.390]  or you can use some open source
[23:52.390 --> 23:55.290]  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:05.390]  Reverse engineering is the life and reverse engineering
[24:05.390 --> 24:08.470]  is the most important aspect of device.
[24:08.890 --> 24:11.290]  So, there are few things that comes
[24:11.290 --> 24:14.350]  in the mind when someone asks why you
[24:14.350 --> 24:17.370]  need to reverse engineer the binary. Hard-coded backdoor
[24:17.370 --> 24:20.290]  account. Some devices, recently
[24:20.290 --> 24:22.970]  when there is a news called on
[24:22.970 --> 24:25.790]  I forgot the name of that router OS
[24:25.790 --> 24:28.850]  but that router OS is having
[24:28.850 --> 24:32.230]  7 major issues was recently
[24:32.230 --> 24:35.330]  identified and most of it was a hard-coded
[24:35.330 --> 24:38.750]  backdoor account. That too listening on a WAN interface.
[24:38.750 --> 24:41.090]  So, let's say if your device is running
[24:41.310 --> 24:43.990]  a telnet on WAN interface and if there is a backdoor account, you
[24:43.990 --> 24:47.850]  never know how one can enter in your network.
[24:48.310 --> 24:50.050]  So, this is one aspect.
[24:50.050 --> 24:52.490]  Second is identifying a critical vulnerability
[24:52.490 --> 24:55.890]  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:04.890]  So, application logic and application
[25:04.890 --> 25:08.850]  code is inside the web application binary only.
[25:09.090 --> 25:10.090]  So,
[25:11.030 --> 25:13.050]  to identify that binary
[25:13.050 --> 25:16.990]  the best way is to reverse engineer that binary and get
[25:16.990 --> 25:19.890]  assembly code out of it and then perform
[25:19.890 --> 25:22.970]  assembly analysis to identify where the
[25:22.970 --> 25:24.850]  native vulnerable calls like
[25:25.830 --> 25:28.430]  sprintf or system call
[25:28.900 --> 25:31.890]  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:37.950]  Now, let's move
[25:37.950 --> 25:39.970]  towards, once you have set up everything
[25:39.970 --> 25:44.030]  we start with the first stage is always the reconnection
[25:44.030 --> 25:46.590]  of WAN testing. In IoT also
[25:46.590 --> 25:49.470]  it's not exceptional. 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 --> 25:58.150]  So, generally in
[25:58.150 --> 26:01.530]  pen testing we perform active recon first and then passive recon. Here we have
[26:01.530 --> 26:04.470]  to do reverse. Like first we have to identify, we have to do
[26:04.610 --> 26:07.670]  a passive recon. Let's say if you got one device
[26:07.670 --> 26:09.770]  for example this headset
[26:10.430 --> 26:13.450]  and now the manufacturer of this headset is
[26:13.450 --> 26:16.790]  saying that this device does not support a WiFi.
[26:16.790 --> 26:19.890]  So, how can you ensure it? Just because he said
[26:19.890 --> 26:22.830]  this doesn't support WiFi, you are going to believe that this
[26:22.830 --> 26:25.830]  doesn't support WiFi. No. You have to read
[26:25.830 --> 26:28.930]  their specifications. So, each device
[26:28.930 --> 26:31.170]  have one unique FCC ID
[26:32.090 --> 26:34.570]  and if you search that FCC ID
[26:34.570 --> 26:37.450]  into the FCC ID database, it will
[26:37.450 --> 26:40.630]  come up with all the specifications are
[26:40.630 --> 26:43.610]  exist with the device. Ok. So, sometimes
[26:43.610 --> 26:46.430]  vendor may lie to you that this functionality is not supported at
[26:46.430 --> 26:49.190]  hardware level and they can disable it. Like
[26:49.190 --> 26:52.090]  this happens with me with one product
[26:52.380 --> 26:55.690]  that vendor was saying, Sir, this device doesn't support
[26:55.690 --> 26:58.630]  WiFi. And on FCC ID device, they have
[26:58.630 --> 27:01.230]  mentioned that this device supports WiFi.
[27:01.410 --> 27:02.790]  So, we had a long debate and
[27:04.070 --> 27:07.590]  lastly I ended up with creating custom firmware
[27:07.590 --> 27:10.510]  which loads the WiFi driver. So, basically they just disabled the WiFi
[27:10.510 --> 27:13.990]  driver. That's why WiFi is not coming up of that device.
[27:13.990 --> 27:16.970]  Ok. So, first we have to do a
[27:16.970 --> 27:20.570]  FCC ID analysis. Second,
[27:20.570 --> 27:22.930]  documents. You should ask for as much
[27:22.930 --> 27:25.910]  as possible documents.
[27:25.910 --> 27:29.210]  So, like that document could be
[27:29.210 --> 27:31.990]  a security architecture document. That document
[27:32.310 --> 27:35.070]  could be a product data sheet.
[27:35.070 --> 27:37.230]  That document could be a project description sheet
[27:37.230 --> 27:40.390]  or could be a user manual of the
[27:40.390 --> 27:43.290]  product. Ok. So, these are the things
[27:43.290 --> 27:46.330]  that you should do first and then you should touch to
[27:46.330 --> 27:49.130]  the device. And then
[27:49.130 --> 27:52.270]  once you touch to the device, first thing is to know
[27:52.270 --> 27:55.290]  your device. Right. So, if
[27:55.290 --> 27:58.310]  I give you something like you have to
[27:58.310 --> 28:01.430]  test this device, what you will do?
[28:01.430 --> 28:04.530]  Like in web application, we see what technology
[28:04.530 --> 28:07.650]  it is built on, like LAMP stack is there or
[28:07.650 --> 28:11.190]  what are the directories are in use, what is the server.
[28:11.230 --> 28:13.530]  So, same way in device security testing
[28:13.530 --> 28:16.590]  or IoT pen testing, we have to identify the multiple
[28:16.590 --> 28:19.550]  entry points to the device. For example,
[28:19.710 --> 28:22.710]  a LAN port. In this device, there is a LAN
[28:22.710 --> 28:25.650]  port, there is a console port or
[28:25.650 --> 28:28.250]  there could be a WiFi this IP phone might be using
[28:28.250 --> 28:29.530]  and some
[28:29.530 --> 28:33.970]  like if device is running on Android,
[28:33.970 --> 28:38.170]  there could be a
[28:38.170 --> 28:41.030]  ADB running on it. Some
[28:41.030 --> 28:44.170]  advanced devices that I told you about Narrowband
[28:44.170 --> 28:45.790]  IoT, they could be using an
[28:46.070 --> 28:49.130]  IDD interface to communicate with the server.
[28:49.130 --> 28:52.630]  No IP network basically. No IP data delivery
[28:52.630 --> 28:55.730]  network. Ok. And
[28:55.730 --> 28:57.690]  then you can check for the UART, if
[28:57.690 --> 29:00.850]  UART is present, console port is present, if Android
[29:00.850 --> 29:03.190]  is there, then ADB is present. If
[29:03.190 --> 29:06.910]  classic ports are there, then LAN port
[29:06.910 --> 29:09.870]  is there, console port is there. So,
[29:09.870 --> 29:12.890]  first thing is to know your device. How can you interact with that device?
[29:12.890 --> 29:15.850]  How can your Linux, your pen testing machine can interact
[29:15.850 --> 29:17.930]  with the device? And once
[29:19.810 --> 29:21.710]  you know that you can interact
[29:21.710 --> 29:24.750]  with device with specific way, you should go
[29:24.750 --> 29:27.530]  through the documents. So, here are some
[29:27.530 --> 29:30.350]  glimpse that will help you in identifying
[29:30.350 --> 29:33.330]  why document review is important. So, here
[29:33.330 --> 29:36.770]  in this document, vendor is saying that this device supports
[29:36.770 --> 29:39.470]  SIP version 2 and RTP.
[29:39.470 --> 29:43.130]  That means this device does not support SIP TLS.
[29:43.130 --> 29:45.510]  SIP TLS. So, if someone
[29:45.510 --> 29:48.250]  is able to sit in the MITM
[29:48.250 --> 29:50.730]  attack, he could able to hear your
[29:51.790 --> 29:54.550]  hear your traffic, hear your call
[29:54.550 --> 29:57.930]  which you had word with. Here you can see
[29:57.930 --> 30:00.970]  this device support TR-069. So,
[30:00.970 --> 30:03.830]  most of the classic guys who is working on Windows,
[30:03.830 --> 30:06.550]  on Linux, on network pen testing are not familiar with the
[30:06.550 --> 30:09.910]  TR-069. So, TR-069 is the protocol
[30:09.910 --> 30:12.890]  through which you can provision and reconfigure device
[30:12.890 --> 30:15.210]  completely using
[30:15.730 --> 30:17.010]  ACS server.
[30:19.010 --> 30:21.150]  And here is a user
[30:21.150 --> 30:24.220]  I am sorry.
[30:24.750 --> 30:27.370]  Here is a user manual. That user
[30:27.370 --> 30:30.290]  manual tells us that firmware of device is
[30:30.290 --> 30:33.350]  upgradable, device have a password management,
[30:33.350 --> 30:36.210]  device have a local and remote syslog, device
[30:36.210 --> 30:39.190]  is having auto provisioning using PFTP,
[30:39.190 --> 30:42.430]  HTTP and HTTPS. And also
[30:42.430 --> 30:45.270]  multi-user level. So, if
[30:45.830 --> 30:48.350]  owner of device have changed the password from
[30:48.350 --> 30:51.270]  device to admin, admin to admin, admin
[30:51.270 --> 30:54.470]  at 1, 2, 3. Still, though it's upgradable,
[30:54.470 --> 30:57.610]  still there could be a multiple users like support,
[30:57.610 --> 31:00.430]  like tech, this kind of user you may find
[31:00.430 --> 31:03.410]  generally inside the product. And their password
[31:03.410 --> 31:06.450]  will be same as the username. So, this you can identify
[31:06.450 --> 31:10.070]  from the manual itself.
[31:10.330 --> 31:12.330]  Now, this is one
[31:12.330 --> 31:15.370]  algorithm. Algorithms, reviewing
[31:15.370 --> 31:18.210]  algorithms is one of the most critical part in
[31:18.210 --> 31:21.390]  IoT. You may be thinking what we have to do with
[31:21.390 --> 31:24.510]  an algorithm. So, the practical example for this
[31:24.510 --> 31:27.390]  is, let's say vendor X have decided
[31:27.390 --> 31:30.270]  to produce a router. So, as per
[31:30.270 --> 31:33.250]  the standard or minimal requirement, all routers
[31:33.250 --> 31:36.150]  Wi-Fi SSID should be unique or Wi-Fi
[31:36.150 --> 31:39.070]  SSID should be random or at least the password
[31:39.810 --> 31:42.510]  to connect that SSID should be random.
[31:43.050 --> 31:45.690]  So, how you think that for 1 crore devices
[31:45.690 --> 31:48.650]  how you are going to do a password? You are going to write a C program
[31:48.650 --> 31:51.250]  for that? No. Right. Or even
[31:51.670 --> 31:54.650]  if you write, so you are going to maintain
[31:54.650 --> 31:57.610]  the unique password for every device with you?
[31:57.610 --> 32:00.390]  No. Right. So, what you are doing here is
[32:00.390 --> 32:03.870]  you are using one algorithm to generate a SSID password.
[32:03.870 --> 32:06.650]  So, basically first 4 digits of your
[32:06.650 --> 32:09.250]  MAC address and last 4 digits of your
[32:10.330 --> 32:12.050]  last 4 digits of your
[32:12.850 --> 32:15.770]  serial number plus current date and time
[32:15.770 --> 32:18.630]  could be a password for SSID. So,
[32:18.630 --> 32:20.810]  if you search for the
[32:21.670 --> 32:23.810]  Belkin password generation hack
[32:23.810 --> 32:26.850]  password generation algorithm hack, you may
[32:27.530 --> 32:30.350]  come up with a, you may get
[32:30.350 --> 32:32.990]  what I am trying to say here. So, if
[32:32.990 --> 32:35.790]  they design the poor algorithm
[32:35.790 --> 32:39.290]  just by adding first 4 digits of MAC address
[32:39.290 --> 32:42.350]  last 4 digits of serial number, anyone can generate a password
[32:42.350 --> 32:45.130]  for any device. Right. Or MAC address plus
[32:45.130 --> 32:47.870]  date on time. So, like you know that
[32:47.870 --> 32:51.170]  if vendor X is generating a password based on MAC address
[32:51.170 --> 32:54.990]  and date on time, so what you do is you set a
[32:54.990 --> 32:57.630]  packet capture, you capture a beacon, you get
[32:57.630 --> 32:59.910]  that MAC address first 4 digits and
[32:59.910 --> 33:03.010]  you add a current DDMM format
[33:03.010 --> 33:05.850]  and connect with the password to the SSID
[33:05.850 --> 33:09.030]  if the SSID is on default password. Right.
[33:09.370 --> 33:12.090]  So, to ensure that they are not doing such a silly
[33:12.090 --> 33:14.850]  mistake, we have to review the algorithm
[33:14.850 --> 33:18.190]  and lastly, the magic number.
[33:18.670 --> 33:20.730]  So, what the magic number is? You know, you
[33:20.730 --> 33:23.910]  found some fault in your device. For example,
[33:23.910 --> 33:26.950]  set-top box or for example, in any
[33:26.950 --> 33:29.610]  of your device, let's say router, if
[33:29.610 --> 33:32.190]  you are a non-techy guy, you take that router
[33:32.900 --> 33:35.590]  hey man, this router is not working, it's not showing up
[33:35.590 --> 33:37.570]  you take that router to the
[33:38.390 --> 33:41.790]  respective service center. That service center guy connects to
[33:41.790 --> 33:44.470]  the router and enters some code
[33:45.030 --> 33:47.330]  and in 15 minutes, he will give you that
[33:47.330 --> 33:51.230]  sir, it is working again. So, how you think it is possible?
[33:51.450 --> 33:53.830]  So, every device have some specific
[33:53.830 --> 33:57.030]  additional access mode that we
[33:57.030 --> 33:59.950]  called a, what we called it
[33:59.950 --> 34:02.450]  developer mode or
[34:03.230 --> 34:05.310]  debugger mode or
[34:05.830 --> 34:08.890]  engineer mode. So, to access those modes, you
[34:08.890 --> 34:11.790]  need to enter some secret code which is also generated
[34:11.790 --> 34:14.650]  by algorithm. So, it calls a magic
[34:14.650 --> 34:17.850]  number generation algorithm. So, you have to review it like
[34:17.850 --> 34:20.570]  there was one USB which was supporting
[34:20.570 --> 34:23.530]  which is locked to support with specific
[34:23.530 --> 34:25.950]  ISPX for internet provide
[34:26.310 --> 34:28.710]  for internet providing and let's
[34:29.510 --> 34:32.570]  then, you want to unlock it and you want to use it
[34:32.570 --> 34:35.990]  over other network. So, how you can do it?
[34:36.530 --> 34:38.470]  You access the engineering
[34:38.470 --> 34:41.410]  mode of that device, you remove that restriction
[34:41.410 --> 34:44.590]  may be a PLM unlock is there, may be some MCC
[34:44.590 --> 34:47.610]  MNC code or white listed inside that device
[34:47.610 --> 34:50.250]  or it could be a single
[34:50.250 --> 34:53.730]  like only name of ISP is written there
[34:53.730 --> 34:56.710]  to latch on this network only if you find. So, you can
[34:56.710 --> 34:59.630]  easily modify. So, to access this additional
[34:59.630 --> 35:02.450]  modes, you need this magic number.
[35:02.450 --> 35:05.170]  So, magic number generation logic should be
[35:05.170 --> 35:08.610]  tough to identify. Otherwise, once this
[35:08.610 --> 35:11.170]  logic is leaked, you are over.
[35:12.070 --> 35:13.350]  Now,
[35:13.350 --> 35:17.070]  this is the most
[35:17.070 --> 35:19.270]  interesting aspect of the commentary.
[35:20.290 --> 35:22.650]  Credentials to access the device.
[35:22.770 --> 35:24.950]  Here, you can see funny part. Default PC
[35:24.950 --> 35:28.970]  port connection type is bridge. Ok, that's fine.
[35:28.970 --> 35:31.050]  Default username for user mode is admin
[35:31.690 --> 35:34.350]  Sorry, for admin mode, it's admin.
[35:34.350 --> 35:37.370]  Ok, that's ok. Default username for user mode
[35:37.370 --> 35:40.990]  is user. Default password for web is null. Wow!
[35:40.990 --> 35:43.350]  Like they set up a complete web UI
[35:43.810 --> 35:46.970]  they set up a user, they set up a password policy
[35:47.390 --> 35:49.810]  and now they are setting password to null.
[35:50.010 --> 35:52.810]  That means all you need to do is you have to identify the
[35:52.810 --> 35:55.970]  IP address. Once you identify the IP address, you type
[35:55.970 --> 35:58.950]  admin, you are admin, you type a user and you are a user.
[35:58.950 --> 36:02.290]  Isn't it so funny? And here is the default
[36:02.290 --> 36:05.430]  web login port. So, they are giving you everything in their
[36:05.430 --> 36:07.850]  documents. So, you should review those documents.
[36:07.850 --> 36:10.410]  You should search for the word like
[36:10.410 --> 36:14.370]  ENC. So, if there is an encryption logic, it will pop up.
[36:14.370 --> 36:16.530]  You should search for the word SECU
[36:16.530 --> 36:19.630]  like secure. So, security related stuff is there
[36:19.630 --> 36:22.730]  it will pop up because sometimes user manual is of 400
[36:22.730 --> 36:26.010]  to 500 pages. To quickly review it
[36:26.010 --> 36:29.110]  as if you are a device tester, you may get
[36:29.110 --> 36:31.630]  limited time of 5 to 10 days to
[36:31.630 --> 36:34.310]  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:40.970]  Now,
[36:40.970 --> 36:43.350]  active recon of the device. So,
[36:43.350 --> 36:46.470]  active recon here is not just the identifying
[36:46.470 --> 36:49.650]  open port. But when it comes to open port,
[36:49.650 --> 36:52.770]  you should do a port scan of all ports
[36:52.770 --> 36:55.930]  for device because they always use non-standard port.
[36:55.930 --> 36:58.350]  Here is one device which I scanned. This was
[36:58.350 --> 37:01.330]  the IP address of it. On 2017,
[37:01.330 --> 37:03.950]  I did scan on this device Monday
[37:03.950 --> 37:07.350]  and I found this port was open 1380.
[37:07.350 --> 37:10.390]  After reversing that binary which was associated to
[37:10.390 --> 37:13.410]  this port, I was able to perform a remote code execution on
[37:13.410 --> 37:16.210]  this device. And this is an end user device. So,
[37:16.210 --> 37:18.810]  multiple users are having access. So, I could have
[37:19.330 --> 37:21.330]  executed a code on
[37:22.870 --> 37:26.230]  maybe 70,000 people in a city.
[37:26.390 --> 37:28.330]  Same way, I discovered this
[37:28.330 --> 37:31.290]  crash on 4046 port.
[37:31.290 --> 37:34.270]  So, if I fired one command on random IP addresses,
[37:34.270 --> 37:37.310]  wherever it connects to 4046, those devices will get
[37:37.310 --> 37:40.170]  crashed and I could cause a disruptive
[37:40.170 --> 37:43.150]  denial of service attack. And this was also an
[37:43.150 --> 37:46.470]  interesting crash I identified
[37:46.470 --> 37:50.050]  on 415654 after reversing that binary.
[37:50.050 --> 37:52.450]  Oh, I forgot to hide this MAC address.
[37:52.450 --> 37:55.490]  That's ok. So,
[37:55.490 --> 37:58.550]  this is an active recon. But, we don't stop here
[37:58.550 --> 38:01.430]  for recognition. We have to identify
[38:01.430 --> 38:04.730]  what is the underlying OS of this device.
[38:05.450 --> 38:07.810]  So, let's say you saw a
[38:07.810 --> 38:10.630]  fine working Android TV. So, you know that underlying
[38:10.630 --> 38:13.370]  OS is Android. Now, what about IP phone?
[38:13.370 --> 38:16.450]  What do you think IP phone is running?
[38:16.450 --> 38:19.750]  IP phone, most of the run, mostly all of this
[38:19.750 --> 38:22.690]  embedded device runs on a Linux. And they use
[38:22.690 --> 38:25.710]  BusyBox as a kernel and BusyBox to save the
[38:25.710 --> 38:28.770]  space. Because, as I told you, we have a very short
[38:28.770 --> 38:31.830]  space associated with it. So,
[38:32.490 --> 38:34.850]  to save space, we have
[38:34.850 --> 38:38.210]  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:46.830]  So, if you search a CV details for BusyBox, you may end up with
[38:46.950 --> 38:49.630]  a vulnerability. And underlying operating system
[38:49.630 --> 38:51.530]  will tell you what are the
[38:52.550 --> 38:55.970]  vulnerabilities are associated with that operating system.
[38:55.970 --> 38:58.890]  So, basically, if the device is using
[38:58.890 --> 39:01.630]  Linux kernel of version 2.10
[39:02.490 --> 39:04.890]  to 2.15, then in this
[39:04.890 --> 39:07.750]  5 versions, there could be lots of vulnerabilities which you can
[39:07.750 --> 39:10.850]  exploit later. So, identifying underlying operating
[39:10.850 --> 39:14.510]  system, identifying BusyBox version,
[39:14.510 --> 39:16.730]  identifying all open ports, TCP,
[39:16.730 --> 39:19.970]  UDP, and apart from
[39:19.970 --> 39:21.350]  this, what we can do
[39:22.610 --> 39:25.830]  is like accessible locations. Like, let's
[39:25.830 --> 39:28.610]  say, if root console is running without
[39:28.610 --> 39:31.650]  password, with the UART, all you need is to connect one cable
[39:32.310 --> 39:34.410]  using UART to USB converter.
[39:34.650 --> 39:37.690]  So, this is an active recon for embedded
[39:37.690 --> 39:40.790]  devices. Now,
[39:40.790 --> 39:43.810]  we will touch base some more aspects of recon
[39:43.810 --> 39:46.270]  in our upcoming training.
[39:47.710 --> 39:49.270]  Now,
[39:49.780 --> 39:52.270]  the great part of device testing is
[39:52.720 --> 39:55.970]  when you are testing device as a white box
[39:55.970 --> 39:58.930]  approach, you may get
[39:58.930 --> 40:01.810]  with a firmware. So, there are two types
[40:01.810 --> 40:04.610]  of firmware basically. Encrypted firmware
[40:04.610 --> 40:06.430]  and Compressed firmware.
[40:06.530 --> 40:10.590]  So, agenda for this firmware analysis talk is
[40:10.590 --> 40:13.710]  to identify what is firmware,
[40:13.710 --> 40:16.730]  obtaining firmware, ways to obtain the firmware,
[40:16.730 --> 40:19.130]  unpacking firmware, and finding vulnerability
[40:19.130 --> 40:21.450]  inside the firmware.
[40:21.970 --> 40:25.530]  So, here the best part of
[40:25.530 --> 40:28.510]  device testing, if you are doing a white box, then you
[40:28.510 --> 40:31.690]  get a firmware. So, that will help
[40:31.690 --> 40:32.870]  you identifying
[40:32.870 --> 40:37.490]  the directories or
[40:37.490 --> 40:40.570]  entry points or network services running on it using the
[40:40.570 --> 40:43.750]  firmware itself. So, you don't have to do just a brute force
[40:43.750 --> 40:46.830]  using FFUF or you don't have to do a
[40:46.830 --> 40:49.790]  content discovery in a very large way.
[40:49.790 --> 40:53.050]  Like, you have to perform analysis here, not
[40:53.050 --> 40:56.110]  a content discovery. So, that section, it really
[40:56.110 --> 40:59.770]  skip from recon and here you
[40:59.770 --> 41:02.210]  if this is a white box testing.
[41:02.210 --> 41:04.570]  So, what is the firmware? Firmware is the file
[41:04.570 --> 41:06.870]  which contains a file system
[41:07.530 --> 41:10.650]  of device, a kernel for the
[41:10.650 --> 41:12.970]  device and a bootloader.
[41:13.090 --> 41:16.810]  And this firmware are of two types.
[41:16.810 --> 41:19.570]  One is a full firmware, second is
[41:19.750 --> 41:22.550]  a delta firmware. So, let's say you are using
[41:23.130 --> 41:25.450]  a mobile, like I am using a Samsung mobile.
[41:25.450 --> 41:28.550]  So, you are using a Samsung firmware version
[41:28.550 --> 41:31.470]  1.1.
[41:31.470 --> 41:34.170]  Now, there was a issue when you open
[41:35.050 --> 41:37.750]  a dialer, it gets crashed. So, this is a
[41:37.750 --> 41:40.490]  small issue, maybe developer messed it somewhere.
[41:40.490 --> 41:43.670]  Now, Samsung want to send a update. So, do you think
[41:43.670 --> 41:46.350]  Samsung is going to send you a 3 GB update
[41:46.350 --> 41:49.950]  for complete operating system for one small patch? No.
[41:49.950 --> 41:52.970]  What they will do is they perform
[41:52.970 --> 41:55.930]  the respective changes at file system layer
[41:55.930 --> 41:58.450]  if it's a file system level. Then that delta
[41:58.450 --> 42:01.670]  part they will calculate of KBs and MBs
[42:01.670 --> 42:04.390]  and that will ship to your device. So, that is
[42:04.390 --> 42:07.850]  called a partial update. So, that is a delta firmware.
[42:07.850 --> 42:10.630]  And that firmware you receive over the air to your
[42:10.630 --> 42:14.270]  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:22.330]  Now, what are the ways
[42:22.330 --> 42:25.490]  to obtain the firmware? So,
[42:25.490 --> 42:28.250]  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:43.870]  Second is like you set up a bridge
[42:43.870 --> 42:45.830]  like this is your device.
[42:46.090 --> 42:49.210]  This is the LAN card of your PC.
[42:49.330 --> 42:52.550]  This is your additional LAN card. You set up a bridge connection
[42:52.550 --> 42:55.330]  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:01.650]  If there is a firmware available, start Wireshark capture
[43:01.650 --> 43:04.310]  here on your bridge and click on download.
[43:04.310 --> 43:06.870]  So, what happens? That capture
[43:07.590 --> 43:10.430]  will get stopped here and you can
[43:10.430 --> 43:13.450]  download the firmware from the update. Now, extracting
[43:13.450 --> 43:16.710]  for a device. I told you like some device don't have
[43:16.710 --> 43:21.630]  literally any way to connect with a
[43:21.630 --> 43:25.330]  JTAG and you can dump the firmware using JTAG.
[43:25.330 --> 43:27.590]  Then, Google Docs. So, like if you search
[43:27.590 --> 43:30.710]  index of or FTP of a product name, you
[43:30.710 --> 43:33.430]  may come with a firmware. And lastly, analyzing
[43:33.430 --> 43:36.370]  device traffic. So, believe me, some devices
[43:37.230 --> 43:38.570]  most of the devices
[43:39.650 --> 43:42.450]  which we use like smart watch or
[43:43.110 --> 43:46.290]  mobile phone gets a silent update.
[43:46.370 --> 43:48.650]  So, what that silent update is, device
[43:48.650 --> 43:51.730]  is checking periodically whether the firmware
[43:51.730 --> 43:55.010]  update is available or not
[43:55.010 --> 43:57.970]  with the respective vendor. So,
[43:57.970 --> 44:00.530]  let's say it on one fine night
[44:01.390 --> 44:03.770]  device checks for the update. Now,
[44:03.770 --> 44:06.730]  that update requires restart and device is restarted. So,
[44:06.730 --> 44:08.750]  I woke up with my phone and saying
[44:08.750 --> 44:12.550]  why my phone is restarted as it was
[44:12.550 --> 44:15.430]  charged full. How? So, these are the tricks
[44:15.430 --> 44:19.030]  that vendor push the firmware silently. That is called silent update.
[44:19.030 --> 44:21.510]  So, to obtain such kind of update,
[44:21.510 --> 44:24.530]  you need to keep eye on device traffic. So,
[44:24.530 --> 44:27.650]  basically, you can set up one interception server itself so that
[44:27.650 --> 44:30.370]  all the devices which are at your home are
[44:30.370 --> 44:33.250]  connected to that interception server and that server is
[44:33.250 --> 44:34.850]  downloading everything from
[44:36.470 --> 44:39.570]  you can have a track of all the things that
[44:39.570 --> 44:41.510]  is getting downloaded at your home.
[44:41.510 --> 44:44.650]  Ok. Now, you got a firmware.
[44:44.650 --> 44:47.290]  What now? So, everyone knows that
[44:47.290 --> 44:50.690]  binwalk-e can extract the firmware. No. That is the most
[44:50.690 --> 44:53.690]  inappropriate approach to extract
[44:53.690 --> 44:56.290]  the firmware. First thing you should do is an
[44:56.290 --> 44:59.670]  entropy analysis. So, some firmwares are
[44:59.670 --> 45:02.890]  compressed and some firmwares are encrypted.
[45:02.890 --> 45:05.490]  So, if you run a binwalk on encrypted firmware,
[45:05.490 --> 45:08.390]  it will create a garbage. It may literally fill
[45:08.390 --> 45:11.470]  your GBs and TBs of data with garbage and you will
[45:11.470 --> 45:14.450]  get nothing. So, first proper way
[45:14.450 --> 45:17.290]  is to perform an entropy analysis on
[45:17.290 --> 45:20.490]  firmware with binwalk-E.
[45:20.690 --> 45:23.570]  It will generate a graph like this. As you can see
[45:23.570 --> 45:25.950]  here, a line is completely
[45:25.950 --> 45:29.310]  on the one. That means the firmware is very nicely
[45:29.310 --> 45:32.150]  encrypted. But here you can see some part is here
[45:32.150 --> 45:35.230]  is not encrypted. So, now what?
[45:35.230 --> 45:38.370]  Now, we can run a DD on this part
[45:38.370 --> 45:41.030]  and we can download this particular
[45:41.030 --> 45:44.390]  information to our
[45:44.390 --> 45:47.310]  device and we see what is there present.
[45:47.310 --> 45:50.070]  So, believe me, once I found the private key to
[45:50.070 --> 45:53.210]  decrypt that firmware in this part, once I
[45:53.210 --> 45:56.130]  found the password, so that is a fun
[45:56.130 --> 45:58.970]  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:05.150]  Now, sometimes
[46:05.850 --> 46:09.210]  in hexdump only you will see the password of firmware.
[46:09.750 --> 46:12.130]  It happens to me. And then
[46:12.130 --> 46:14.590]  you can perform a signature analysis.
[46:14.690 --> 46:17.970]  So, if you are able to perform a signature analysis, you may come up with
[46:17.970 --> 46:21.130]  knowing which type of file system
[46:21.130 --> 46:24.090]  are in use. So, like in Windows, we have FAT
[46:24.090 --> 46:27.110]  and TFS. In Linux, we have XT, XT1234
[46:27.110 --> 46:29.970]  and Razer FS. And
[46:29.970 --> 46:33.290]  same way, in device
[46:33.290 --> 46:36.410]  you may never find this FAT and XT4.
[46:36.410 --> 46:39.030]  You will find operative file system like
[46:39.030 --> 46:42.370]  cramfs, ubfs, squashfs
[46:42.370 --> 46:44.630]  squashfs is majorly I have seen till now
[46:44.630 --> 46:47.970]  and yzfs. So, these are the
[46:47.970 --> 46:50.430]  very small file systems are in use because
[46:50.430 --> 46:53.670]  due to the restriction of space. Ok.
[46:54.170 --> 46:57.210]  Now, once you are able
[46:57.210 --> 46:59.970]  to extract the file system from the firmware.
[47:00.150 --> 47:03.150]  Now, what to look inside it. Right. We are going to touch base
[47:03.150 --> 47:06.810]  details aspect of this in our tomorrow's training.
[47:06.970 --> 47:09.270]  But, as of now, what are the
[47:09.270 --> 47:12.050]  most critical aspect that you should look. First, obviously
[47:12.210 --> 47:14.890]  a passwd file to get a credentials and
[47:15.850 --> 47:18.750]  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:24.270]  So, what are the web pages are there. Some hidden pages which is
[47:24.270 --> 47:27.650]  not listed in GUI. Those hidden pages
[47:27.650 --> 47:30.470]  may use to access a device
[47:30.470 --> 47:33.350]  core functionality or execute a root
[47:33.350 --> 47:36.290]  level command. Then, as I told you
[47:36.290 --> 47:38.650]  in this application binary
[47:39.070 --> 47:42.150]  and the docu application logic is built inside
[47:42.150 --> 47:45.090]  the web binary. So, that binary should be
[47:45.090 --> 47:48.130]  downloaded and reverse engineer
[47:48.130 --> 47:51.610]  for the purpose of identifying vulnerability.
[47:51.610 --> 47:54.950]  And lastly, this is the first command which I run on
[47:54.950 --> 47:57.230]  firmware. Find slash name
[47:57.230 --> 48:00.630]  dot sh with type of file
[48:00.630 --> 48:03.690]  and having permission 777. So,
[48:05.270 --> 48:06.790]  this is the most important
[48:06.790 --> 48:09.750]  aspect. As you can see
[48:09.750 --> 48:12.110]  there are cron jobs running with a root
[48:13.650 --> 48:15.530]  and that was a shell script
[48:15.530 --> 48:19.250]  and it was having a permission of 777. What you want?
[48:19.250 --> 48:22.330]  You are root now. You can edit that shell script
[48:22.330 --> 48:25.470]  put add user command and once
[48:25.470 --> 48:27.750]  that script is run by cron
[48:27.750 --> 48:31.430]  you get a add user. Your user is added
[48:31.430 --> 48:34.550]  so you can backdoor that device. Or as it is 777
[48:34.550 --> 48:37.270]  and having SS type so you can
[48:37.270 --> 48:40.010]  execute it yourself. Right.
[48:40.070 --> 48:43.350]  So, this kind of interesting stuff you can look what are the shell
[48:43.350 --> 48:46.250]  script files are there. You can look up for
[48:46.250 --> 48:49.430]  their email addresses. We are taking this in a little deeper
[48:49.430 --> 48:52.470]  manner in tomorrow's training. So,
[48:52.470 --> 48:55.350]  these are the crucial part of firmware you should look
[48:55.350 --> 48:58.270]  for. Now,
[48:58.270 --> 49:01.070]  here in document root you may
[49:01.070 --> 49:04.170]  ended up a source code review of a web application
[49:04.170 --> 49:07.290]  completely. And in application binary itself also
[49:07.290 --> 49:10.090]  you can review a source code review
[49:10.090 --> 49:13.170]  of the application binary to execute a command
[49:13.170 --> 49:16.790]  from a web interface. Now, getting hands dirty.
[49:17.290 --> 49:19.070]  First thing is like
[49:19.070 --> 49:22.130]  obvious. You are running a port scan.
[49:22.130 --> 49:25.130]  So, once you remember we
[49:25.130 --> 49:28.230]  conducted a document review where we found a default credential is
[49:28.230 --> 49:31.290]  admin. Now, I ran a port scan on
[49:31.290 --> 49:34.110]  this one fine device. One fine
[49:34.110 --> 49:37.190]  IP phone. It was an IP phone. And I found that
[49:37.190 --> 49:40.210]  telnet was open. And simply connecting to
[49:40.210 --> 49:43.310]  telnet and running admin admin. I got
[49:43.310 --> 49:44.150]  this.
[49:45.750 --> 49:49.170]  Here you can see UID 0, JID 0.
[49:49.290 --> 49:52.210]  We got a root over this device just by typing
[49:52.210 --> 49:55.310]  admin admin. Now, we see that
[49:55.310 --> 49:58.130]  ATN 443 is running also. As we know that
[49:58.130 --> 50:01.350]  web server is running on document. I found this two new
[50:01.350 --> 50:04.130]  ports from port scan that 7547 is there
[50:04.130 --> 50:07.350]  and 53 is filtered on the device. So,
[50:07.350 --> 50:10.450]  generally this device don't have a capacity to host a DNS
[50:10.450 --> 50:13.550]  server. So, they use a very fine utility called
[50:13.550 --> 50:16.690]  DNS mask. Almost in every device you find
[50:16.830 --> 50:19.910]  a DNS mask which is running on a port 53.
[50:19.910 --> 50:22.550]  That DNS mask itself acts as a DHCP
[50:22.550 --> 50:25.450]  server also in device. And I
[50:25.450 --> 50:28.810]  found one new port that is called 7547 port.
[50:28.810 --> 50:31.510]  So, after studying a lot I come to know that that is
[50:31.650 --> 50:34.270]  a CWMPC port which was doing a device
[50:34.270 --> 50:37.390]  management on 7547. And here you can
[50:37.390 --> 50:40.210]  see operating system is Linux kernel 2.6.
[50:40.210 --> 50:43.210]  Just Google about Linux
[50:43.210 --> 50:45.490]  kernel 2.6 exploit.
[50:45.970 --> 50:48.950]  I believe you may find a 5 to 6 pages
[50:48.950 --> 50:52.210]  of CVE details with the exploit available on the
[50:52.210 --> 50:55.510]  device. And here is a specific version 2.6.17
[50:55.510 --> 50:58.610]  to 2.6.36. So,
[50:58.610 --> 51:00.990]  you may find more critical
[51:00.990 --> 51:03.910]  vulnerability. And now you have a deeper angle and you have
[51:03.910 --> 51:06.610]  deeper aspects. So, all you need is to look into
[51:06.610 --> 51:10.370]  17 to 18 exploits.
[51:10.370 --> 51:13.150]  Like 18 versions and exploit for that
[51:13.150 --> 51:15.130]  18 version only. So, you may
[51:15.910 --> 51:18.810]  use it for a remote code execution if exploit is
[51:18.810 --> 51:22.290]  supporting RC or you may end up with a
[51:22.290 --> 51:25.510]  privileged escalation vulnerability.
[51:25.510 --> 51:27.970]  Now, obviously, as we
[51:27.970 --> 51:30.190]  seen in a port scan, the device is running
[51:30.800 --> 51:33.770]  web server. I connected to that device and found this
[51:33.770 --> 51:37.110]  index.asp. I entered username and password. Here you can
[51:37.110 --> 51:39.890]  see username is travelling and password is
[51:39.890 --> 51:42.790]  travelling. But what? I think
[51:42.790 --> 51:46.650]  something is missing here. So, what is missing?
[51:46.730 --> 51:48.870]  That missing part is nothing but
[51:49.130 --> 51:52.010]  a XFrame option header. Now, you are thinking why
[51:52.010 --> 51:55.090]  I am making a critical issue. Why I am asking this
[51:55.090 --> 51:58.910]  as a critical issue. I will tell you in a next slide.
[51:59.470 --> 52:01.390]  But keep in mind that we have
[52:01.390 --> 52:04.370]  no XFrame option here. So, that means these devices
[52:04.370 --> 52:07.230]  are vulnerable for click jacking vulnerability.
[52:07.590 --> 52:10.270]  Then after further accessing
[52:10.270 --> 52:12.110]  or after further obtaining
[52:12.850 --> 52:15.910]  view from this device, I got to
[52:15.910 --> 52:19.150]  this one request that this one request
[52:20.770 --> 52:22.050]  could manage a
[52:22.050 --> 52:25.190]  complete device. So, I can, with this one
[52:25.190 --> 52:28.030]  request, I can manipulate every
[52:28.030 --> 52:30.230]  parameter of device. Here you can see
[52:30.230 --> 52:33.750]  user type is admin, username is admin,
[52:33.750 --> 52:36.290]  admin password is admin, then
[52:37.050 --> 52:39.530]  DBID, CLCD language is 0, management
[52:39.530 --> 52:43.310]  use VPN 0, remote web login is 1.
[52:43.310 --> 52:45.990]  That means remote web login is enabled
[52:45.990 --> 52:49.050]  or disabled. Ok. So, you can change it
[52:49.050 --> 52:52.450]  also as you have a, in one request only.
[52:52.450 --> 52:55.010]  Wireless access 0, LAN port
[52:55.010 --> 52:58.110]  is 80, DBID web port
[52:58.110 --> 53:00.710]  is 80, DBID web SSL port is
[53:00.710 --> 53:03.450]  443 and remote
[53:04.050 --> 53:06.930]  web, remote legal IP is everything.
[53:06.930 --> 53:09.950]  So, every remote web is
[53:09.950 --> 53:12.830]  legal IP. Then remote telnet is 1, telnet
[53:12.830 --> 53:15.810]  security code and telnet, local telnet
[53:15.810 --> 53:19.010]  is 1, telnet port is 23. Telnet
[53:19.010 --> 53:21.930]  remote legal IP is 0.0.0.0.
[53:21.930 --> 53:24.810]  So, anything, any
[53:25.450 --> 53:25.870]  any
[53:29.630 --> 53:31.230]  any characters
[53:31.230 --> 53:33.870]  anyone can connect
[53:33.870 --> 53:36.730]  to device over a telnet. As this device
[53:36.730 --> 53:40.070]  is listening on 0.0.0.0
[53:40.070 --> 53:42.890]  and hostname was there, radius
[53:42.890 --> 53:45.910]  access is there, IP
[53:45.910 --> 53:48.390]  for instance, log, enable, device plan
[53:48.750 --> 53:52.010]  So, as you can see here, everything is controlled in
[53:52.010 --> 53:53.830]  just one request. 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:03.470]  I will tell you, there is no
[54:03.470 --> 54:06.690]  uniqueness in this request. As you can see
[54:06.690 --> 54:09.530]  apart from this cookies, there is no uniqueness.
[54:09.530 --> 54:12.850]  So, that means this device is vulnerable for request forgery
[54:12.850 --> 54:15.570]  also. Now, we have a click jacking vulnerability
[54:15.570 --> 54:18.870]  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:24.090]  Now, let's look at
[54:24.090 --> 54:26.010]  last part.
[54:26.630 --> 54:28.670]  Here, these devices
[54:30.430 --> 54:31.790]  have some
[54:32.530 --> 54:34.410]  one page called diagnostic
[54:36.330 --> 54:38.550]  to perform this kind of
[54:38.550 --> 54:40.730]  operation, like to ping the device
[54:41.350 --> 54:44.270]  or to see whether the device is properly
[54:44.270 --> 54:48.010]  configured in a network. So, like, you can't do the SSH to the device
[54:48.010 --> 54:50.410]  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 --> 54:58.910]  I just put a ID command in backtake
[54:58.910 --> 55:03.310]  and it returns me an ID. So, basically, we have a
[55:03.310 --> 55:05.590]  remote code execution vulnerability or say
[55:05.590 --> 55:08.690]  code execution vulnerabilities on the device.
[55:08.730 --> 55:11.820]  Now, we have a click jacking,
[55:12.270 --> 55:14.350]  we have a cross-site request forgery
[55:14.350 --> 55:16.890]  and we have a code execution.
[55:17.250 --> 55:20.210]  Now, if you put some logic that
[55:20.210 --> 55:23.630]  this is an IP phone, it is connected
[55:23.630 --> 55:26.570]  to the laptop. Now, laptop is directly
[55:26.570 --> 55:29.430]  connected to IP phone. In most of the company,
[55:29.430 --> 55:32.530]  wherever you see, IP phone network and
[55:32.530 --> 55:35.690]  laptop network are same. Generally,
[55:35.690 --> 55:37.710]  IP phone itself gives IP to
[55:38.370 --> 55:41.690]  using that cable to laptop. So, that means your laptop
[55:41.690 --> 55:44.890]  is reachable to IP phone. Now, let's
[55:44.890 --> 55:47.170]  make some fancy page
[55:49.290 --> 55:50.650]  to retain
[55:50.650 --> 55:53.610]  this organization employment
[55:53.610 --> 55:56.930]  you have to agree to policy.
[55:56.950 --> 55:59.570]  Means to continue with employment, you have to agree
[55:59.570 --> 56:02.630]  to those policies. If you don't want to, if you want to
[56:02.630 --> 56:05.690]  get terminated, you can or in case you want
[56:05.690 --> 56:08.570]  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:14.750]  Using click jacking, make a request
[56:14.750 --> 56:18.130]  to the IP phone with the default credential.
[56:18.150 --> 56:20.330]  It works most of the time and
[56:20.330 --> 56:23.650]  instead of that ID parameter, change
[56:23.650 --> 56:27.230]  that value with a call facebook.com
[56:27.230 --> 56:30.330]  or let's say, let's add a
[56:30.330 --> 56:32.850]  cron job.
[56:32.850 --> 56:36.570]  Let's add a cron job using command execution vulnerability like
[56:36.570 --> 56:40.290]  for i in 1 is to 100
[56:40.290 --> 56:42.230]  do curl-ik
[56:42.830 --> 56:49.230]  https://facebook.com or any website
[56:49.230 --> 56:51.410]  for example, .com
[56:51.410 --> 56:52.150]  and once you
[56:52.150 --> 56:53.750]  once this request is fired, that bot is under your control
[56:53.750 --> 56:56.610]  or you can add a backdoor to the device
[56:57.450 --> 56:59.710]  and those will become your
[56:59.710 --> 57:02.750]  destructive bots. Isn't it
[57:02.750 --> 57:05.910]  easy? This is how we can turn a simple
[57:05.910 --> 57:09.390]  IP phone into a
[57:09.390 --> 57:12.030]  botnet.
[57:12.030 --> 57:15.170]  That's all. Here is the
[57:15.170 --> 57:18.590]  POC which I have done on my laptop
[57:18.590 --> 57:21.010]  and this was connected to a laptop
[57:21.010 --> 57:23.630]  IP phone. I just clicked on
[57:23.630 --> 57:27.610]  I agree and it executed ID command on the device
[57:29.350 --> 57:30.350]  using this
[57:30.350 --> 57:33.070]  simple way. Now what I need to use this
[57:33.070 --> 57:35.930]  I need to host this test POC to one
[57:35.930 --> 57:38.910]  server and all I need to do is send that
[57:38.910 --> 57:40.910]  server link to anyone
[57:41.720 --> 57:44.590]  means to send that server link to
[57:44.590 --> 57:48.050]  users so that once users click on that link
[57:48.050 --> 57:51.730]  it will create a request to device
[57:51.730 --> 57:54.450]  and with the CSRF and default credentials
[57:54.450 --> 57:57.530]  and command execution it will authenticate and
[57:57.530 --> 58:00.070]  execute the command.
[58:01.510 --> 58:03.350]  So this was all
[58:03.350 --> 58:06.390]  getting hands dirty with IoT. Now we will
[58:06.390 --> 58:09.730]  touch base upon a fuzzing reverse engineering and expert development.
[58:09.730 --> 58:12.330]  We have a complete one hour section
[58:12.330 --> 58:15.090]  in tomorrow's training or in
[58:15.090 --> 58:17.230]  my training at day 1
[58:18.410 --> 58:21.570]  of fuzzing on this fuzzing reverse engineering
[58:21.570 --> 58:24.910]  and expert development. In this brief due to lack of time
[58:24.910 --> 58:28.030]  we are just touching base on this.
[58:28.370 --> 58:30.590]  So first thing
[58:30.590 --> 58:33.170]  is to get the shell. Before we start fuzzing
[58:33.730 --> 58:36.490]  or debugging we need to install the
[58:36.490 --> 58:40.030]  debugging tool on the device.
[58:40.030 --> 58:42.730]  So for that we need to get access to the root
[58:42.730 --> 58:45.050]  or we need at least some shell
[58:45.530 --> 58:48.310]  to device for testing this. Second
[58:49.070 --> 58:51.610]  what are the ways to obtain this shell
[58:51.610 --> 58:54.210]  it's like one I showed demonstrated just now
[58:54.210 --> 58:57.650]  with web vulnerability. Instead of id command you can execute
[58:57.650 --> 59:00.430]  npf and lvp on 4444 you will get
[59:00.430 --> 59:01.530]  bind shell
[59:03.910 --> 59:06.590]  to the device. Second is
[59:06.590 --> 59:09.770]  firmware analysis. In firmware analysis you may come up
[59:09.770 --> 59:12.850]  with a hardcoded account, backdoored account or you may
[59:12.850 --> 59:14.570]  come up with a way to execute a command
[59:15.350 --> 59:18.830]  some binaries might be there which is listening silently
[59:18.830 --> 59:21.830]  and there is some clients to connect
[59:21.830 --> 59:24.910]  that device. Third is document review
[59:24.910 --> 59:27.650]  in document dimension that in case of
[59:27.650 --> 59:30.790]  emergency you need to connect
[59:30.790 --> 59:34.030]  on this port by this way or by pressing this
[59:34.030 --> 59:36.670]  button multiple times you may get a shell
[59:36.670 --> 59:40.150]  and last default credential is always good
[59:40.150 --> 59:42.930]  and reverse engineering the binary. Default credential
[59:42.930 --> 59:45.810]  we used in earlier our telnet server
[59:45.810 --> 59:48.810]  and exploiting web vulnerability also we used
[59:48.810 --> 59:51.730]  right now and lastly reverse engineering
[59:51.730 --> 59:54.190]  the binary. So
[59:54.190 --> 59:57.590]  this looks complicated earlier but
[59:57.590 --> 01:00:00.130]  when I start exploring this it is
[01:00:00.470 --> 01:00:03.790]  not as complicated as it is. So there was
[01:00:03.790 --> 01:00:07.110]  one fine admin panel, I just put admin on it
[01:00:07.110 --> 01:00:09.610]  I intercepted this and I found this
[01:00:10.490 --> 01:00:12.350]  these are the request, username
[01:00:12.350 --> 01:00:14.670]  logoff, login time
[01:00:14.670 --> 01:00:18.110]  login time 0 and login value
[01:00:18.570 --> 01:00:21.730]  password, wrong password, password 2 is wrong password
[01:00:21.730 --> 01:00:24.690]  this is the input I typed here and again
[01:00:24.690 --> 01:00:27.710]  there is a user password is wrong password
[01:00:27.710 --> 01:00:30.310]  so I saw multiple fields there as a password
[01:00:30.310 --> 01:00:33.470]  and I decided to first make sure
[01:00:33.470 --> 01:00:36.630]  whenever you are fuzzing a device you should fuzz each and every request
[01:00:36.630 --> 01:00:40.030]  you never know when you got a
[01:00:40.030 --> 01:00:43.170]  surprise. Then I created this fuzz list
[01:00:43.170 --> 01:00:45.730]  here. A, 2 times A, 5 times
[01:00:45.730 --> 01:00:49.050]  A, 10 times A, 20 times A, 50 times A
[01:00:49.050 --> 01:00:51.310]  100 times A, 200 times A
[01:00:51.830 --> 01:00:54.310]  and I loaded it into burst payload
[01:00:56.290 --> 01:00:57.110]  and I fired this
[01:00:57.110 --> 01:01:00.630]  into that. Now here you can see this is a
[01:01:00.630 --> 01:01:03.490]  missed part. Here you can see the responses
[01:01:03.490 --> 01:01:06.470]  is here but here it is missing. Again
[01:01:06.470 --> 01:01:09.810]  device started responding. So let's see what happened in the background
[01:01:09.810 --> 01:01:12.310]  here is a logoff device
[01:01:12.310 --> 01:01:16.150]  what you can see here. Can you see something interesting here
[01:01:16.150 --> 01:01:20.370]  so the boa server was running here
[01:01:20.370 --> 01:01:21.110]  on the
[01:01:22.010 --> 01:01:23.550]  then there is a extra body
[01:01:23.550 --> 01:01:26.750]  it got, what it got?
[01:01:26.810 --> 01:01:29.730]  6er. A buffer overflow here, a static buffer
[01:01:29.730 --> 01:01:31.970]  overflow. Dumping core and flash tmp
[01:01:32.550 --> 01:01:35.230]  now what? Again boa server started
[01:01:35.230 --> 01:01:38.430]  with a different PID
[01:01:38.430 --> 01:01:41.510]  1170, 1169 and
[01:01:41.510 --> 01:01:44.330]  what here? Extra radiant body, again it got
[01:01:44.330 --> 01:01:46.590]  6er, again dumping core and tmp
[01:01:47.490 --> 01:01:50.770]  now again it got crash, again it started
[01:01:50.770 --> 01:01:53.890]  so someone might be wondering that if we are
[01:01:53.890 --> 01:01:56.430]  able to crash, if the device is getting crash
[01:01:56.430 --> 01:01:59.690]  how this binary is getting up? It's because
[01:01:59.690 --> 01:02:03.030]  there are procmon kind of activities are running inside
[01:02:03.030 --> 01:02:05.770]  the device which will keep
[01:02:05.770 --> 01:02:08.950]  eyes on process like if the web interface is up or not
[01:02:08.950 --> 01:02:11.550]  if the SIP interface is up or not
[01:02:11.550 --> 01:02:14.710]  if a LAN interface is up or not. So whenever we are
[01:02:14.710 --> 01:02:18.050]  crashing this with our payload as you can see here
[01:02:18.050 --> 01:02:20.070]  here when we send
[01:02:23.270 --> 01:02:24.390]  5000 A's
[01:02:24.390 --> 01:02:26.930]  as a password to the device
[01:02:26.930 --> 01:02:29.170]  device get crash, again we send
[01:02:30.790 --> 01:02:32.970]  10,000 A it is getting crash
[01:02:32.970 --> 01:02:35.790]  again we send 20,000 it is getting crash
[01:02:35.790 --> 01:02:38.550]  again with the 50,000 it is getting crash
[01:02:40.810 --> 01:02:42.230]  so this is how
[01:02:42.230 --> 01:02:43.550]  we are getting crashes here
[01:02:44.310 --> 01:02:47.890]  so first thing is once you got a
[01:02:47.890 --> 01:02:50.750]  server, you need to fuzz all
[01:02:50.750 --> 01:02:53.010]  each and every request with each and every parameters
[01:02:53.550 --> 01:02:56.170]  you may get a surprise anytime
[01:02:56.170 --> 01:02:59.550]  so this is a fuzzing with HTTP section we are doing now
[01:03:01.490 --> 01:03:03.210]  now you got a crash
[01:03:03.210 --> 01:03:05.550]  right, but you have to identify
[01:03:06.610 --> 01:03:08.630]  at what level device is getting crash
[01:03:09.290 --> 01:03:11.450]  so here you may see when you are sending
[01:03:11.610 --> 01:03:14.430]  a 5000 A, the device is getting crash
[01:03:14.430 --> 01:03:17.850]  so what you have to do now with the MSF
[01:03:17.850 --> 01:03:19.930]  you have to generate a payload of 5000
[01:03:20.590 --> 01:03:23.910]  and you have to copy that payload into a
[01:03:23.910 --> 01:03:26.910]  request and you have to send that payload to identify those
[01:03:26.910 --> 01:03:28.930]  offsets
[01:03:30.810 --> 01:03:33.030]  at which point device is getting crash
[01:03:33.170 --> 01:03:37.490]  to develop a successful exploit. Now how you can achieve it
[01:03:37.490 --> 01:03:38.270]  so first thing is
[01:03:38.270 --> 01:03:39.770]  as you have a root shell
[01:03:39.770 --> 01:03:43.670]  first thing is to grape for the process ID
[01:03:43.670 --> 01:03:47.490]  which process is running. Now you have to install
[01:03:47.490 --> 01:03:50.110]  the GDB server. We are taking this in deeper manner
[01:03:50.110 --> 01:03:53.570]  that how we are going to install GDB in training
[01:03:53.570 --> 01:03:56.130]  and you have to attach the process
[01:03:56.130 --> 01:03:58.250]  here with GDB
[01:03:58.250 --> 01:04:02.230]  now GDB is listening to this process and then
[01:04:02.230 --> 01:04:04.810]  you have to connect GDB
[01:04:04.810 --> 01:04:08.810]  we need a GDB multi architecture
[01:04:08.810 --> 01:04:10.150]  here to connect this
[01:04:10.790 --> 01:04:14.070]  and once you connected to GDB, you have to regenerate
[01:04:14.070 --> 01:04:16.970]  the crash. As the device is crash, you can see
[01:04:16.970 --> 01:04:18.710]  here the registers from GDB
[01:04:19.610 --> 01:04:21.110]  it's a Pond GDB I used to use
[01:04:21.110 --> 01:04:26.610]  here you can see from register S0 to S3
[01:04:26.610 --> 01:04:28.870]  this 4 registers are in our control
[01:04:28.870 --> 01:04:30.970]  then here you can see
[01:04:30.970 --> 01:04:34.230]  T4 register and T7 register
[01:04:34.230 --> 01:04:37.070]  are in our control and also we have a control
[01:04:37.070 --> 01:04:40.270]  over return address. So once we got this much of access
[01:04:40.270 --> 01:04:42.510]  now you know what to do
[01:04:42.510 --> 01:04:46.050]  just get a dirty shell code or reverse shell
[01:04:46.050 --> 01:04:47.550]  or bind shell
[01:04:49.150 --> 01:04:50.690]  and fire it
[01:04:51.590 --> 01:04:54.590]  and once you fired it, you will get
[01:04:54.590 --> 01:04:58.370]  the device. So this is the owning the device
[01:04:58.370 --> 01:05:01.270]  so here is an exploit which is a simple exploit
[01:05:01.270 --> 01:05:04.330]  I developed here for this IP phone only
[01:05:04.330 --> 01:05:07.010]  here you can see username is buffer overflow
[01:05:07.010 --> 01:05:10.270]  and password is equal to A into
[01:05:10.270 --> 01:05:13.150]  999 times, this is the padding
[01:05:13.150 --> 01:05:16.090]  till T4, then first register comes is T4
[01:05:16.090 --> 01:05:19.790]  then again we have a
[01:05:19.790 --> 01:05:22.670]  T7 here, then T6
[01:05:22.670 --> 01:05:25.090]  and here you can see S0 register, S1 register
[01:05:25.090 --> 01:05:26.870]  S2 and S3 register
[01:05:26.870 --> 01:05:31.170]  so all you need to do is you have to host this register here
[01:05:31.170 --> 01:05:34.370]  in S0 to S4 and then you have to
[01:05:35.610 --> 01:05:37.150]  give some padding here
[01:05:37.150 --> 01:05:39.650]  again till return address and
[01:05:40.270 --> 01:05:43.030]  some padding and then you have to call the return address
[01:05:43.030 --> 01:05:46.610]  and by this way you can own the device
[01:05:46.610 --> 01:05:49.190]  without any interaction just by knowing the
[01:05:49.190 --> 01:05:51.930]  IP address. All you need is IP address once you perform
[01:05:51.930 --> 01:05:54.190]  an extensive research to this.
[01:05:54.570 --> 01:05:57.770]  So as I am available with you from long time
[01:05:57.770 --> 01:06:00.810]  on this all, still you have a question you can
[01:06:00.810 --> 01:06:03.510]  mail me at incosubatme.com
[01:06:03.510 --> 01:06:06.530]  and you can follow me at twitter
[01:06:06.530 --> 01:06:09.810]  at securitibill. Thanks a lot, hope you like this talk
[01:06:09.810 --> 01:06:12.070]  and hope I can see you again
[01:06:12.770 --> 01:06:14.430]  for tomorrow's training.