Tag Archives: patch

Last Week’s Security news: Exploits for ForgeRock, vSphere, Apache Tomcat, new Print Spooler vuln, Kaseya Patch and REvil, SolarWinds, Schneider Electric, Bulletins

Leave a reply

Last Week’s Security news: Exploits for ForgeRock, vSphere, Apache Tomcat, new Print Spooler vuln, Kaseya Patch and REvil, SolarWinds, Schneider Electric, Bulletins. Hello guys! The fourth episode of Last Week’s Security news, July 12 – July 18.

I would like to start with some new public exploits. I think these 4 are the most interesting.

  • If you remember, 2 weeks ago I mentioned the ForgeRock Access Manager and OpenAM vulnerability (CVE-2021-35464). Now there is a public RCE exploit for it. ForgeRock OpenAM server is a popular access management solution for web applications. Michael Stepankin, Researcher: “In short, RCE is possible thanks to unsafe Java deserialization in the Jato framework used by OpenAM”. And now this vulnerability is Under Active Attack. “The [Australian Cyber Security Centre] has observed actors exploiting this vulnerability to compromise multiple hosts and deploy additional malware and tools,” the organization said in an alert. ACSC didn’t disclose the nature of the attacks, how widespread they are, or the identities of the threat actors exploiting them”.
  • A new exploit for vSphere Client (CVE-2021-21985). The vSphere Client (HTML5) contains a remote code execution vulnerability due to lack of input validation in the Virtual SAN Health Check plug-in which is enabled by default in vCenter Server. A malicious actor with network access to port 443 may exploit this issue to execute commands with unrestricted privileges on the underlying operating system that hosts vCenter Server.
  • Apache Tomcat 9.0.0.M1 – Open Redirect (CVE-2018-11784). “When the default servlet in Apache Tomcat […] returned a redirect to a directory […] a specially crafted URL could be used to cause the redirect to be generated to any URI of the attackers choice”.
  • Apache Tomcat 9.0.0.M1 – Cross-Site Scripting (CVE-2019-0221). “The SSI printenv command in Apache Tomcat […] echoes user provided data without escaping and is, therefore, vulnerable to XSS”. However, in real life this is unlikely to be used. “SSI is disabled by default. The printenv command is intended for debugging and is unlikely to be present in a production website”.

Continue reading →

Last Week’s Security news: PrintNightmare patches and Metasploit, Kaseya CVEs, Morgan Stanley Accellion FTA, Cisco BPA and WSA, Philips Vue PACS, CISA RVAs, Lazarus job offers

1 Reply

Last Week’s Security news: PrintNightmare patches and Metasploit, Kaseya CVEs, Morgan Stanley Accellion FTA, Cisco BPA and WSA, Philips Vue PACS, CISA RVAs, Lazarus job offers. Hello guys! The third episode of Last Week’s Security news, July 5 – July 11. There was a lot of news last week. Most of them was again about PrintNightmare and Kaseya.

The updates for PrintNightmare (CVE-2021-34527) were finally released mid-week. It became possible not only to disable the service, but also to update the hosts. This is especially important for desktops that need to print something. But the problem is that these patches can be bypassed. “If you have a system where PointAndPrint NoWarningNoElevationOnInstall = 1, then Microsoft’s patch for #PrintNightmare CVE-2021-34527 does nothing to prevent either LPE or RCE”. Microsoft has updated their security update guide after that: “if you set this reg key to = 1 then the system is vulnerable by design”. It seems that solving this problem requires hardening and registry monitoring.

Continue reading →

Vulnerability Management vendors and Vulnerability Remediation problems

1 Reply

Vulnerability Management vendors and Vulnerability Remediation problems. It’s not a secret, that Vulnerability Management vendors don’t pay much attention to the actual process of fixing vulnerabilities, that they detect in the infrastructure (Vulnerability Remediation). Although it seems to be the main goal of VM products: to make vulnerabilities fixed and whole IT infrastructure more secure, right?

In fact, most of VM vendors see their job in finding a potential problem and providing a link to the Software Vendor’s website page with the remediation description. How exactly the remediation will be done is not their business.

Vulnerability Management vendors and Vulnerability Remediation

The reason is clear. Remediation is a painful topic and it’s difficult to sell it as a ready-made solution. And even when Vulnerability Vendors try to sell it this way, it turns out pretty ugly and does not really work. Mainly because the Remediation feature is sold to the Security Team, and the IT Team will have to use it.

Continue reading →

Guinea Pig and Vulnerability Management products

12 Replies

Guinea Pig and Vulnerability Management products. IMHO, security vendors use the term “Vulnerability Management” extremely inaccurate. Like a guinea pig, which is not a pig and is not related to Guinea, the current Vulnerability Management products are not about the actual (practically exploitable) vulnerabilities and not really about the management.

Guinea Pig and Vulnerability Management

Vulnerability should mean something solid and reliable, something that can be practically used by a malicious attacker or penetration tester.

When (so-called) Vulnerability Management vendors start working with indirect information from third-party about potential vulnerabilities in the software, that were possibly exploited by someone in some unknown conditions, or simply distance from responsibility: “we just provide information from the software vendor; software vendor knows better about the vulnerabilities in his own products”, it’s all falling into to the area of fortune telling and counting angels on the head of a pin.

Hardcore process of identifying weaknesses that real-life attackers can use moves to a boring compliance. For example, as PCI DSS requires, there should be no vulnerabilities above medium level (CVSS Base score > 4). At the same time, no one cares how fair this assessment of criticality is or how real these vulnerabilities are. All the analytics build on such formal data loses its sharpness and practical value.

Continue reading →

Psychological Aspects of Vulnerability Remediation

8 Replies

Psychological Aspects of Vulnerability Remediation. In my opinion, Remediation is the most difficult part of Vulnerability Management process. If you know the assets in your organization and can assess them, you will sooner or later produce a good enough flow of critical vulnerabilities. But what the point, if the IT team will not fix them?

Kübler-Ross model and Tsunami of Vulnerability Tasks

Kübler-Ross model and Tsunami of Vulnerability Remediation Tasks

Just think about it. The only thing that your colleagues from  IT team see is an unexpected  tsunami of the patching tasks. They most likely don’t understand WHY they should do it. They most likely don’t know about the concepts of Attack Surface minimization and Attack Cost maximization. From their point of view it’s just some stupid requirements from InfoSec team imposed with only one goal – to make their life miserable.

So, they may think that denial and pushing back can solve all their problems. And, frankly, this may work. There are countless ways to sabotage Vulnerability Remediation. Most main and common are the following:

  • I don’t understand how to patch this.
  • I already patched this, there should be a false positive in the scanner.
  • Why should we patch this? The vulnerability is not exploitable. Or it is exploitable in theory, but not exploitable in our particular infrastructure. Or this server is not critical and, even if it will be compromised, there won’t be a huge impact. So, we will not patch it.

In each individual case Vulnerability Analyst can describe and proof his point, but doing this for each vulnerability will require insane amount of time and efforts and will paralyze the work. It is basically the Italian strike or work-to-rule.

Continue reading →