Learn about how attackers identify a weak component through scanning or manual analysis. They customize the exploit as needed and execute the attack.
- [Instructor] Number nine in the OS top 10 is using components with known vulnerabilities. This just so happens to be my favorite one because I'm fascinated with how modern software is built and how much even brand-new software depends on existing software that is often developed by open-source communities and third parties. I'm going to talk about using components with known vulnerabilities in general terms to help you understand conceptually how this kind of thing works.
See now how this whole time we've been talking about security vulnerabilities and how hackers can exploit them to attack software? This is not a theoretical phenomenon. Lots of software out there in the world is actually vulnerable to the types of things we're talking about. Some of it is patchable and some of it is patched. But a lot of it isn't patchable and a lot of it isn't patched. There's a public list of these security vulnerabilities called CVE, which stands for common vulnerabilities and exposures.
When a new security vulnerability is discovered and a patch is released by whoever made that software in the first place, that information gets posted here. The tricky thing is that this information can be used for good and it can be used for evil. When an organization that is using the vulnerable software finds out about the patch, they can use CVE to find out about it and get the software fixed so they are no longer vulnerable. But as soon as the good guys find out about the vulnerability, so do the bad guys.
The bad guys know that a lot of software isn't patched quickly. Frankly, some software doesn't get patched, period. And they know how to take advantage of it. There's another thing about software that makes this list of vulnerabilities particularly interesting. It's that pretty much all software depends on other software. Any given piece of software might actually depend on tens, or hundreds, or even thousands of other software components that were developed either by the open-source community or by third parties.
In the same way that car parts are sourced from many different manufacturers, so are software components. Last year, I received a recall notice for my Honda Accord, saying that there was a problem with the air bag inflator which had been developed by a third party manufacturer called Takata. I had to bring my vehicle in to the dealership and get it replaced. If I hadn't done that, then my car and any passengers riding in it would have been at risk of injury until it was fixed.
There are two really important parts to this story. Number one, I was notified about the problem, and number two, I got my car fixed. It's a similar situation with software. Organizations that develop or run software need to find out about problems and they need to patch them. Unfortunately, patching is much more easily said than done. A failure to patch in time is pretty much exactly what happened with regards to the Equifax breach in 2017 which affected more than 100 million US consumers.
In this case, the patch for the vulnerable software component was released in March. Remember that when this type of information comes out, it's available to both the good and the bad guys. For whatever reason, Equifax did not get around to patching it quickly and the hackers got around to exploiting the vulnerability before it could be fixed.