Stories
Slash Boxes
Comments

SoylentNews is people

posted by janrinok on Tuesday February 21, @11:41AM   Printer-friendly
from the patch-grief-with-proverbs-but-patch-software-with-fixes dept.

Majority of Ransomware Attacks Last Year Exploited Old Bugs:

Many vulnerabilities that ransomware operators used in 2022 attacks were years old and paved the way for the attackers to establish persistence and move laterally in order to execute their missions.

The vulnerabilities, in products from Microsoft, Oracle, VMware, F5, SonicWall, and several other vendors, present a clear and present danger to organizations that haven't remediated them yet, a new report from Ivanti revealed this week.

Ivanti's report is based on an analysis of data from its own threat intelligence team and from those at Securin, Cyber Security Works, and Cyware. It offers an in-depth look at vulnerabilities that bad actors commonly exploited in ransomware attacks in 2022.

Ivanti's analysis showed that ransomware operators exploited a total of 344 unique vulnerabilities in attacks last year—an increase of 56 compared to 2021. Of this, a startling 76% of the flaws were from 2019 or before. The oldest vulnerabilities in the set were in fact three remote code execution (RCE) bugs from 2012 in Oracle's products: CVE-2012-1710 in Oracle Fusion middleware and CVE-2012-1723 and CVE-2012-4681 in the Java Runtime Environment.

Srinivas Mukkamala, Ivanti's chief product officer, says that while the data shows ransomware operators weaponized new vulnerabilities faster than ever last year, many continued to rely on old vulnerabilities that remain unpatched on enterprise systems.

"Older flaws being exploited is a by-product of the complexity and time-consuming nature of patches," Mukkamala says. "This is why organizations need to take a risk-based vulnerability management approach to prioritize patches so that they can remediate vulnerabilities that pose the most risk to their organization."

Among the vulnerabilities that Ivanti identified as presenting the greatest danger were 57 that the company described as offering threat actors capabilities for executing their entire mission. These were vulnerabilities that allow an attacker to gain initial access, achieve persistence, escalate privileges, evade defenses, access credentials, discover assets they might be looking for, move laterally, collect data, and execute the final mission.

The three Oracle bugs from 2012 were among 25 vulnerabilities in this category that were from 2019 or older. Exploits against three of them (CVE-2017-18362, CVE-2017-6884, and CVE-2020-36195) in products from ConnectWise, Zyxel, and QNAP, respectively, are not currently being detected by scanners, Ivanti said.

[...] Notably, 131 of the 344 flaws that ransomware attackers exploited last year are not included in the US Cybersecurity and Infrastructure Security Agency's closely followed Known Exploited Vulnerabilities (KEV) database. The database lists software flaws that threat actors are actively exploiting and which CISA assesses as being especially risky. CISA requires federal agencies to address vulnerabilities listed in the database on a priority basis and usually within two weeks or so.

"It's significant that these aren't in CISA's KEV because many organizations use the KEV to prioritize patches," Mukkamala says. That shows that while KEV is a solid resource, it doesn't provide a full view of all the vulnerabilities being used in ransomware attacks, he says.

Ivanti found that 57 vulnerabilities used in ransomware attacks last year by groups such as LockBit, Conti, and BlackCat, had low- and medium-severity scores in the national vulnerability database. The danger: this could lull organizations who use the score to prioritize patching into a false sense of security, the security vendor said.


Original Submission

 
This discussion was created by janrinok (52) for logged-in users only, but now has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 3, Interesting) by bloodnok on Tuesday February 21, @07:35PM

    by bloodnok (2578) on Tuesday February 21, @07:35PM (#1292919)

    You're constantly plugging holes with corks and hoping for the best...

    One of the problems, in my opinion, is the nature of the DMZ. Servers in the DMZ are exposed to the world and are expected to be hardened and to limit access to services in the "secure" part of your network. However, in many cases, servers in the DMZ have almost unlimited access to those internal services.

    Consider database servers: no-one with a clue would put a database server in the DMZ, but they will give a server that is in the DMZ access to almost all of the database's data. If you break into the app server, then you can select, insert, update or delete into or from every table that the app needs access to, and probably a few that it doesn't.

    When explained this simply, this is obviously a bad thing, but almost everyone does it.

    The solution is to make the database provide access to an authenticated user, rather than to the app server, and to limit each user's access to only that data that is relevant to them. That way, if you break in as Alice, Bob's data is still secure.

    Of course, no-one does this. But they could: https://marcmunro.github.io/veil2/html/pt01.html/ [github.io].

    __
    The Major

    Starting Score:    1  point
    Moderation   +1  
       Interesting=1, Total=1
    Extra 'Interesting' Modifier   0  
    Karma-Bonus Modifier   +1  

    Total Score:   3