Tag Archives: vulnerabilities

New study shows: Vulnerabilities in popular open source projects doubled in 2019. No need to panic!

9 June 2020

Catalin Cimpanu’s (1) post on the RiskSense study “The Dark Reality of Open Source” is well worth reading. Open source software is used everywhere. A critical vulnerability in an application that is based on open source software can lead to a data breach. But this holds also for commercial software. We can also expect that the number of flaws in open source and commercial software is roughly the same.

The main difference is that the number of open source software reviews is much higher than the number of commercial software reviews. So the results of the study are not really surprising.

In the case of TomCat, 7 of the 72 published vulnerabilities were weaponized. A quick check against the latest Coverity scan results for Apache TomCat (2) shows that the software has 987 defects, thereof 290 not yet fixed.

High impact defects are very valuable for attackers because their exploitation results in a full loss of integrity. The number of high impact defects in TomCat yet not fixed is 171. So we can expect that the number of vulnerabilities that can be weaponized is high.

In the case of Puppet, none of the 72 published vulnerabilities were weaponized. The latest Coverity scan for Puppet (3) shows no high impact vulnerabilities. So the result is not surprising.

What is the difference between Puppet and TomCat? Puppet is written in PHP/Python/Ruby with a defect density of 0.20. The defect density is the number of defects in 1000 LoC. TomCat is written in Java with a defect density of 1.19. Thus, software reviews will definitely detect more vulnerabilities in TomCat than in Puppet.

This has direct impact on your security strategy. If you use TomCat as middle-ware in the DMZ you should design your application to allow frequent patching, means, more robust against changes in the middle-ware. In addition, automated testing is required to ensure operability in the case a patch must be implemented. Finally, your operations team must be prepared to install patches within few hours upon release by the vendor.

Have you ever seen such details for commercial software? Like IIS?

Have a great week.

References

1. Cimpanu C. Vulnerabilities in popular open source projects doubled in 2019 [Internet]. ZDNet. 2020 [zitiert 8. Juni 2020]. Available at: https://www.zdnet.com/article/vulnerabilities-in-popular-open-source-projects-doubled-in-2019/

2. Synopsys. Coverity Scan – Static Analysis for Apache TomCat [Internet]. 2020 [zitiert 9. Juni 2020]. Available at: https://scan.coverity.com/projects/apache-tomcat

3. Synopsys. Coverity Scan – Static Analysis for Puppet [Internet]. [zitiert 9. Juni 2020]. Available at: https://scan.coverity.com/projects/puppetlabs-puppet

If one can ping an industrial controller, one can stop it

12 November 2016

On Wednesday I watched the Indegy webinar “How a new PLC Simulator vulnerability can compromise SCADA/ICS networks?“. The webinar dealt with a recently detected vulnerability in a simulator software.

Simulators are used for verification and validation of changes to process control systems (PCS) before the changes are applied to the PCS. If the changes passes the tests it is very likely that the changes will have no negative impact on the PCS and thus to the safety of the process. Simulators are executed on the Engineering Station which is directly connected to the control system and to the production network.

PCS are very specialized realtime industrial computer systems. All PCS are lacking of the security features we know from the office IT, e.g. authorization, authentication and malware protection.

The slide below brings it straight to the point:

The Center of Gravity in the ICS Domain

The Center of Gravity in the ICS Domain

With this, the isolation of the Engineering Stations and the PCS in separate network zones is the key to security in the ICS domain. Access to these networks must be limited to authorized staff and through few strictly controlled access paths.

And with this, the first commandment of the Office IT Security, “Thou Shall Patch“, becomes less important in Industrial IT (OT) Security. “Thou Shall Isolate“, across the entire OSI stack, is the first commandment of OT Security.

Have a good weekend, and enjoy the webinar.

Adobe releases next emergency Flash zero-day patch

27 June 2015

Adobe Flash Player is a real source of irritation. New vulnerabilities are continuously made public. In the last three month 64 vulnerabilities were published in the NIST NVD Database, of which 43 with highest severity 10.0.

The latest vulnerability CVE-2015-3113, that potentially allows an attacker to take control of an affected system, is a technically advanced piece of malware. For technical details see the FireEye blog post ‘Operation Clandestine Wolf – Adobe Flash Zero-Day in APT3 Phishing Campaign’.

As usual the attack is started through a phishing email. And, once the attackers got access to the victim’s network, they move laterally through the network in the search of valuable information.

With this we have the first and second line of defense in a prevention strategy: User awareness training to support users in recognizing such attacks, and system isolation to prevent the attackers from moving laterally through the network.

Perhaps it’s time to solve this problem once and for all by uninstalling Flash Player…

Have a good weekend.