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.
(Score: 3, Interesting) by Freeman on Tuesday February 21, @03:05PM (2 children)
You're constantly plugging holes with corks and hoping for the best. Sometimes you've got patch over patch that patched the other patch, which introduced unintended side effects. At least that's what it seems like from the outside. As all I do is tell someone else about problems, I don't generally have to fix anything.
Joshua 1:9 "Be strong and of a good courage; be not afraid, neither be thou dismayed: for the Lord thy God is with thee"
(Score: 4, Insightful) by canopic jug on Tuesday February 21, @04:30PM
Bug #1 -- the presence of M$ staff.
That's it in a nutshell. It's a staffing problem because the m$ products are only the symptom. Skilled and/or knowledgeable people eschew broken, complicated, and expensive crap. The process is otherwise just an expensive, time-wasting game of Whac-A-Mole as they play their bosses with the well-worn M$ playbook:
That loops until the money runs out at any of the three excuses.
Clearing the deck of m$ personnel won't in and of itself secure things, nor will sprinkling open source software around be a panacea, but they really are the unavoidable first steps in getting there. Don't take my word for it though. walk through Ken Thompson's ACM lecture [acm.org] from August 1984.
Money is not free speech. Elections should not be auctions.
(Score: 3, Interesting) by bloodnok on Tuesday February 21, @07:35PM
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
(Score: 2) by EvilSS on Tuesday February 21, @04:15PM