30 May, 2018

Life path embedded bugs from 0- to 1-days

“As Gregor Samsa awoke one morning from uneasy dreams he found himself transformed in his bed into a gigantic insect.”
Franz Kafka, The Metamorphosis.

The IoT world enjoys tremendous growth with new devices being released to the market every day. Unfortunately, cybercriminals forge ahead as well since the number of attacks on IoT devices is increasing. So, security becomes a more acute problem and the basic necessity. There is a wide spectrum of cybersecurity companies offering their solutions to protect IoT devices. In this article, we’ll describe the life path of a common software vulnerability, and touch upon main types of security solutions and proactive solutions in particular.


Device release. A vendor releases a device to the market. After that, a user or an enterprise purchase this device (or provided with it by a service supplier). Here, it’s worth pointing out that financial capabilities and the degree of cybersecurity awareness of common users and organizations differ greatly. One may say, that right at the moment of plugging a device into a power outlet, its owner starts facing the threat of being compromised.

Research. Both good and bad guys may begin researching a device to find 0-days it contains. So, there are two pathways here. The time required to conduct a research vary significantly: from a couple of hours to six months of continuous searching for security imperfections. The amount of time depends on both the degree a device is protected and an adversaries’ skills and determination (read: the sum of money they’ll get). It’s one thing when cybercriminals prepare themselves to launch an APT attack but it’s quite another when your an ill-natured person living next door tries to hack your router and add it to his botnet “collection”. The first case implies an incredibly large amount of work to be performed. As for the second one, there is a high chance attackers would either shelve their project or choose a more promising and tempting target.

Disclosure. An average vendor learns about the vulnerabilities in its product in the following ways:

  • a vendor is reported about a vulnerability by a cybersecurity company (like Embedi);
  • independent security researchers directly notify a vendor about it;
  • Bug Bounty participants report a vulnerability;
  • a developer found a vulnerability as a result of internal testing;
  • etc.

The main idea behind this discourse is that a vendor gets this precious knowledge not as a result of an investigation of an ITW attack on its client. There are no guarantees for this information being exclusive. Cybercriminals may have dissected this or that security issue a long-long time ago, which leaves a vendor naked and exposed.

Attack. The light at the end of a pitch-black tunnel starts begins to fade if adversaries were first to find a 0-day. In such a case, adversaries spend no time and expeditiously write an exploit that ill-wishers from all over the non-flat planet we’re living on may use in any way their imagination lets them to. These mass attacks are quite easy to detect. Cybercriminal may stick to APT attacks and use the exploit for years. As it is stated in RAND’s research, the life time of a typical 0-day reaches an approximate of 7 years.

By way of example, a user, enterprise or company comes across a security incident that slips under their radar. I presume you’ve got the idea of what happens in this situation. Yeap, cybercriminals get an indefinite amount of time to use the exploit to their liking until an unsuspecting victim finds out it has a vulnerability that is not only exploitable but has also been exploited for quite awhile.

Detect. Detection is a moment of a great revelation, where a vendor has to go through five stages of accepting its defenselessness. Sure thing, common users’ capabilities are quite limited by the lack of systems and professionals that can detect security issues, so an average user is even more vulnerable here. As said above, attack detection may take either an acceptable or huge amount of time. Let’s suppose a security incident was dragged to light timely. But don’t forget it’s still a dangerous 0-day that is not fixed yet and can be used by adversaries for years from the moment of its detection.

Verify. Once an incident comes to the bright light, an enterprise should find the root of the problem. It initiates the process of meticulous gathering of the data relevant to the investigation of the case. A common user is sure to fall out from the equation at the previous stage. Here, one should perfectly realize that it’s only some indirect significations and consequences of the incidents can be detected. As for the prime cause, it’s not as easy as one can think. And it’ll be a real conundrum to investigate a successful attack case if a cybercriminal used this or that device to attack an enterprise.

Thus far, it is a complex and complicated task to investigate a security incident on an end-point smart device. There are no universally applicable tools and approaches since there is a vast variety of devices. For instance, IDS/IPS/IoT firewalls may turn out to be an attacker’s point of entry into an enterprise’s infrastructure (a car, factory, health facility, smart-city system, etc.) or a house. Even if an enterprise’s information security specialists manage to find out that potential traffic has been passed through a camera, the questions of how an attacker has got access to the device and what vulnerability has been exploited (buffer overflow, command injection or something else) should be still inquired into. Let’s suppose, in co-operation with a vendor, an enterprise has found the answers and proceeded to the following stage. Don’t forget though that until a vulnerability is fixed other owners of a device of the kind may be attacked as well.

Analysis. At the Analysis stage, a vendor or its internal security team (if there is one) starts analyzing the vulnerability. Here, the following questions are to be answered:

  • Why has the vulnerability happened?
  • Are there other vulnerable code?
  • Is this unsafe code used in other devices of a vendor (quite often different devices share the same code)?

In addition, a vendor or its internal security team (if there is one) formulates a list of recommendations for fixing the vulnerability and settles other technical and organizational issues. Depending on numerous factors and aspects, the process may take a considerable amount of time. No wonder, an attacker won’t wait for a vendor and will go on exploiting the security imperfection.

Patch release. When all is good and done, a developer team releases an anticipated security patch and starts the internal testing. The goal of the testing is to ensure the patch won’t negatively affect the stability of a device operation. Having verified this, developers release the patch, and devices may be finally updated.

In the meantime, the bad guys who hadn’t the exploit to a vulnerability earlier learn the vulnerability is closed. They carry out a detailed analysis a new firmware version, find patched code, and write a new exploit. Then, they either simply use the exploit (for example, to create a botnet until all devices are patched) or put it into public access for their associates to have fun. Thus, the exploit turns into a public domain. What is even more important and dangerous at the same time, it requires no special technical skills.

It results, in mass endemic attacks on devices. As the practice shows, exploits of the kind may be used for a long time, especially when it comes to not updatable devices. We shouldn’t forget about vendors that don’t bother themselves updating and patching their devices either. Unfortunately, unscrupulous vendors are still a thing.

Update. At this stage, vulnerable devices should be updated, which may either take a while or not happen at all. The successfulness of the updating stage hinges on the basic configuration of devices (whether they can automatically update their firmware via the Internet) and the level of technical skills of both a common user and an enterprise (in case devices can’t be updated automatically).

Here, a user has to go to a manufacturer’s webpage or find the corresponded menu entry in a device, request/download a security patch and install it on a device. It’s also worth noting that there may be a wide variety of vulnerable devices, so the process of updating all of them by a vendor may be laborious and unbearably long.

To install an update a user will have to restart a device. For enterprises, it’s not as easy though because to restart their devices and not to harm vital business process they must wait for special technological intervals in their schedule. Most users, in their turn, do not even think about updating their devices and hand them to attackers on a silver platter, which results in botnets emerging all over the globe.

Well, road to update was long and winding, and only now a device has got the fix it needed. Considering the overall of the stages we’ve reviewed, it won’t take much effort to imagine for how long this potential vulnerability has been being exploited. Of course, there may be much more vulnerabilities in a vendor’s devices along with the patched one. And, you know, someone may be exploiting them right now.


Each stage of the life path corresponds to a particular type of a solution: Predict solution, Proactive solution, Detection solution, Response solution, and Updating solution. They facilitate investigating a security incident and can even help avoid it. However, a vendor may choose not to use any of them and leave its products vulnerable, and quite a tempting target for an adversary. It’s a pity, but such defenseless devices are a common occurrence.

Before a device is released to the market, a developer holds all the procedures to increase the security level of its product. As a rule, these procedures relate to Predict solution. With its help, a developer can use various security libraries, frameworks, scanners, and analyzers of source code. Nonetheless, it’s no guarantee for detecting all current and future issues and incidents. A vendor can also implement a set of solutions that will help at following stage, such as sandbox mechanisms, exploit mitigations and monitoring agents.

The purpose of Proactive solutions is to make a security issue either completely unexploitable or extremely difficult, unstable or burdensome to be exploited. These solutions may save an enterprise’s time and financial resources on preventing a security incident and, consequently, a device getting infected by an attacker.

Detection and Response solutions boost and simplify the process of fixing a vulnerability (both at investigating and patch releasing stages). However, a security issue still stays in a device and can be exploited.

Updating solutions are aimed at making the process of updating devices easier and faster.

The figure above demonstrates the dependency between financial losses a vendor may face to fix a vulnerability and security solutions implemented into a device or supported by it. There are also financial losses suffered by an enterprise that came across a security incident with a vendor’s devices. This may also lead to reputational losses for a vendor.

Advantages of Proactive security solutions:

  • proactive measures make exploitation of vulnerabilities either extremely difficult or even impossible. Both adversaries and their associates will encounter difficulties in the process of exploitation and will turn to less protected devices. It is also a challenge of a kind for the cybersecurity community, which vendors can use to their benefit;
  • no costs on recovery from an attack (no attack — no financial losses);
  • more time to create, test, and release a patch since devices and users are safe;
  • lower risk for clients with outdated devices. As was stated above, it may take quite a long time to bring an anticipated update to all devices. Proactive solutions won’t allow a new wave of attacks launched after 1-day is detected to harm devices.

To choose an appropriate proactive solution for a particular security case or device, the following questions should be answered:

  • What attack model is applicable to your device?
  • What attacker’s models are relevant for your device and which of the are of the highest priority?
  • What changes in your devices are acceptable?
  • What overheads in a device operation are acceptable?

Possible answers to the listed questions will be provided in one of Embedi’s following articles.

We, at Embedi, believe that it’s better to prevent security issues from occurring than wasting precious time to counteract them and their consequences. At the moment, we offer two proactive security solutions.

AntiExploit is a software solution created to make the process of exploitation of 0- and 1-day vulnerabilities and those vulnerabilities related to memory corruption extremely difficult or even impossible for an attacker.

WebGuard is a software solution developed to increase exploitation difficulty of those 0- and 1-day vulnerabilities related to web technologies. It minimizes the number of vulnerabilities by filtering (performing validation check) user requests and application responses.

We’ve demonstrated the way our IoT security solutions may help secure your devices at: