Tag Archives: National vulnerability database

Puzzling: Five years old critical vulnerabilities exploited in November 2017

26 November 2017

Section Exploited Vulnerabilities of the Recorded Future Cyber Daily is sometimes really frightening. On November 9th, 2017, 249 successful exploits of CVE-2012-1823, a vulnerability in PHP, were recorded. This is hard to believe because CVE-2012-1823 was published on May 11th, 2012. Although a patch was available at the date of publication, it seems that the operators of this systems were not able to implement them within the past five years.

However, it would have been of urgent need in this case. CVE-2012-1823 is a so-called RCE (Remote Code Execution) vulnerability, which allows remote attackers to execute arbitrary code on a victim’s computer, and, in the worst case, to hijack the victim’s network.

RCE vulnerabilities are included in the critical vulnerabilities. Critical vulnerabilities are

  • exploitable from the network
  • need only low or medium skills to exploit
  • need no authentication
  • cause great damage, have high severity
  • allow remote attackers to execute arbitrary code on the victims computer

If an application system is operated in the DMZ, critical vulnerabilities must be patched directly upon publication to prevent attackers from getting onto your network. Or at least, between the time of publication and an exploit or proof of concept shows up. Since examples of how to exploit this PHP vulnerability were available in early May 2012, immediate action was required.

The big question is: Why were this vulnerable PHP versions not directly patched?

Exploitation of older vulnerabilities is not an isolated case. The HPE 2016 Cyber Risk Report shows, that in 2016

  • 47% of successful exploits use five or more years old vulnerabilities.
  • 68% of successful exploits use three or more years old vulnerabilities, 47% of them were critical vulnerabilities.
  • Stuxnet, CVE-2010-2568, was used in 29% of successful exploits.

An analysis of the critical vulnerabilities by vendors shows, that more critical vulnerabilities were found in non-Microsoft products than in Microsoft products.

Critical vulnerabilities 2010 - 2016

Critical vulnerabilities 2010 – 2016 by vendors. Click to enlarge.

But automated patch management is only available for Microsoft and few of the other vendors’ (e.g. Adobe, Oracle, SAP) products. Thus, we can expect that many critical vulnerabilities remain unpatched, which results in an ever-growing pool of opportunities for cyber criminals.

An ever growing pool of opportunities

An ever-growing pool of opportunities. Click to enlarge.

1) For the chart above I assumed that 50% of critical vulnerabilities remain unpatched. This assumption is based on the analysis of the 2017 NIST NVD data as of August 31st, 2017.

Since no automated patch management exists for PHP we can expect, that CVE-2012-1823 was rarely patched. But the worst is yet to come: From the HPE 2016 Cyber Risk Report we learn, that even six years old Microsoft vulnerabilities (Stuxnet, CVE-2010-2568) are not patched.

How to tackle this issue? From my point of view, the cause is compliance driven security. We often do patching of everything to meet compliance with a certain standard, instead of focusing on the real important issues, e.g., the critical vulnerabilities. Or, in other words, we close a lot of mouse holes while the barn door remains wide open.

WIth this, we must move from patching to vulnerability management, and priority patching for the critical vulnerabilities. Through a differentiated inspection of vulnerabilities we get out of the patch treadmill and can start working on the important cyber security issues.

By the way, if you haven’t subscribed to the Recorded Future Cyber Daily yet, consider to do it this week.

Have a great week.

Advertisements

How to mitigate Drive-by-Downloads Attacks

24 January 2014

Bad news for Adobe Flash Player users. A new critical vulnerability (CVE-2015-0311) was found in Adobe Flash Player 16.0.0.28… Successful exploitation could cause a crash and potentially allow an attacker to take control of the affected system.

In the Adobe Security Bulletin we read ‘We are aware of reports that this vulnerability is being actively exploited in the wild via drive-by-download attacks against systems running Internet Explorer and Firefox on Windows 8 and below.’

Drive-by-download (DbD) attacks are a often used technology to exploit vulnerabilities in programs. In his post ‘How malware works: Anatomy of a drive-by download web attack’ John Zorabedian from SOPHOS gives a detailed description about how DbD attacks work.

The shocking fact is: It’s not even necessary to click a link on the malicious site. If you just load the site the malware download could start, automatically and silently in the background.

The good news is that we could almost completely deactivate this feature, namely without considerable comfort loss. The Security Technical Implementation Guide (STIG) for Internet Explorer 11 shows the direction.

STIG’s are primarily used to secure the information systems of the Departments of Defense, but this should not deter us from using STIGs to secure our systems at home, and of course in our businesses.

STIGs are available from http://www.stigviewer.com/stigs for operating systems, web servers, databases or applications. They are an excellent means to secure the devices that are connected to the internet against malicious attacks. But, be aware that 100% safety could not be achieved.

Applying STIGs to Microsoft operating systems and applications is very easy if you are familiar with the registry editor regedit.exe and the local group policy editor gpedit.msc. Since only standard windows security options are used the recommended settings could be applied to all computers.

Back to the Drive-by-Download attacks. To prevent DbD attacks we have to configure Internet Explorer such that downloads not consented by the user are blocked. Sound’s easy, doesn’t it? We have just to work through the STIG for Internet Explorer 11 and implement the relevant fixes:

Step 1: Block non user-initiated file downloads

The DoD requirements block unconsented downloads from the Restricted Sites Zone and the Internet Zone. Since I would not trust computers in local networks as well I would strongly recommend to block unconsented downloads from all zones.

Implement at least Fixes from Finding Ids V-46705 and V-46643

Step 2: Block non user-initiated file downloads for Internet Explorer Processes

Implement Fixes from Finding IDs V-46779 and V-46781

Step 3: Enforce Protected Mode

Protected Mode protects Internet Explorer from exploited vulnerabilities by reducing the locations Internet Explorer can write to in the registry and the file system. I would recommend to enforce protected mode for all zones.

Implement at least Fixes from Finding IDs V-46685 and V-46681

Step 4: Enforce Enhanced Protected Mode on 64 bit Windows Systems

Implement Fix from Finding ID V-46987

That’s it for today. Please keep in mind that 100% safety could not be achieved, even if you implement the 155 fixes from the IE11 STIG.

Don’t Panic! And have a good weekend.

Software manufacturers have no sense for IT security – Part II

23 October 2014

Sometimes malware protection software works too well. I found some emails with malicious executables, disguised as pdf files, in the attachment in my junk-mail folder. Unfortunately the anti-malware system removed the attachments and replaced them by the filename.

Some weeks ago a new kind of malware that resides solely in the registry was in the news. To implant Poweliks attackers must exploit a vulnerability of the system and, the good faith of the users. Pdf or rtf documents with embedded malicious code are used very often to start the attack.

Just why is the Adobe Reader such a popular tool for attackers?

Adobe Reader is very popular for viewing of pdf documents, and very notorious for its vulnerabilities. The list of known vulnerabilities published in the National Vulnerability Database is really long, and some of them are perfectly suited to implant malware. By the way, Adobe Flash Player is as popular as the Adobe Reader for attackers, and the list of vulnerabilities is of comparable size.

Fortunately advanced security options like a sandbox are available to defend malicious attacks, but these are not activated during a standard installation. Even for enterprise users the standard installation procedure must be pre-configured.

I can’t find a reason why Adobe does not install the Reader with advanced security options enabled by default. Apparently, Adobe is not interested in protecting the privacy and security of their customers.

Fortunately the National Checklist Program Repository provides ‘detailed low level guidance on setting the security configuration of operating systems and applications’.

For Acrobat Reader X a checklist is available which could be easily adapted to the Acrobat Reader XI. Although this checklist is meant for pre-configuring installation packages the configuration hints could be used to secure existing installations as well:

Navigate to menu Edit/Preferences.

In category General section Application Startup activate option Use only certified plug-ins.

In category Security (Enhanced) set the protection options as described below:

Adobe ReaderEnhanced Security Settings

Adobe ReaderEnhanced Security Settings

[1] Enable sandboxing for all files

[2] Enable Enhanced Security

[3] Disable all Privileged Locations.

Although this sounds somewhat paranoid viewing of pdf files is much more secure now. A pdf file is now opened in a sandbox running at the lowest integrity level. Most features are disabled by default, but could be enabled with just one click.

Enjoy!