Aluminium maker battles to contain ransomware attack

A significant news story this morning. This underlines the importance of a range of security measures, including network segmentation.

It is also important to carry out risk assessments and treatments that target business critical systems with security controls reflecting what is likely to be a heightened risk appetite.


Windows 7 support will end soon – Microsoft

The US Department of Homeland Security CISA covered the impending end of support for Windows 7 support today.

What date will support end for Windows 7? It’s January 14, 2020. With enterprise refresh plans taking a long time, it’s now that obsolescence planning needs to start, to avoid the risks of unpatched platforms.

After this date, Windows 7 will no longer receive technical support, software updates, or security updates or fixes.

Read more at US-CERT – Microsoft Ending Support for Windows 7

The Microsoft End of Support FAQ has lots of useful information, see – Microsoft End of Support FAQ

What can you do in your business to better manage this upcoming development, and similar ones in the future?

  • Review your installed software base using automated licensing tools
  • Manage your operating environments
  • Ensure all operating environments, to the fullest extent possible, are in-support and receiving updates
  • Carry out rigorous risk assessment and treatment for obsolete platforms
  • Implement a patch management plan and policy
  • Implement an obsolesecence management plan
  • Consolidate your enterprise environment to fewer better-managed operating systems

TAs leverage legacy email protocols to bypass MFA

An interesting article by ProofPoint. This has been a weakness in many MFA architectures particularly email for a long time now, where application specific passwords have been used to mitigate the threat.

Hopefully we will see some innovation in authentication schemes for legacy protocols, but it might not be easy due to inherent protocol limitations.

This underlines the importance of:

  • MFA access to external non-VPN email (e.g. OWA) through controlled access routes
  • Removing Internet facing legacy email services such as POP3 and IMAP
  • IDS systems on your perimeter network
  • In house or outsourced SOCs 24×7


CMU CERT on ASLR – assumptions a bad idea

Some time ago I wrote a blog post on the topic ASLR, DEP and similar protections offered by Windows.

As I discussed at the time, it’s very easy to make assumptions about these kinds of protective schemes that in many cases fail to hold.

This is because, in the absence of mandatory protection policies, the protections are controlled by the PE executable header flags, which effectively opt-in binaries.

I stumbled across a post by CMU CERT on this very topic by Will Dormann recently, which complements my earlier blog post very well. Worth a look.

This is, of course a very good motivation for:

  • Using the latest version of software
  • Maintaining patch management policies and plans
  • Auditing software, particularly binaries with a heigtened attack surface (e.g. public facing daemons)
  • Protecting legacy software systems

SANS Security Awareness: Forwarding Email

SANS Security Awareness regularly produce useful information that can be used by SMEs and enterprises to improve awareness among users about cyber security topics. It’s all good stuff, but this recent update caught my attention as it’s very easily done in modern desktop software packages for email:

Vulnerabilities in Adobe Reader underline benefits of PDF sandboxing

Control Your Own Destiny or Someone Else Will” is perhaps one of the most relevant quotes for cyber security, of course from celebrated GE CEO Jack Welch. It’s never been more true than with the PDF file format.

There has been some further coverage this week about the vulnerabilities affecting Adobe DC and Reader DC. A whopping 44 vulnerabilities were addressed in the February updates from Adobe, of which 43 are critical. Some of the vulnerabilities allow code execution, while others bypass security controls, and yet other facilitate the theft of password hashes.

Most SMEs install Reader DC and Adobe DC, and a large number of them install Reader DC as the primary viewer for PDF attachments.
But by using such a file association, it can directly expose endpoints to exploitation attempts through malicious PDFs. In some cases, by the time the PDF has been opened in the targeted software package, it can be too late.
This raises risks of sophisticated exploitation attempts by phishing attackers, who may be able to successfully deliver a PDF payload right into the organisation over email. That’s not so far fetched – email security filters provide good to excellent protection, but will not provide total protection. Compounding the problem, PDF ranks as one of the top five maliciously-used file attachment types in malicious email, so it pays off to handle it correctly.
What can be done to protect against these kinds of threats? The best option is to use a less feature-rich viewer for PDF attachments. In most cases, PDFs are used as a static document format to discourage modification. More elaborate features such as JavaScript are not used very often. So it can be a smart move to use an alternative default viewer for PDF files, and the option of choice is usually Google Chrome. A PDF viewer is contained within Chrome that provides a good level of isolation from the user environment to make it a popular choice. Chrome treats web content as untrusted and isolates it within a sandbox using the PDFium module as a viewer for PDFs, a module that has a relatively small attack surface based on known vulnerabilities and functionality.
Though PDFium is not without it’s own history of vulnerabilities. In 2016 CVE-2016-1681 showed a malformed JPEG2000 image, embedded in a PDF, could achieve code execution on the endpoint. The vulnerability was present in the OpenJPEG library that was used by PDFium to handle JPEG2000 files. It was swiftly rectified by Google with a patch being issued.
At face value, the low number of vulnerabilities in Chrome’s PDF viewing solution suggest it’s a superior approach for viewing PDFs. It certainly reduces risk, on account of the reduced functionality available in PDFium, and this is the most tangible security benefit.
The fact the Chrome PDF vulnerability sat not within PDFium, but within the OpenJPEG codec dependency, and both of these dependencies were open-source, does potentially underline the reduced control Google had over the situation. In reality it turned out Google had a patch issued quickly, though it does highlight the importance of evaluating the supply chain underlying a product and whether that fits within corporate risk appetites.
Google Chrome is therefore a sensible application for PDF file viewing, and should be configured as the default application for PDF viewing.
Other countermeasures should reflect a sensible blend of preventative and detective technical capabilities. Inbound email should be filtered, and ideally analysed by a content-inspecting scanner at the boundary. Endpoint AV and anti-malware solutions are also a must. Attempt to disrupt any endpoint compromise by investing in least-privilege firewall rulesets and a mandated web proxy with dynamic blacklist updates. So, in the event something malicious does get a foothold on your endpoint, it has to interact with a detective and preventative control in the form of a good web proxy.