Is the Internet of Things a thrilling frontier or a ticking time bomb? Our homes are becoming smarter, but are they secure? Learn to uncover hidden vulnerabilities in devices.
Master industry-standard tools for analyzing firmware. Exploit weaknesses in critical protocols like Modbus and MQTT. And ethically test for security breaches.
This course isn't just theory. It's hands-on action. Gain the confidence to test and secure your own smart home network. Become an IoT security expert.
Crack the code. Exploit the vulnerabilities. Enroll now.
In this video, we are going to introduce Internet of Things and discuss why they are gaining so much popularity. According to the Word Economic Forum, we stand on the brink of a technological revolution that will fundamentally alter the way we live, work, and relate to one another. In its scale, scope, and complexity, the transformation will be unlike anything humankind has experienced before.
The Internet of Things is basically creating a new revolution. The human race has experienced these revolutions whenever there has been a major technological advancement. Revolutions have triggered profound changes in economic systems and social structures. First, we had the mechanical revolution in 1760s after the invention of the steam engine. In the 1870s, we had the second revolution with the introduction of electricity.
The third revolution started with computers and extends up to the incursion of the internet in our daily lives. The upcoming revolution is all about interconnectivity and the technologies like artificial intelligence, quantum computers, robotics, virtual reality, biotechnology, and most importantly, Internet of Things is driving these changes. So, what exactly is the Internet of Things? The Internet of Things is the network of physical objects or things embedded with electronics, software, sensors, and network connectivity.
which enables these objects to collect and exchange data. Multiple technologies like machine learning, artificial intelligence, real-time analytics, embedded systems, wireless sensor networks, control systems, automation and others all contribute to enabling the Internet of Things. It is also referred to as Machine-to-Machine, Skynet or Internet of Everything.
IoT itself has evolved over time. We had mobile communication and SMS in pre-internet era. With the advent of advanced communication networks, we entered in the era of internet content with resources like emails and information websites. The introduction of smart platforms gave rise to e-commerce and e-productivity services.
Then social networking websites created a web of the internet of people, and now we are looking towards machine-to-machine communication with smart devices talking to each other. We are now talking about smart homes, smart hospitals, smart highways, and smart factories with a number of intelligent sensors and devices talking to each other. Now, let us see IoT history. In the late 1970s, systems for remotely monitoring meters on the electrical grid via telephone lines were already in commercial use. In the 1990s, Advances in wireless technology allowed machine-to-machine, M2M, enterprise, and industrial solutions for equipment monitoring and operation to become widespread.
Many of these early M2M solutions, however, were based on closed-purpose built networks and proprietary or industry-specific standards, rather than on Internet Protocol, IP, based networks and Internet standards. The first internet device, an IP-enabled toaster that could be turned on and off over the internet, was featured at an internet conference in 1990. Over the next several years, other things were IP-enabled, including a soda machine at Carnegie Mellon University in the US and a coffee pot in the Trojan Room at the University of Cambridge in the UK, which remained internet-connected until 2001. The term Internet of Things, IoT, was first used in 1999 by British technology pioneer Kevin Ashton to describe a system in which objects in the physical world could be connected to the internet by sensors. Ashton was working on RFID, radio frequency identification devices, and the close association of RFID and other sensor networks with the development of the IoT concept is reflected in the name of the RFID device company that Ashton joined later in his career.
Thing magic. The number of things connected to the internet already exceeded the number of people on earth, and now we are looking at more than 50 billion IoT devices that are online. Now let us see.
Some of the advantages and applications of the internet of things. IoT devices now can be found in every walk of life. In smart cities, we can find IoT devices in road traffic for smart parking systems, management of public transport, supply chain management of utilities, street lightning systems, and many more.
We have smart IoT devices for the elderly IoT, with a built-in accelerometer that can automatically detect falls, We have medication reminder devices and GPS trackers, which allow an emergency operator to locate and provide directions to the individual. Similarly, there is now a smart fork called the Happy Fork. It is an electronic fork that helps you monitor and track your eating habits. It also alerts you with the help of indicator lights and gentle vibrations when you are eating too fast.
We have already seen smart driving cars. Similarly, we have smart parking systems which can indicate when and where is a parking space vacant. In the world of IoT, even the cows will be connected and monitored. Sensors are implanted in the ears of cattle.
This allows farmers to monitor cows'health and track their movements, ensuring a healthier, more plentiful supply of milk and meat for people to consume. On average, each cow generates about 200 MBs of information per year. The battlefield has also become smart.
The Internet of Battlefield Things is a project initiated and executed by the U.S. Army Research Laboratory that focuses on IoT to enhance the capabilities of Army soldiers. In 2017, ARL launched the Internet of Battlefield Things Collaborative Research Alliance establishing a working collaboration between industry, university, and Army researchers.
And the list goes on. In this video, we are going to look at IoT components and the basic architecture. Internet of Things, IoT devices, typically consist of several components that work together to collect, process, and transmit data.
The specific components can vary. depending on the type and purpose of the IoT device, but common elements include the thing itself, sensors, actuators, communicator, and controller module. We are going to see these components one by one. Things, in the IoT sense, can refer to a wide variety of devices, such as heart monitoring implants, biochip transponders on farm animals, electric clams in coastal waters, automobiles with built-in sensors, DNA analysis devices for environmental, food, pathogen monitoring, or field operation devices that assist firefighters in search and rescue operations.
These devices collect useful data with the help of various existing technologies and then autonomously flow the data between other devices. Sensor and actuators are the physical devices that interact with the environment. Sensors collect data, for example temperature, humidity, light, motion, while actuators perform actions based on received commands, for example turning on-off a switch, adjusting a motor. Unlocking seamless connectivity, the communicator brings devices together, bridging the gap between the physical world and the boundless capabilities of the cloud. In the realm of IoT, both wired and wireless communication play pivotal roles, but it's the wireless magic that steals the spotlight.
Embracing the power of Wi-Fi, RFID, and Bluetooth, our communicator transforms every device into a harmonious ensemble, ensuring a symphony of data exchange and collaboration. In addition to the basic components, An IoT device may consist of several interfaces for connections to other devices, both wired and wireless. There will be I.O. interfaces for sensors, interfaces for internet connectivity, memory and storage interfaces, and audio-video interfaces. Now let us look at the Internet of Things lifecycle.
There are four stages of the complete IoT lifecycle. The first step is to collect data. Then this data is communicated to a central server mostly in the cloud.
Analyses take place on the collected and correlated data, and then we take necessary action based on the results obtained after analysis. For example, for the collection of data, we have devices and sensors that collect data everywhere at your home, in your car, at the office, and in manufacturing plants. In the second step, this data is sent through the network to some destination for further processing.
The destination can be a home network, cloud server, or a private data center. In the third step, we analyze important information from the data collected by visualizing the data, building reports, filtering data, pairing it, and correlating. The last step is taking action based on data and information. These can be communication with other machines, sending a notification, SMS, email, or talking to another system.
Now, let us look at the simplest form of IoT architecture. Simply, we can define complete IoT architecture in four layers. As far as the IoT protocol stack is concerned, the first layer is the physical perception layer, which contains the actual smart things, sensors and actuators.
The challenges faced by this layer are energy consumption, security, and interoperability. The second layer is the network layer. It supports various protocols to receive sensor data and forward it to the application layer. The network layer also faces specific issues concerning scalability, network availability, power consumption, and security. The third layer is the application layer, which provides smart services to the customers and also feeds processed and aggregated data to the semantics layer.
The protocols include MTT message queuing telemetry transport, extensible messaging and presence protocol, a set of open technologies for instant messaging, AMQP, the Advanced Message Queuing Protocol and DDS, Data Distribution Service for Real-Time Systems. The challenges being faced at this layer are related to handling, storage and processing of data received from the sensors, security privacy of user information and conformity to industrial government regulations. The fourth and the last layer is Semantics, which can also be termed as a business management layer. as it manages all the activities of an IoT system.
It implies the use of cognitive technologies to provide certain high-end services such as data analysis, business intelligence, strategic decision making, and business modeling. That all for this lecture. See you in the next lecture.
In this video, we are going to look at some of the challenges in IoT security. In the IoT threat spectrum, we will discuss some common threats to IoT and various threats specific to different layers of IoT architecture. As we know, IoT is growing fast and more and more IoT devices are being connected to the Internet. As of today, 30% of all network-connected endpoints are IoT devices.
However, this is a major threat. as 90% of the IoT devices are still unencrypted. Around 57% of these devices are vulnerable to medium and high-level attacks, making these IoT devices low-hanging fruit for attackers.
Picture this. A striking 83% of medical imaging IoT devices out there are cruising on outdated and unsupported operating systems. It's like leaving the front door wide open for potential attacks. Breaking it down further, when we look at the landscape of attacks on IoT devices, it's like a playbook.
The majority involve exploiting known vulnerabilities, followed closely by the infiltration of malware. Notably, a significant 26% of incidents can be traced back to lax security practices. The generalized threats are the common attacks that can be observed in the IoT environment.
Moreover, these issues are also trivial in conventional IT systems. For example, threats to data and user security and privacy. Various attacks threaten device and software integrity. Numerous security issues in IoT communications protocols.
hardware weaknesses, DOS and DDoS attacks, and finally wireless sensors networks. WSN specific challenges. Let us see these issues one by one. Security and privacy issues. When addressing security and privacy concerns, it's crucial to safeguard both users and their data.
The significance lies in the fact that 90% of prevalent smart devices from smartphones to fitness trackers, gather personal information. The lack of transparency regarding data usage by device manufacturers and application providers leads to security and privacy issues, along with the risk of data integrity attacks. Additionally, the rise in these concerns is attributed to the absence of reliable authentication in resource-constrained IoT devices and the insufficient implementation of data confidentiality measures like encryption and robust network access controls.
Device integrity. For IoT to effectively serve critical infrastructure like smart grids, healthcare, intelligent traffic systems, smart vehicles, and smart homes, the key lies in the reliability of devices and the secure transmission of data between them. Unfortunately, IoT and devices often operate in a trustless environment devoid of physical security.
Consequently, these devices become vulnerable to various physical attacks, including invasive hardware attacks, side-channel attacks, and reverse engineering attacks. Software Integrity As IoT devices are commonly placed in public or remote areas without strong physical protection and authentication, any compromise or successful remote access poses a serious threat to the integrity of the operating system, applications, and device configuration settings. Security issues concerning software integrity stem from the absence of host-based measures, such as antivirus and software firewalls, which are essential for preventing the execution of malicious code and unauthorized remote access.
Turning our attention to security concerns and communication protocols, the primary threat involves the man-in-the-middle attacks initiated by spoofing the address resolution protocol. ARP, at the MAC layer. Moreover, security researchers have identified ongoing challenges related to cross-layer and hybrid security in wireless communication. These challenges extend into the domains of IoT and CPS. Exemplified by security breaches such as unauthorized access to a Mitsubishi vehicle through brute force hacking of the pre-shared Wi-Fi key, exfiltration of private sensitive data from a computer via a covert FM channel, and hacking of a wirelessly controlled implantable medical device.
Now, turning our attention to hardware vulnerabilities, IoT devices are commercially developed with a predominant focus on device functionality rather than security. Consequently, security features are frequently incorporated in an ad hoc manner. As a result, commercial IoT devices often retain hardware vulnerabilities including open physical interfaces and susceptibilities in the boot process that can be exploited remotely.
The dependable and secure operation of IoT systems is contingent on the integrity of the underlying devices, particularly the integrity of their code and data against malicious modifications. Another significant threat to the sustenance of IoT is the distributed denial-of-service attack that targets the availability of the device itself or certain other services, for example, due to constrained resources such as low memory, low computation power, and low battery consumption. IoT devices are vulnerable to resource exhaustion attacks.
These attacks include jamming of communication channels, extensive unauthorized or malicious utilization of critical IoT resources, such as bandwidth, memory, CPU time, disk space, and change of node configuration. All of these attacks will most likely affect the operational functionality of IoT devices and the non-availability of their services to the respective users. The analysis of past cyber incidents infer that the vulnerabilities of IoT devices make them an ideal platform to launch DDoS attacks.
It has also been disclosed by researchers that 96% of the devices involved in DDoS attacks were IoT devices, whereas 3% were home routers and 1% were compromised Linux servers. Threats specific to wireless sensor networks fall into the following categories. Interruption, for example, jamming.
Interception, for example, eavesdropping. Modification, for example, message tampering. Malicious routing.
Fabrication attacks, for example, insertion of malicious messages. Now let us see some threats at different architectural layers of IoT devices. At the physical or perception layer, Various threats are encountered, encompassing eavesdropping, battery drainage, hardware failure or exploitation, malicious data injection, Sybil attacks, device compromise, timing attacks, node cloning, semi-invasive and invasive intrusions, change of configuration, and change of firmware version. Each of these poses distinct challenges and risks. Moving beyond the physical layer, we encounter the Mac, adaptation, or network layer, where a myriad of threats unfolds.
These include unfairness and impersonation attacks, various forms of denial of service, DOES attacks such as collision attacks, channel congestion attacks, battery exhaustion attacks, and exploitation of CSMA, Carrier Sense Multiple Access. Additionally, threats extend to fragmentation attacks, man-in-the-middle, MITM, and eavesdropping attacks. spoofing, hello flood, and homing attacks, as well as message fabrication, modification, or replay attacks. The layer is susceptible to network intrusion and device compromise, often facilitated remotely through malware. Other threats involve node replication attacks, the insertion of rogue devices, and risks associated with selective forwarding, Sybil, wormhole, and black hole attacks, creating a diverse and intricate security landscape.
Moving up to the application layer, a prevailing perception suggests that security takes a backseat to efficiency and service delivery in the minds of application developers today. This mindset exposes applications to vulnerabilities, making compromise and service denial to legitimate users all too easy. The major threats at the application layer include the notorious cross-site scripting attack, where malicious links in a seemingly safe environment can be exploited by attackers. Identity theft looms as a significant risk, emphasizing the importance of securing usernames and passwords for critical services. Compromise of root passwords on laptops can lead to escalated privileges and weaken security.
Software modification threats arise when attackers gain access to IoT devices, either physically or through remote access, enabling unauthorized actions. Malicious codes, whether spreading over the Internet or through targeted malware, Exploit unique vulnerabilities in connected IoT devices. Brute force attacks take advantage of weaknesses in authentication and authorization mechanisms, potentially leading to information disclosure, privilege escalation, and data tampering.
SQL injection attacks pose a common threat to databases, allowing attackers unauthorized access to sensitive information. The aftermath of a successful attack may trigger a breach of user privacy, Exposing sensitive data like financial or insurance information, insecure APIs, whether in web or mobile applications, present vulnerabilities in the application layer, especially when weak authentication or a lack of data encryption mechanisms exist, exposing user data to unauthorized disclosure. Lastly, we have the semantics layer.
As highlighted in the beginning, the semantics layer is responsible for data analysis, business intelligence, strategic decision-making, and business modeling. Hence, lack of data security or privacy-preserving measures such as user anonymity and data encryption. Numerous issues concerning user privacy can occur.
For example, if a user's critical health data is exposed along with his identity during data analytics, and the same is accessed by a third party not authorized to know about the true identity of the user, it will have significant consequences as far as user's privacy or reputation is concerned. Now let us look at some of the threats to cloud-supported Internet of Things. Most of the IoT service providers use cloud-based architecture to collect, process, and analyze IoT data, and then provide various data analytics or business intelligence services to the users. Despite the advantages of cloud-based architectures, they come with inherent weaknesses.
Firstly, reliance on a trusted cloud service provider is crucial, as the security of the entire system is contingent on its integrity. Secondly, The vulnerability of cloud systems becomes evident in the event of a cyber attack, sabotage attempt, or technical malfunction, as the cloud becomes a single point of failure, potentially disrupting services. Furthermore, the centralized control characteristic of cloud environments makes user data susceptible to data manipulation attacks, including modification or censorship attacks.
These weaknesses underscore the importance of robust security measures. and careful consideration when opting for cloud-based solutions. In conclusion, as we navigate the vast and interconnected landscape of the Internet of Things, it becomes imperative to recognize and address the multitude of threats that loom over this transformative technology. From the physical vulnerabilities at the foundational layers, to the intricate challenges presented at the network and application levels, understanding these threats is the first step towards building resilient and secure IoT ecosystems.
As we delve into the future, let us remain vigilant, fostering a collective commitment to innovation and security to ensure the continued advancement and safe integration of IoT into our daily lives. Thank you for joining today's discussion on the critical threats facing the Internet of Things. In this video, we are going to see how we can perform Internet of Things open source intelligence.
Open Source Intelligence is the process of collecting data about targets without communicating directly with the systems. It's one of the initial steps for any assessment. You should always perform it to get the lay of the land.
For example, you might download and examine device manuals and chipset data sheets, browse online forums and social media, or interview users and technical personnel for information. One of the easiest ways to gather sensitive data about a target is through search engines, which should be your first step in gathering information. Google Dorking may help you identify important documents about an IoT device.
For example, you can try to find device manuals, which can provide a ton of information about the inner workings of devices. You can usually find them on the device vendor's official website. If that fails, Try advanced Google searches for PDF documents containing the device name. For example, you can try the Google Dorks as shown. These Dorks will help you find PDF documents related to a device.
We can try to find PDF files related to a common Wi-Fi router, and we can see download user manuals, specification documents, etc. It's surprising how much important information you can find in manuals. They can even reveal default usernames and passwords that often remain in production environments, detailed specifications of the system and its components, network and architecture diagrams, and troubleshooting sections that help identify weak spots. Similarly, you can use advanced dorking techniques to find sensitive information and login pages of industrial instrument control systems.
We can look for the text containing the datasheet related to the device as shown. We can then download the datasheet and get the relevant information. We can also search for login pages.
Here, we can see login pages of industrial instrument control systems. Now, let us see what information we can get from FCCID of a device. The Federal Communication Commission, FCC, is a general body to regulate various devices emitting radio communications, which is most IoT devices. The reason for the regulation is that the radio spectrum is limited and devices are operating at different frequencies. In case of no regulatory body, one can decide to manufacture and choose his or her device to use a frequency.
that might already be in use by another device and lead to interference in the communications of other equipment. Thus, any device that uses radio communication must go through a set of approval processes, which involves several tests, after which approval is granted by FCC for the device. The FCC ID of a device will be the same for a given model of a specific manufacturer.
You can find the FCC ID of the device either printed on the device itself or by looking online at different sources. By searching for a specific device's FCCID, you can find details on the wireless operating frequency, internal photos of the device, user manuals, and more. You may also find relevant data sheets which might lay out the chipset pins used for debugging. You can use the websites as shown. For example, let us look for information You can find its FCC ID on the bottom side of the device.
Now go over to FCCID.io and search for the FCC ID. You get the complete details of the camera. You can see the supported frequency ranges, user manuals, etc.
One of the most interesting things to look at while analyzing the FCC ID information is the internal pictures of the device. The pictures also reveal that this IP camera has a URT interface, as suggested by the four pads shown in the photo. This is also something we can use to extract firmware from the device.
Patent documents can also reveal sensitive and important information about a device. Patents can provide information about the inner workings of certain devices. Try searching for a vendor name at patents.google.com and see what comes up.
For example, the keywords Medtronic Bluetooth should pull up patents for a communication protocol between implantable medical devices. The patents will almost always contain flow diagrams that could help you when assessing the communication channel between the device and other systems. Now let us look at some IoT search engines.
Shodan is often referred to as the search engine for hackers, because it allows users to search for internet-connected devices and systems based on various criteria such as IP address, ports, banners, and more. It is commonly used for security research, and it can be used to find vulnerable devices, industrial control systems, webcams, and other internet-connected resources. Senses is another search engine that focuses on internet-wide scanning and indexing.
It provides a searchable database of information about hosts and networks on the internet. Senses is often used for security research, asset discovery, and monitoring internet-wide trends. We will be looking at Shodan and see how to do reconnaissance on IoT devices.
Shodan supports a number of query types to shortlist IoT devices on the internet based on different criteria. You can search with port number, device name, protocol name, or other headers. Once you open Shodan, you can find a cheat sheet on the homepage.
You can use this cheat sheet to search IoT devices. You can click on Explore and browse some popular IoT devices. For example, let us browse some web cameras. Let us open the first result. Surprisingly, this device has already been hacked.
We can see some credentials. We can also see the complete user account hashes. Now, let us browse some open Android IP cameras, and we have a bunch of results.
Let us see if we can view it live. And we can see the camera feed live. Similarly, we can also search for other IoT devices.
Let us search for MQTT devices. We have more than 500,000 results. You can also view more details about the results by clicking on the More button. Here, you can further filter devices. For example, we can directly search for vulnerable devices.
Here we can see a summary of devices vulnerable to a particular CVE. We can also filter devices by country with a country filter. Further, we can shortlist devices with connection code 0, which is an indication that no authentication is required to access the device. Similarly, we can search for Modbus-based devices by searching for port 502. We can search for SCADA devices in a specific country, and even if we want, we can directly search for the vendor name and shortlist devices.
Different headers can also be used for searching devices. For example, we can directly search for devices with UPnP functionality that also have an exposed web server as shown. Now let us see Scentsy's search engine. Here, also you can search with protocol names or port numbers. So, in this manner, we can use open source resources to perform OSINT for the Internet of Things.
In this video, we are going to set up IoT pen testing platform by setting up a virtual box and then setting up IoT GOAT and Kali Linux virtual machines on it. Open. VirtualBox official website.
Click on Download VirtualBox. You will be redirected to a download page. Here you can download the VirtualBox version suitable for your device.
I am going to download the Windows version. After the download is completed, open the installer. Follow the installation steps and the virtual box is installed on your device.
Now we need to download and set up IoT GOAT. Open the GitHub page for IoT GOAT. You can read the description of the project here. Click on the releases page link.
Download the VMDK image. We are going to move this image in our working directory. Open the virtual box. Click on the new icon to create a new virtual machine. Give it a name.
Select the folder for your VM. Now, select the type as Linux. and the version as Linux 2.5-3.x x32-bit system. Click on Next.
Select your hardware resources and click Next. Choose to select the existing virtual disk, navigate to your working directory, and select the IoT GOAT VMDK image that you downloaded earlier. Now click on Start.
IoT GOAT will boot up and you can see the flash screen. Now, let's set up Kali Linux. Go to kali.org website, click on Virtual Machines, and download the VirtualBox 64-bit image.
Move the downloaded VM to your working directory. The VM is compressed with 7-zip. If you do not have it, download it and install 7-zip software. Now extract the Kali Linux VM with 7-zip.
In your VirtualBox, click on the Add icon and add the downloaded Kali VM. Kali will be added to your library. Now, start the machine, and Kali will boot up. The default credentials for Kali VM are Kali and Kali. Now, we need to set up our virtual network so that the Kali VM can talk to the IoT GOAT.
So, shut down both virtual machines. In the Virtual box, go to Tools and select Network Manager. Select the NAT Networks tab. Here, you can set up your IP address range.
Ensure that DHCP is enabled and give it a name that you can remember afterward. Open Kali VM Settings, and in the Network tab, ensure that the network is selected as the NAT network that you have just created. Similarly, for IoT GOAT, select the same NAT network.
Now, boot up both machines. Once IoT GOAT boots up, you can check its IP address with ifconfig command, and you can see that it has got the IP address of 192. .168.2.4 Similarly, log on to the Kali machine and check that it has got an IP address. Now, try to ping the IoT GOAT machine from Kali VM, and you can see that we do have the connectivity.
You can now open the browser and browse to the IoT GOAT IP address. The login page will appear. So, in this manner, we have successfully established out IoT Pen Testing Lab on VirtualBox with IoT GOAT and Kali VM.
The first step in the dynamic analysis of an IoT device is scanning for vulnerable network services. We have both Kali Linux and IoT GOAT up and running. The IP address of IoT GOAT is 192.168.2.4.
We can check the IP address of our Kali Linux machine with ifconfig command, and the IP address is 192.168.2.5. Let us first check the connectivity with IoT GOAT with the ping command, and we do have the connectivity. Let us first do a TCP SYN scan.
The"-p-flag scans all six 5535 ports, and the"-ss-flag specifies the stealth scan."-ox-flax is being used to write scanning results to a file. We have used the"-t-4 flag for aggressive scanning to speed up the process. It will take a few minutes, and a list of open ports will be revealed. Here we can see a few unknown ports, like port 5515 and 65534 which are worth checking. Similarly, we can scan for UDP ports with dash SU flag and we have a few UDP ports open as well, like port 53 for DNS and port 1900 for UPNP.
After we have found the open ports, The next step is to get services information that are running on these ports. We can repeat the scan with the"-SV flag for service enumeration and"-SC to run default NMAP scripts that scan for common vulnerabilities against the target. We can specify the ports manually by the"-P flag and here we have detailed information about the services that are running on these ports. We can see that SSH service is using DropBear, and DNS mask 2.73 is running on port 53. Similarly, we can see detailed information about each service. For port 5515, we can see that it is a backdoor, and Nmap has been able to successfully connect with it during the scan. We can also see Telnet running on port 65534. Similarly, we can conduct a UDP service enumeration scan. The UDP service scan is going to take a lot of time, and here we can see detailed information about services running on UDP ports. We can see the detailed information about the DNS server and UPNP service details. We can also run some service-specific NMAP scripts to get more information about a service. For example, let us use the broadcast UPnP info script, and here we can see very detailed information about the UPnP service running on the host. So, in this manner, we can conduct active reconnaissance against an IoT target and scan it for detailed information. In the last video, we performed extensive scans on our target. We saw a bunch of open ports. We also saw some potential backdoors. In this video, we are going to see how we can exploit these backdoors. So, in our scan in the last video, the backdoor appeared to be running on port 5515. Let us confirm this again by running a quick scan on the port, and we can see that the port is open. We can use a tool called NetCat to try to connect to the port and observe the response. So, Use the command nc-nv, the IP address of our target, and the port number. Here, dash n flag suppresses DNS resolution, which means that numeric IP addresses are used directly without attempting to resolve hostnames. Dash v enables verbose mode, providing more detailed information about the connection. We get connected to the target and get access. You can check the current directory by pwd command. Similarly, We can list files with ls command, we can check the current user with the id command, and we can see that we have root access on our target. The shell is not stable, and we can try to stabilize it. However, as the target does not have Python or Bash installed, we will be using a script from payload all the things that try to stabilize the shell with the inbuilt busy box. This command uses mkfifo to create a named pipe. It then establishes a connection to your machine using Netcat, sending standard input and output through the pipe. The slash bin slash sh, I command starts an interactive shell, and T is used to write the output to both the named pipe and standard output. Before entering the command, make sure to open a Netcat listener on our attacking machine with the command nc-l-p and the port number. Now enter the shell stabilizing command, and we can see that we get a shell on our Netcat listener, and we can run commands as usual on this terminal as well. We can check shell properties with the echo dollar command. The eye indicates that we have the shell in invocation mode which closely resembles an interactive shell. We have already seen that port 65534 was also open on our target. But if we try to connect to it, we cannot connect to it because it is asking for credentials which we do not have. In the next few videos, we will try to crack these credentials. I hope you are enjoying the course. See you in the next lecture. In the last video, we saw a backdoor on our IoT device at port 5515, which we were able to connect. In this video, we will see different methods to brute force login credentials. Let us quickly run an Nmap scan to see whether port 5515 is still open. The port is open, so let us connect to it with Netcat, and we are connected. We can use different commands like ls to list down the files. Now, let us see the content of our password file on our target to see the available users. And here we have a number of users. Let us copy and save the contents of this file. Similarly, cat out the contents of the shadow file. Here we have all our password hashes. Save the contents of the shadow file to a new file. We will now use the unshadow command which takes these two files as input and merges them, removing the password hashes from the etc password file and combining them with the other information from the etc shadow file. This makes it easier to manipulate and process the password hashes for password cracking using tools like John the Ripper or Hashcat. We now have our hashes in the hash.txt file. We are interested in users who have the shell enabled. So, we have the root user and the IoT goat user as our target. To crack these hashes, we will be using the Mirai Botnet word list. The list is available in SeqLists which you can install with the sudo apt install seeklists command if you do not have it. Let us check the first few entries of the word list with the head command, and the word list contains both usernames and passwords. We need only the passwords. We can use the cut command to separate the passwords from the list. So, Use the command cut"-d", with delimiter as space and"-f1", to select the first field, and pipe it to head to see if we're getting it right. So, we have the usernames. Now use the same command, use"-f2", to select the second field, and save it to a new file pass list.txt. Now check the content of the file with the head command, and we have successfully separated passwords from the list. Now let us use John to crack our password hashes. Use the command john, the hashes file, and specify the dictionary with the dash w flag, and we have successfully cracked the password of the IoT GOAT user. This method of cracking passwords works only if we have access to password hashes, which may not be possible in all cases. Now let us see some online password cracking methods. We have seen that SSH was also running on our IoT device. We can directly try to brute force the password of the service with online password cracking tools with the same password list. Let us first try Hydra. Use the command Hydra-L to specify the user. "-p", to specify the password file and the target with the protocol, we are brute forcing. Hydra gives errors due to the use of old encryption mechanisms. We can try the other tool, crackmap exec. Use the command as shown. and we have successfully cracked the password. Similarly, we can use Medusa, which is also able to crack the password. We have shown different tools, so that if you are having issues with one tool, you can still use the other one. Now let us use the cracked credentials to log on with SSH. We are getting the error as our target is using a very old encryption scheme. We can specify the encryption algorithm with our command, and we are able to connect. We have already seen that port 65534 was open, but we could not connect to it. because it was asking for credentials. Now we have the credentials and we can connect through it. So, let us try connecting to port 65534. And we have the terminal. So, in this video, we saw different methods to brute force passwords of an IoT device. IoT devices often have web interfaces to interact with. For example, In the case of a wireless router, we have a web interface to configure our router. In this video, we are going to see how web vulnerabilities affect IoT devices, and will try to find cross-site scripting vulnerabilities in the router. Cross-site scripting, XSS attacks, are a type of injection in which malicious scripts are injected into otherwise benign and trusted websites. XSS attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser-side script, to a different end-user. The end-user's browser has no way to know that the script should not be trusted and will execute the script. Because it thinks the script came from a trusted source, The malicious script can access any cookies, session tokens, or other sensitive information retained by the browser and used with that site. We are assuming that we have access to credentials and we can log into the web portal. So, login. For cross-site scripting, we are looking for some kind of input field where we can inject our JavaScript. So, browse through all links on the web portal and try to find potentially vulnerable areas. Let us try the script in Network Settings by injecting it into the new firewall rule form. Use the simple script tag and try to generate an alert. Click on Add. And here we can see the alert notification, which means the field is vulnerable to cross-site scripting. Sometimes a simple alert script may not work, we may need to get creative and use other HTML tags like image tag to test for XSS. Let us try another payload in the Wireless Settings tab. Select to change the SSID. Input your script as payload and click on Save. You can see that our payload has not worked. We can try some other script. Let us try with an image tag, which on error generates an alert. And this time we get an alert. So, in this manner, we can test for vulnerabilities in web interfaces provided by IoT devices. In this video, we are going to look into the firmware security testing methodology. Whether network-connected or standalone, firmware is the center of controlling any embedded device. It is crucial to understand how firmware can be manipulated to perform unauthorized functions and potentially cripple the supporting ecosystem's security. The firmware security testing methodology is composed of nine stages tailored to enable security researchers, software developers, hobbyists, and information security professionals to conduct firmware security assessments. The nine stages start with information gathering and end with individual exploitation of binaries. We are going to see these steps one by one. The first step is information gathering and reconnaissance. During this stage, collect as much information about the target as possible to understand its overall composition underlying technology. The information gathered may include supported CPU architectures, operating system platforms, bootloader configurations, hardware schematics and data sheets, etc. The above listed information should be gathered before security testing fieldwork via a questionnaire or intake form. Where possible, acquire data using open source intelligence. If open source software is used, download the repository and perform both manual as well as automated static analysis against the codebase. The second step is is obtaining firmware. We can attempt to obtain firmware contents using one or more of the given methods. We can directly obtain the firmware from the development team, manufacturer, vendor, or client. We can build the firmware from scratch using walkthroughs provided by the manufacturer. Sometimes we can find the firmware on the vendor's support site. Google DORC queries targeted towards binary file extensions and file sharing platforms such as Dropbox, Box, and Google Drive may also be helpful as it's common to come across firmware images through customers who upload content to forums, blogs, or comment on sites where they contacted the manufacturer to troubleshoot an issue and were given firmware via a zip or flash drive sent. We can also perform a man-in-the-middle attack during updates. Sometimes we can download builds from exposed cloud provider storage locations, such as Amazon Web Services S3 buckets. We can also try to extract firmware directly from hardware via UART and JTAG. Similarly, we can sniff serial communication within hardware components for update server requests. We can also try dumping firmware from the bootloader to flash storage or over the network via TFTP. As a last resort, we can try removing the flash chip or MCU from the board for offline analysis and data extraction. The next step is to analyze the firmware. Once the firmware image is obtained, explore aspects of the file to identify its characteristics. You can use different tools to analyze firmware for file types, and potential root file system metadata, and gain an additional understanding of the platform it's compiled for. We can use utilities like strings, file, and hexdump to gather this information. If none of the above methods provides any useful data, it means the binary may be encrypted or contain a real-time operating system, RTOS platform with a custom file system. If the binary may be encrypted, check the entropy using binwalk. If we have low entropy, then the binary is not likely to be encrypted. If entropy is high, it is likely encrypted or compressed in some way. There are also some online tools to check the entropy. Step 4 is extracting the file system. This stage involves looking inside firmware and parsing relative file system data to start identifying as many potential security issues as possible. Binwalk can automatically extract the firmware of known file system types. However, sometimes the binwalk may be unable to find the magic byte, so we may need to adopt manual methods to extract the firmware. In the manual method, you first use binwalk to find the offset of the file system. Then you can carve the compressed file system from the binary using the dd command. Once we have extracted the file system, we can use the appropriate tool to uncompress it. In step 5, we can start analyzing the file system contents. During this stage, clues are gathered for dynamic and runtime analysis stages. Investigate if the target firmware contains red flags, legacy insecure network daemons such as telnetd, sometimes manufacturers rename binaries to disguise, hard-coded credentials like usernames, passwords, API keys, SSH keys, and backdoor variants. hard-coded API endpoints and backend server details, review uncompiled code and startup scripts for remote code execution, extract compiled binaries to be used for offline analysis with a disassembler for future steps. We need to statistically analyze file system contents and uncompiled code manually, or leverage automation tools such as Firmwalker that parse the sensitive data and binaries such as etc, shadow, and etc. passwbd files, list out the etc. ssl directory, and search for SSL-related files such as PEM, CRT. Search for configuration files, look for script files, and search for other bin files. Look for keywords such as admin, password, remote, and AWS keys. Search for common web servers used on IoT devices. Search for common binaries such as SSH, TFTP, DropBear, Search for banned C functions. Search for common command injection vulnerable functions. Search for URLs, email addresses, and IP addresses. The step 6 is emulating firmware. Using details and clues identified in previous steps, firmware as well as its encapsulated binaries must be emulated to verify potential vulnerabilities. To accomplish emulating firmware, there are three approaches. The first is partial emulation. or user space emulation which is the emulation of standalone binaries derived from a firmware's extracted file system the second is full system emulation which is the emulation of the full firmware and startup configurations leveraging fake nv ram the last is emulation using a real device or virtual machine at times partial or full emulation may not work due to hardware or architecture dependencies If the architecture and endianness match a device owned such as a Raspberry Pi, the root file system or specific binary can be transferred to the device for further testing. This method also applies to pre-built virtual machines using the same architecture and NDAness as the target. In the seventh step, perform dynamic testing while a device is running in its normal or emulated environment. Objectives in this stage may vary depending on the project and level of access given. Typically, this involves tampering of bootloader configurations, web and API testing, fuzzing network and application services, as well as active scanning using various tool sets to acquire elevated root access or code execution. We can use tools like Metasploit, Burp, Nmap in this phase. You can review specific areas within an embedded device's web application, such as diagnostic or troubleshooting pages for potential command injection vulnerabilities. Authentication and authorization schemes are validated against the same framework across ecosystem applications, as well as the firmware operating system platform. Test whether default usernames and passwords are used. Perform directory traversal and content discovery on web pages to identify debug or testing functionality. Fuzz application parameters and observe exceptions and stack traces. Tailor targeted payloads against embedded web application services for common C slash C plus, plus vulnerabilities such as memory corruption vulnerabilities, Format string flaws, and integer overflows. Stage 8 is runtime analysis. Runtime analysis involves attaching to a running process, or binary, while a device is running in its normal or emulated environment. Tools that may be helpful are Frida, GDB Debugger, etc. The last stage is binary exploitation. After identifying a vulnerability within a binary from previous steps, a proper proof of concept is required to demonstrate the real-world impact and risk. Developing exploit code requires programming experience in lower-level languages as well as a background within the particular target architecture. POC code involves obtaining arbitrary execution on a device or application by controlling an instruction in memory. It is not common for binary runtime protections to be in place within embedded systems, however when this happens, additional techniques may be required such as return-oriented programming. In this video, we went through the methodology to analyze firmware. From the next lecture, we will start our practical lessons on IoT pen testing. In this video, we are going to see how we can extract a firmware, and then look for sensitive information in the firmware. We are in Kali Linux. We are going to download the IoT GOAT firmware that we have already set up as a VM in previous videos. Search for IoT GOAT on Google, browse to the GitHub page, click on the latest releases, and download the firmware image for Raspberry Pi. We are going to extract this image to view the file system contents. Browse to the Downloads folder. We will use binwalk to automatically extract the image. Use the command binwalk-e and the image file name binwalk will automatically extract the image. Move into the extracted folder. Here we can see squashfs root directory, which means our firmware used the squashfs file system, which is the most popular IoT file system. Move to the squashfs directory, and we can see firmware contents. As we have discussed before, one of the most important things we are interested in a firmware is to look for hardcoded credentials. Move into the etc folder and cat out the contents of the etc password file. Here, we have made an error. We have read out the content of our Kali machine users instead of the password file from the firmware. So, just cat out the contents from the password file in the current folder. Here, we can see all available users on firmware. We are particularly interested in users who have shell access. Similarly, we can read the contents of the shadow file, which contains hashes. Use the unshadow command to merge password and shadow files so that we may crack them easily with hashcat or John the Ripper. Now, we have the hash.txt file with password hashes. We will be using the mirai-bot net word list from seeklists. We can see if we have seeklists installed by using the locate command. And here we can see a bunch of word lists. We have already seen in our previous videos that this word list contains both users and passwords. Let us use the cut command to create a word list containing only passwords. Now use John with our hash file and the newly created password dictionary files as input, and we have successfully cracked the password for IoT Goat user. Similarly, we can also look for other sensitive files like database files. Let us use the Find command to file all DB files. Here, we have found two database files. We can open these files with SQLite Browser to see if we can find some useful information. So, open the first file with SQLite Browser. Click on Browse Data. And here we can see some email addresses, as well as their birth dates, which can be utilized in further attacks. Let us close this and try to open the other file. We get an error which means this file is not useful for us. In the same manner, we can look for other juicy files like config files, and analyze them one by one to extract useful information. In this video, we are going to see how we can find hidden and secret pages of a web portal of an IoT device with firmware analysis. We have the IoT GOAT VM up and running. If we open the web portal, we can see we see some kind of notification about Lua configuration. IoT GOAT is based on OpenWrt, which uses the LUCI interface for configuring and managing the device. We can see the URL address which is pointing to cgi-bin, LUCI directory. We can move to www directory in the extracted firmware. and see the contents of index.html file. It is also referring to the same cgi bin, luci directory. Let us move to the directory location, and we can see this luci file. uhttpd web server is often used to serve luci. The configuration file for uhttpd may include settings related to luci, such as the port it listens on and access control settings. Open this file and we can see the settings. The home page is www. If we scroll further down, we can find a user, lib, lua, lucy directory. We need to see the contents of the directory to see from where actual pages are being served. Here, we can see different directories like controller and view directories which look interesting. Let us move into the view directory, and here IoT goat directory may contain some interesting files. In the folder, we can see three files. We can try to browse these files on our browser, but we are getting errors. It means these are not being directly served. Let us move to the controller directory, which controls how pages are viewed or displayed. In the IoT GOAT directory, we have a Lua config file. Open the file, and here we can see some interesting entries. The command page is being served through admin, IoT GOAT directory, as command inject page. Let us try to browse the page again on our browser. And here we have found a secret page that allows us to run commands on the device. Before we play with the commands, let us see if other mentioned pages have useful stuff or not. And these are only placeholders. Let us play with the command injection page. We can directly run commands from the web portal, so we can try to get a reverse shell. Check the current IP address of your Kali machine. Open a Netcat listener to catch incoming shells. We will be using Netcat BusyBox reverse shell from PayloadAllTheThings. Copy the payload and amend the IP addresses. Enter the command and we can see that we have a shell on our Kali Linux. We can check the running processes with the ps command and we can play with it how we require. So in this manner we can analyze a firmware to find secret web pages of an IoT device and exploit them. In this video, we are going to download and analyze an actual firmware that is used in a wireless router. We are going to download the actual firmware of the TP-Link MR3620 Wi-Fi router. You can find the download link on the official website. Download the firmware. The firmware is compressed, so unzip it. We have a bin file now. I am going to rename it to firmware.bin. Now let us analyze it by running binwalk. The firmware uses the squashfs file system and uboot bootloader. Now, let us extract it with binwalk. Use the"-e flag with binwalk", and it will extract the firmware automatically. We can now move into the extracted firmware directory. We have a rootfs file system folder. Open it. We can now analyze it for useful information. For example, we can move into the bin directory. Here we have the busy box that is often found in IoT devices. We can find the supported IoT device architecture by using the file command. Here we can see that it is a 32-bit executable, and the architecture is MIPS. Similarly, we can move to the ETC directory. Here we have a password backup file. We have three users here. We can try to crack the hash passwords of these users. Copy these to a text file. Now use John to crack them. We are using the default John dictionary. So, we have cracked the password of the admin account, which is 1234. In the etc directory, we also have a vsftpd password file, which is an FTP server. If we open it, we also see three more user accounts and passwords in clear, which are hard coded. As per our analysis, these can be used for FTP access. We can also use the find command to look for juicy files like config files. We can check the contents of these files to extract useful information. For example, we can see what is the FTP server banner and anonymous login is allowed or not. One more important directory to look for is init.d. Here we have the script files that run every time the device boots. We can look into the RCS script that runs first on system boot. We can read the contents of this file and see what processes are initiated on boot. We can use the same file to add our backdoor to firmware if we want. Similarly, we can look for the shadow file or other important files on the file system. One of the most useful ways to search for sensitive information is to use the grep command to recursively find keywords in the file contents. For example, we can look for the keyword admin. By using this method we can find juicy information. For example, where this user account is being used or are there any other password files or services for the user. Here, we can see the files containing user information and passwords. So, in this manner, we can download an actual firmware for an IoT device and analyze it for security weaknesses. In this video, we are going to install Adafi OS. Adafi OS is a penetration testing distro for security professionals to assess the security of Internet of Things. The distro is based on Ubuntu 18.04. and contains pre-configured tools to help you with your next IoT pen test. So, search for Adafi OS. Open the official website. Scroll down. You will see a download link. Click on it. You will be redirected to a Google Drive. Click on the OVA folder. and download the OVA file. The file is approximately 8 GBs, and it will take a while to download. Once the file is downloaded, open the VirtualBox, click on the File menu, and select to import appliance. Choose the OVA file you just downloaded, and click Next. Now, you can select the folder where your new VM will be created on the hard disk. Click on Finish. Your VM will be imported. Now, start the VM. Adafi OS will boot up. You can see the tools directory on the desktop. It contains all IoT pen testing tools pre-installed. You can click on the View menu and switch to Full Screen mode. So, in this manner, you can set up an IoT pen testing VM. In this video, we are going to analyze a D-Link Wi-Fi router firmware on Adafi OS. Open a web browser and search for D-Link 300 router firmware. You will get an FTP site in the results. Open it. You will find a firmware bin file. Download the file. Open a terminal and analyze it with binwalk. We can see that the firmware contains the squashfs file system. Now, extract it with binwalk. Use binwalk with dash e flag to extract it. Open the extracted file system folder. and move to the squash fs directory here we can see our usual linux files we can move into the etc directory to see if we have some password or shadow files we cannot see these files here so the firmware has actually tried to avoid hard-coded credentials however this particular firmware has a known vulnerability that telnet credentials are not secured properly we can make use of the grep To recursively look for telnetd, which is the telnet server used mostly in IoT devices. Here, we can see a script that looks like is used to start telnet services on the device. Read the contents of the script. Here, the username alphanetworks is hard-coded, and the password is being fetched from a variable. If we look at the top, The variable is fetching the password from a config file. If we check out the contents of this file, we can find the hard-coded password. So, in this manner, we can analyze a firmware with our Adafi VM and look for weaknesses and vulnerabilities in the firmware. In this video, we are going to emulate a Netgear Wi-Fi router firmware using the Firmware Analysis Toolkit. Then, we are going to brute force its initial login credentials. Open a web browser and search for Netgear WNAP 320 Router Firmware. Open the Netgear official website. Scroll below. You will find a section for firmware and software downloads. Click on it. Now look for old versions of firmware and download the firmware version 2.1.1. Open a terminal and move to the Downloads folder. Unzip the downloaded file. We will get a TAR archive. Use the command TAR with"-xvf", to extract it. Now we get a rootfs.squashfs file, which is the actual firmware. Now to emulate the firmware, move into the tools folder. We will be using the firmware analysis toolkit. Move into the firmware analysis toolkit folder. Here we have a python script file called fat. Try to run it. We need to provide the exact firmware path to emulate it, so use the command fat.py and the full path of our extracted firmware. The Firmware Analysis Toolkit will automatically extract the firmware and build it for emulation with Kimu. Note down the IP address shown. This IP address will be used to access our emulated firmware. Now press Enter. and our firmware will be emulated using Kimu. Now, we can try to ping our IoT device, and we can see we do have the connectivity. Open the web browser and browse to the IP address of the target, and here we can see the login page of our Netgear Wi-Fi router. So, we have successfully emulated our firmware. Now, we will try to brute force the login credentials of the router with Burp. Burp is available in Adafi OS as a JAR file in the tools directory. Right click on it, and open it with OpenJDK Java Runtime. Burp will start. To easily route traffic from the web browser to Burp, we need the Foxy Proxy add-on. But as our Adify OS has not been updated since 2020, we will need an old version of the add-on. Search for Foxy Proxy old versions. Open the first link you got, scroll down, and download a version from 2020. Click to add to Firefox. The extension will be added to the browser. Click on the extension and open the option settings. Click on Add to add a proxy. Name your proxy as burp and add IP address as and port as 8080. And save the settings. In your browser, enter any fake credentials. Make sure the Intercept tab is on in the BERT proxy. Click on Login, the request will be captured in Burp. Now, right-click on the captured request and send it to the intruder. In the Positions tab, clear all variables. Then select the Attack Type as Cluster Bomb. Select the username captured and click on Add. Similarly, select the password and click on Add again. Now, our both fields are selected. Move into the Payload tab. The Payload Set 1 corresponds to usernames. Here, we can specify a username word list, or we can manually add users as well. I am going to add only two users, admin and root. Now select Payload 2 to specify the password word list. For this, I am going to use a default word list that comes with Metasploit. Now, click on Attack to start brute forcing. Here you can see Burp trying different users and password combinations. We need to keep an eye on the Status tab. You can click on the Status tab to sort it by code. Here we can see that we have status code 200 at password. Pause the attack. So, we have got our username and password combination for the login page. Now, open the login page again. turn off the burp proxy and try to log in with the found credentials and we are logged in so in this video we learned how we can emulate a firmware and then brute force the login credentials in this video We are going to see how we can exploit a blind remote code execution vulnerability in a Netgear Wi-Fi router firmware. Open a web browser and search for Netgear WNAP 320 router firmware. Open the Netgear official website. Scroll below, you will find a section for firmware and software downloads. Look for old versions of firmware and download the firmware version 2.1.1. Open a terminal and move to the Downloads folder. Unzip the downloaded file. We will get a TAR archive. Use the command TAR with"-x v f", to extract it. Now we get a rootfs.squashfs file which is the actual firmware. We can now extract the firmware using binwalk. We can now proceed with our manual checking of firmware files one by one to find the vulnerabilities. For example, we can move to etc folder and look for sensitive files. Here we can see that we have the shadow file which we can read. Normally, we are interested in the web application that is being run on the device. So, move into the www folder. Here, we have multiple files. In actual pen test, we will be analyzing these files one by one. Here we can also find hidden web pages that may not be visible otherwise. This particular firmware has a blind remote code execution vulnerability due to the use of a function called exec in an insecure manner in two of the files, namely the boarddata.ww and boarddata.na. We can see the contents of these files within an editor. Here we can see the insecure use of the exec function that is not sensitizing input before execution. Now to emulate the firmware, move into the tools folder. Move into the firmware analysis toolkit folder. Use the command fat.py and the full path of our extracted firmware. The firmware analysis toolkit will automatically extract the firmware and build it for emulation with Kimu. Note down the IP address shown. This IP address will be used to access our emulated firmware. Open the web browser and browse to the IP address of the target, and here we can see the login page of our Netgear Wi-Fi router. You can now log in with the username as admin and password as password. You can now open the vulnerable page. Here we can see an input field that accepts the MAC address. We need to exploit this input field so that we can execute commands of our choice through it. We will be using Burp Repeater to play with the input field. Launch Burp from the Tools directory. Make sure the Intercept tab is on in the BURP proxy. In your browser, select FoxyProxy to route traffic through BURP. Enter a Fake Make Address and click on Submit. The request will be captured in BURP. Right-click on the captured request and send it to the Repeater module. Now, to check whether the field is actually vulnerable to blind code execution, We can try pinging the localhost by adding a semicolon to the MAC address as shown. Click on Send. You'll notice a delay, which means the application is vulnerable to command execution. To further verify it, we can make it ping our attacking machine and see if we receive any pings. So, replace the localhost address with your attacking machine IP. Now start TCP dump on your network interface. Click on send and we can see that we are receiving ping requests. Now we will try to copy the shadow file to our current directory so that we may be able to open it directly in our web browser. Use the copy command as shown on the screen and click on send. Although we receive no notification, our file will be copied to the current directory. Now open the web browser and try to open the newly created shadow file. And we can see the file contents. So, in this video, we learned how we can exploit a blind remote code execution vulnerability. If you want, you can exploit it further to obtain a shell. In this video, we are going to learn how easy it is to install a backdoor in a router firmware. We are going to modify firmware of very famous router of TP-Link, 841N. We can break down the steps of backdooring a firmware in a few steps. First, we need to analyze the firmware and find its CPU architecture if it's MIPS or something else. We will generate a shellcode with Metasploit according to the CPU architecture. Then we need to copy the generated shellcode to the extracted firmware and make it run on boot. The last step is to rebuild the firmware using Firmware Mod Kit and emulate it. We already have a TP-Link firmware downloaded on Adafi OS. Let us first emulate it. Move into the Firmware Analysis Toolkit folder. Use the fat.py script to automatically extract the firmware and emulate it. Once the network setup is done, note down the IP address. After the emulation is complete, open the web browser and enter the IP address. Enter the username and password as adminadmin. And we can see the TP-Link router main configuration page. Now, we will use the firmware mod kit to extract the firmware. Use the extract firmware script. in the firmware mod kit master directory and it will automatically extract the firmware one important thing to note in the logs is that the file system uses big nd in format The firmware mod kit extracts the folder in FMK directory, and later on, once, we will rebuild the firmware, it builds the firmware from the same directory. Now we can move into the FMK folder, and here we have the extracted firmware in the rootfs folder. We can see the same familiar Linux directory structure here. One important thing that we need now is to find the supported CPU architecture. The easiest way to do that is to check the properties of BusyBox binary. So, move into the bin directory and use the file command on the BusyBox. And, we can see that supported architecture in MIPS 32-bit. Now, to generate our shellcode, we need to move into our Kali Linux machine. List down all payloads that are supported by MIPS CPU architecture. Here, we can see both big endian and small endian payloads. We need to use big endian payload, and for the video, we will be using shell bind TCP payload. This will open a port on our target to which we can connect. So, generate the payload with the command as shown. We are specifying the listening port with Lport flag, and we need the payload in ELF file format. Once our payload is generated, copy it, move back to Adafi OS, and paste it in the bin directory in the extracted firmware. Now, we need to make the payload executable and provide the read, write, and execute permission to the user. Use the change mode command to assign the permissions. You can verify the file permissions with ls-la command and we are set to go. The next step is to make this file run every time the system boots. There are multiple ways to do it. One of the easiest ways to do this is to add the file to the startup script. Move into the etc folder and rc.d directory. Here, we have the RCS file. The commands and scripts mentioned in this file are always run once the device boots. Add the command to run our payload at the end of the file. Save and close the file. Now, we have everything set up. Move back to the firmware modkit master folder and run the buildfirmware script. Our firmware will be built incorporating the changes we made and saved in the FMK directory. Let us move this new firmware to our Firmwares folder. Now, let us emulate it again. Use the Firmware Analyses toolkit to emulate our new firmware. Once it is done processing, open the IP address in the web browser, and we can see that we have the same configuration page open. Now, let us scan the router IP address and see if our backdoor port is open. We can see that port 5555 is open. We can now use Netcat to connect to the port. And we are successfully connected to our backdoor. Now we can run different commands and extract information if we want. So in this manner we can backdoor a router firmware. If we want we can upload this firmware to a physical router as well and we will have our own backdoored wi-fi router. In this video we are going to see how we can analyze MQTT packets for IoT. MQTT protocol works on publisher-subscribe model where there is a central MQTT broker and there are some IoT devices that publish data and then there are some IoT devices that subscribe to that data. Let's see some MQTT terminology. MQTT broker receives published topics. and keep the connection alive. It also sends last will and testament to subscribers if a client ungracefully disconnects. Then there is a M2TT client which can publish topics, keep a live time, retain bit quality of service etc. It can subscribe to topics. A topic is the name of data and the payload is the actual data and the message is the topic plus payload. There are three different types of quality of surveys. Zero means at most once, once is at least once, and two is exactly once. Publishing means to send a topic with payload to MQTT broker, whereas subscribing means to request a topic with payload update from MQTT broker. Retain is to ask MQTT broker to save the topic with payload even after sending it to all the subscribing clients. Then there is Keep Alive time which is how often broker pings client to see if he is there. Then there is Last Will and Testament is the topic with payload initially sent by an MQTT client to the MQTT broker for the broker to send to other clients if he is ungracefully disconnected. Now let's see how MQTT data exchange works. Publishers are fundamentally separate from subscribers. Publishers only care about getting data to broker and broker is fully responsible for getting data to subscribers. Clients connect to an MQTT broker and clients can publish data to topics. Clients can also subscribe to topics. Now let's see the demonstration. Now we know how MQTT protocol works and what are the different parameters included in the protocol. Now let's see how we can analyze MQTT protocol packets with Wireshark. Now open the pcap file containing MQTT packets. I have attached a sample pcap file as a resource to this document. Now apply the filter MQTT. Now you can see all the packets for the MQTT protocol. You can see that there are different packets like subscribe request, write acknowledgement, publish message etc. Let's analyze a published message. Click on the packet. Now go to the left bottom pane, click on MQT Telemetry Transport Protocol message and you can see the topic and the message included, which is Hello MQTT. Similarly you can check other packet and you can see that it contains the message Hello from Palo blocking client. So in this manner, if some information is hidden there, you can view that. and you can analyze the communication between IoT device and the broker. I hope you like this lecture and see you in the next lecture. John was working on his smart home appliances when he noticed weird traffic going across the network. Can you help him figure out what these weird network communications are? Let us start our target machine. We will start, as in any other case, by scanning the target IP. I explicitly scanned all the ports of the machine by specifying"-p-tag". From the scan we can see that there is a port open that uses TCP, and the service running behind it is MQTT. Let us do vuln scan and see if we can get more information. We specified sv flag to know about services and versions, and we used sc flag to run the default script scan. T4 will speed up our scan a bit. We can see a lot of topics that we can subscribe to and get more information. MQTT stands for MQ Telemetry Transport. It is a published, subscribed, extremely simple, and lightweight messaging protocol designed for constrained devices and low bandwidth, high latency, or unreliable networks. With that info, the next step is to attempt some communication with the device itself. We can do so by using the Mosquito MQTT client We can install Mosquito by simple command as shown. Now to connect to the Mosquito broker, we can use the Mosquito underscore sub and use dash t flag to specify the topic. Here, we want information about all topics. So, we use the wildcard hash for this operation. We can specify the target IP address with dash h flag. "-v has been used for verbose output.
We start receiving all the data from the device until we receive a weird string. This looks like base64 encoded. We can go to CyberChef and try to decode it.
After decoding, we can see there are some registered commands along with two different topics. MQTT works on publish-subscribe model. We can publish to a topic and the MQTT broker broadcasts this message to the devices that are subscribed to it. Now, let us try publishing to the two topic one by one. We can open a listener by using the same Mosquito subscriber command, open another tab, and use the Mosquito publisher to send a hello message to the first topic.
Observe the response received in the first window. We can see that we have received hello as it is which is not very interesting or useful. We can try encoding the message with base64 and observe the response.
So, use CyberChef to encode it. Now publish the message again to the first topic. However, we get the same results.
Now, let us try the second topic we saw earlier. Try publishing the hello message to the topic. And this time, we have got some Base64 encoded response. Try decoding it with CyberChef. We get some type of error message, which reveals the actual format for sending messages.
Now this is an interesting information. We have discovered what is the proper format for the message that we want to transmit. Let us try the ls command to list down all files in the current directory. Format the command according to the revealed format.
Use the id that we found in the original encoded message and base64 encode the whole thing. Then we simply send that using the Mosquito Publisher and wait for a reply in the subscriber window. We receive another response which is Base64 encoded.
We can see in the decoded reply that there is a file called flag.txt inside the root folder on the device. so we know which command we have to craft next. Now we can format our command to read this file. We send the command using the publisher and wait for the response from the subscriber, as we have done in the past. Now decode the receive message.
And just like that we should be able to retrieve the flag. Hopefully, you have at this point realized how simple it can be to hack an IoT device, and how we can manipulate the MQTT protocol to retrieve sensitive information. I hope you like the video and see you in the next video.
In this video, we are going to learn about Modbus protocol security. Modbus is an industrial protocol used for communication between intelligent devices and industries. We will go over the TriHackMe room titled Attacking ICS Plant 1. This room goes over the absolute basics of attacking a plant that uses Modbus.
Let us first understand what is Modbus and how does it work. Modbus is a serial communication protocol developed by Modicon in 1979 for use with its programmable logic controllers, PLCs. In simple terms, it is a method used for transmitting information over serial lines between electronic devices. Modbus is an open protocol.
It has become a standard communications protocol in industry. and is now the most commonly available means of connecting industrial electronic devices. Modbus is used to exchange information between PLC, SCADA, and field devices such as sensors and actuators. Several versions of the Modbus protocol exist for the serial port and Ethernet, and the most common are Modbus RTU, Modbus TCP, and Modbus Plus.
Modbus communicates over several types of physical media, with Serial RS-485 being the most popular method used. Let's say in a hotel we have several air conditioners. From a main computer, we can control each air conditioner. We give a unique address to each air conditioner.
We can see here the two communication lines A and B, which are connected in parallel with each AC. B. One wire is used to transmit data. while the other is used to receive data. Modbus Gateway is used for data conversion between different types of Modbus devices and media.
This is a typical setup in any industry. Modbus Communication over serial RS-485 physical media using two-wire transmit and receive connections works on master-slave model. Modbus RTU Network has one master and one or more slaves. Each slave has a unique 8-bit device address or unit number.
Packets sent by the master include the address of the slave the message is intended for. The slave must respond only if its address is recognized and must respond within a certain time period, or the master will call it a no-response error. A slave is any peripheral device such as an I.O.
transducer, valve, network drive, or other measuring types of devices which processes information and sends its response message to the master using Modbus. Masters can address individual slaves or initiate a broadcast message to all slaves. Slaves return a response to all message queries addressed to them individually but do not respond to broadcast messages.
Slaves do not initiate messages on their own and only respond to message queries transmitted from the master. Each exchange of data consists of a request from the master, followed by a response from the slave. Each data packet, whether request or response, begins with the device address or slave address, followed by function code, followed by parameters defining what is being asked for or provided. The general outline of each request and response is illustrated in the diagram. A slave's response consists of the fields, confirming it received the request, the data to be returned, and an error check field.
Modbus data is most often read and written as registers, which are 16-bit pieces of data. Most often, the register is either a signed or unsigned 16-bit integer. If a 32-bit integer or floating point is required, these values are actually read as a pair of registers.
The most commonly used register is called a holding register and these can be read or written. The other possible type is the input register which is read only. The exceptions to registers being 16 bits are the coil and the discrete input which are each one bit only. Coils can be read or written while discrete inputs are read only. Coils are usually associated with relay outputs.
Whether a particular device includes all of these register types is up to the manufacturer. It is very common to find all IOMapped to holding registers only. The type of register being addressed by a Modbus request is determined by the function code. The most common codes include 3 for read holding registers.
Function code 6 is used to write a single holding register. Function code 16 is used to write one or more holding registers. Some of the Modbus function codes are shown on the slide. Modbus slave devices can be visualized as having an internal spreadsheet filled with numbers. The columns in a Modbus device's spreadsheet represent register types.
The rows in a Modbus device's spreadsheet are simply the register number. Most often, these start at 1 and count up sequentially. Some devices might not have a register 1, and their first register may be number 100, for example. Now, let us look at the TriHackMe room.
The first task is introduction to OT and ICS. You can read through it in your own time. The second task introduces the Modbus protocol, which we have already seen in detail. The task also introduces the Modbus TCP library, which we can utilize to play with Modbus. So, go ahead and install it with the given command.
We also have some downloadable scripts here. The author has provided us these scripts to attack Modbus. So, download these.
I already have downloaded these. The first two questions ask about the functions of Modbus library that are used in these scripts. The first question is, which is the function used to read holding registers in the Modbus library? Open the discover.py script.
We can observe that it takes the IP address as the argument and connects to port 502. Here we have a function client dot read holding registers which is being used to read values from registers. The second question is, which is the function used to write holding registers in the Modbus library? Now cat out the contents of setRegistry.py, and here we have writeRegister function.
So answer the question. For task 3, we have a virtual plant VM. Start your machine.
Once it starts, browse to the target IP address in a web browser. and you can see a visual representation of a water bottle filling plant. Here, we can see that we can press the escape button to restart the plant.
We have bottles that are being moved on a roller and being filled with a liquid. If you look closely, you can see a sensor at the bottom that indicates the start of a bottle. And we have a sensor that senses if the bottle has been filled and our nozzle stops the liquid. Let us restart the plant.
Now, you can see as soon as the first sensor senses the bottle, the nozzle opens up. As soon as the bottle is filled, the liquid stops. So, we have three phases.
The initialization phase once the plant starts from the beginning. The filling phase is when water flows in the bottle. And the moving phase. Once the bottle is filled, the roller starts again moving the next empty bottle under the nozzle.
and we have sensors to read the state of the plant and actuators to alter the state of the plant. The first question is how many phases can we observe? So we have seen that the plant has three phases.
The next question is how many sensors can we observe? We have seen the two sensors in the graphical representation. How many actuators can we observe? These are three.
The plant start stop button. the nozzle, and the roller. Now we have to use the given script to discover the registers.
Run the Discover.py script, and we can count 16 registers with values of either 0 or 1. The next question is, after the plan is started and a bottle is loaded, How many registers are continuously changing their values? Let us observe the change in register values. We can see that only the first four registers are changing values. Which is the minimum observed value?
We have seen that the minimum value is 0. And for the next question, we have the maximum value as 1. Which registry is holding its value? If we go back, we can see that the 16th register value is constantly 1. Next question. Which registries are set to 1 while the nozzle is filling a bottle? Now, we have to pay attention and observe the GUI with our discovery script. If we look closely, we can see that registers 2 and 4 are 1 once the bottle is filling up.
Which registries are set to 1 while the roller is moving the bottles? Observe the plan again, and we can see these are 1 and 3. Now the color of the water level sensor is red, and the color of the bottle sensor is green. Next, we have to find the registry associated with the roller. The register 3 turns 1 once the roller starts, which is the registry associated with the water level sensor.
Here we can observe that it is register number 1. So, now we have nearly mapped most of the functions of the plant to the register values. The start-stop button is linked with registry 16. The roller engine is being managed by registry 3. The nozzle is either being controlled by registry 2 or 4. We need to perform additional tests to detect it. So, the next question is to find this registry. What we will do is change the registry values one by one for registry numbers 2 and 4 and try to observe the change. Back on our Kali machine, we have a set registry script.
If we see its contents, we have to provide three inputs. the IP address, the registry number, and the value. Let us first set the value in registry 2 to 1 and see what happens.
We can observe that the value has been updated, but our plant has got stuck and the nozzle has not started spraying liquid. Similarly, now change the value in Registry 4. We can see that the nozzle sprayed some liquid outside the bottle as soon as it received the input. To confirm this, restart the plant and change the registry value again, and we have the same results. So, we can deduce that registry number 4 is associated with the nozzle.
Now we have exactly figured out how registries work and how they are mapped. We can utilize this information to craft our further attacks. The room creator has already provided us with a number of scripts that we can utilize to attack the target. For example, we have a shutdown script.
If you run this, you can completely shut down the virtual plant. Similarly, we have an attack underscore move script. This script causes the nozzle to spray liquid uncontrollably while the bottles keep on moving.
Similarly, you can use these scripts and perform different types of attacks on the virtual plant. So, in this video, we discuss the basics of Modbus protocol and how easily it can be to exploit it and cause damage in an industrial environment.