Tag Archives: Juniper

August 2023: GitHub PoCs, Vulristics, Qualys First-Party, Tenable ExposureAI, SC Awards and Rapid7, Anglo-Saxon list, MS Patch Tuesday, WinRAR, Juniper

Hello everyone! This month I decided NOT to make an episode completely dedicated to Microsoft Patch Tuesday. Instead, this episode will be an answer to the question of how my Vulnerability Management month went. A retrospection of some kind.

Alternative video link (for Russia): https://vk.com/video-149273431_456239134

GitHub exploits and Vulristics

This month I made some improvements to my Vulristics vulnerability prioritization tool. These changes relate to the use of exploit data on Github. We all know that exploits are often posted on GitHub. But how adequate is this source in order to evaluate the exploitability?

Continue reading

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

Divination with Vulnerability Database

Today I would like to write about a popular type of “security research” that really drives me crazy: when author takes public Vulnerability Base and, by analyzing it, makes different conclusions about software products or operating systems.

CVE Numbers their occult power and mystic virtues

The latest research of such type, was recently published in CNews – a popular Russian Internet portal about IT technologies. It is titled ““The brutal reality” of Information Security market: security software leads in the number of holes“.

The article is based on Flexera/Secunia whitepaper. The main idea is that various security software products are insecure, because of amount of vulnerability IDs related to this software existing in Flexera Vulnerability Database. In fact, the whole article is just a listing of such “unsafe” products and vendors (IBM Security, AlienVault USM and OSSIM, Palo Alto, McAfee, Juniper, etc.) and the expert commentary: cybercriminals may use vulnerabilities in security products and avoid blocking their IP-address; customers should focus on the security of their proprietary code first of all, and then include security products in the protection scheme.

What can I say about these opuses of this kind?

They provide “good” practices for software vendors:

  • Hide information about vulnerabilities in your products
  • Don’t release any security bulletins
  • Don’t request CVE-numbers from MITRE for known vulnerabilities in your products

And then analysts and journalists won’t write that your product is “a leader in the number of security holes”. Profit! 😉

Continue reading