Nicholas L

On a note, if using our tool (FireEye linked above), make sure to keep updating as actors are actively trying to evade it.

This got more clear with a blog later in the day. https://securelist.com/chrome-0-day-exploit-cve-2019-13720-used-in-operation-wizardopium/94866/

https://www.zdnet.com/article/halloween-scare-google-discloses-chrome-zero-day-exploited-in-the-wild/ Its not clear if there is actual exploitation or just that an exploit exists...

This is probably getting to deep, but any indication of actual exploitation vs scanning?

Another good resource on this came out the 9th. https://devco.re/blog/2019/08/09/attacking-ssl-vpn-part-2-breaking-the-Fortigate-ssl-vpn/

https://twitter.com/MalwareTechBlog/status/1162034211672358914?s=20https://twitter.com/MalwareTechBlog/status/1162034211672358914?s

For reasons that are as convoluted as they get, I often have to score things in CVSSv2. Which raises an awful amount questions. One of those questions is always around Access Vector. The CVSSv2 specification [1] states that the metric value of "Network" is: The question that inevitably arises is if you should score a vulnerability that can be conducted remotely via user interaction as "Network". For example, a user downloads a malicious file and opens it or opens an attachment...etc. Should be an easy "No" right? The problem lies further in the specification documents. Scoring Tip #6 states: This scoring tip directly contradicts the definition laid out by the specification. Because: A malicious file is not bound by the network stack, it can be delivered via USB, created on the vulnerable document, etc... Attacker requires local access and is gaining that access through the complicit user In CVSSv3 the definition was tightened and this type of a vulnerability was clearly indicated to be "Local" but they made the issue worse for CVSSv2 by stating [2]: That confusion wouldn't have existed if they didn't contradict their "Network" definition in supplemental "Scoring Tips". In CVSSv3 and now v3.1, the definition has been expanded but still uses some of the same language. The metric was actually renamed to "Attack Vector" vs "Access Vector" though these are still often mixed up in many vulnerability disclosure reports/articles. So I guess, there are three takeaways I hope one will get from this: Don't be surprised if CVSSv2 has something as Network and v3 has the same vuln as Local. If you are converting between the two, please know the difference. The definition of the metric should be final word, don't change the meaning of the metric in supplemental documentation. If you are a security practitioner, developer of scanning software, or just generally rating/discussing vulnerabilities using CVSS please move to v3 or v3.1 already. And yes I know, they are both flawed in their own ways. -Nicholas [1] https://www.first.org/cvss/v2/guide [2] https://www.first.org/cvss/v3.0/user-guide

Imho, having a honeypot that is open to too many things generates an insane amount of noise. Of course if your monitoring/triage can deal with that, its not a concern. However, for me, it seems to make getting full understanding of what is going on a more difficult task.

Yeah I jumped on that bandwagon after you first mentioned it. Has been good call so far.

And the exploit watch begins again.

On that note, it doesn't seem to have a place to add the last name?

Hello, I'm Nicholas. Currently a Senior Vulnerability and Exploitation Analyst at a large-ish US-based security firm. Previously, I've have filled many different roles in several organizations. I develop and run www.linuxkernelcves.com on the side. I "enjoy" attempting to get boards/decision makers to care about things they don't fully understand and have a hard time quantifying. (aka infosec)