As part of our articles detailing the 10 most frequent web attacks (as listed in the OWASP top 10), we are going to evoke the use of components with known vulnerabilities.
Quite obvious, isn’t it?
In this series of articles we treat the whole of the OWASP top 10, but this explanation in particular does not really require technical details. Indeed, when one uses a component with known vulnerabilities, one must expect an attacker to use it… It seems logical, which is why we will not be detailing this point any further.
However, it is important to understand that a software or library that is not vulnerable at some point might (and probably will, in the case of the web) become vulnerable the next day.
It is sometimes more complex than it looks to get rid of these components with vulnerabilities.
A lot of situations lead to the keeping of components that are outdated or with security flaws:
- Loss of control over the development, for instance because of a web agency change, or a loss of internal resource
- Difficulty to stop the production during an update
- Lack of information: one doesn’t know that the component is vulnerable
- Non-disclosure: when nobody made the vulnerability public, but it is already exploited by pirates
- Inter-dependency of programs and libraries. For instance, if one upgrades a SSL library, will all the softwares relying on it automatically use the new version? Or will one have to upgrade all of them individually?
- Lack of human resources or time to prioritize the project
It is thus important not to use vulnerable software or libraries, but when it is not possible, one must still bring a solution to the problem.
CerberHost’s answers to vulnerable softwares or libraries
One of the points that presided the creation of CerberHost is precisely this one. We set up quite an important bill of specifications, in which we had to find solutions to the fact that developers would mistakenly integrate vulnerabilities and that libraries, components or softwares could be or become vulnerable.
CerberHost provides many answers:
- Our WAF, NAXSI, does not rely on signatures (file containing a trace of virus code, for instance used by antivirus softwares to block attacks) but on behaviors, it natively protects your website against the most common embezzlements (XSS, XSRF, SQL Injection, etc…)
- Operating systems being reinforced by the adding of numerous components (Pax / GRSec, fail2ban, Mysql Sniffer, ExecVEkiller, etc.), they auto-defend themselves against common attacks (including overflows), no matter which software is touched
- Audits and test, before any production launch, ensure that the code and its annexes, as well as the used softwares’ and libraries’ versions, are safe and not vulnerable
- If a vulnerable software should be used, a virtual patching will be set in place on reverse proxies or firewalls, beforehand, for these vulnerabilities to no longer be available for use
- Finally, the R&D department of NBS System continuously checks the web for emerging vulnerabilities on the market and brings patches and corrections, transparently for our clients. The last vulnerabilities found (XEN, heartbleed, Shellshock, Puddle, etc…) were corrected on our infrastructure in 24 to 48 hours after their publication.
The ideal procedure remains to update, as soon as possible, the vulnerable components. If they are infrastructural (reverse proxies, firewalls, routers…), this operation is the responsibility of our team. If the components belong to the website (framework, PHP or Javaversion, extensions, plugins, etc), it is the responsibility of the client or its web agency. In the meantime, our teams monitor more particularly the websites relying on fragile components.
CerberHost protects your website against all Top 10 OWASP attacks, and much more.
To discover CerberHost in pictures, watch its presentation video HERE.