If you're a typical HN person, this list isn't going to be especially useful to you; it's basically collecting statistics about specific CVEs that are seen exploited in the wild, and those are heavily, heavily biased towards corporate IT infrastructure.
There are already so many startups in this space. I suspect the solution isn’t more/better technology, but taking away people’s ability to operate IT services through higher insurance premiums.
I doubt it's even possible for a 'disruptor' to fix it - It's not a problem with products or services, it's a culture problem. Corporate IT has basically become the technical counterpart to middle management. Responsibility goes up the food chain to people who don't understand the problems, blame goes down to the front-line technicians, contractors, and often vendors who aren't capable of fixing the problems. We have two generations of Cisco and Microsoft evangelicals with no real understanding of the fundamentals. Certificate-culture has prioritized checkbox quizzes over real learning.
It will take serious culture changes to "fix" the corporate IT industry. Until there are actually consequences for doing unsafe things or using unsafe products, people will continue to take shortcuts.
It is a culture problem, and worse than that -- it's a talent problem. Everyone knows that the world wants and needs ten times as many talented coders as are available, and the vast majority of the time, it just has to get by with untalented ones. In cyber security, the problem is far worse. I would believe if the demand were a hundred times the supply. Big, important, sexy-on-a-resume organizations have a hard time getting enough cyber security talent to be actually effective. God help people who process meat or transport oil for a living.
My guess is that the reason it's a culture problem is that it's a talent problem. Some big, scary thing that no one knows how to effectively solve is going to result in everyone working to avoid blame rather than solve the problem. And organizations that have to get by with extremely bottom feeder security talent wind up with extremely bottom feeder security knowhow, processes, and intuition.
If you can figure out a way to effectively productize defensive security, that seems to me like a great way to print money. Unfortunately, the problem is that your customers are not good at thinking about security and can't afford to be (and are distracted by trying to solve their actual business problems), and your adversaries are extremely resourceful, persistent, and motivated. Even when great tools are out there, people often fail to use them or break the security in some silly way. For example, in theory, keeping systems patched is a solved problem -- use one of the automated patch managers out there. In practice, doing so correctly is a pretty tall order for a lot of people, and isn't actually easier than creating and carefully following an effective manual procedure. And in actual practice, the problem never was putting in the effort to get to the systems and run the updates, and it never was setting up a patch manager -- organizations getting caught by these common CVEs often do neither. The problem all along was knowing that patching is important important, not just one of a hundred security checkboxes that you'll never check all of. I really don't know how you would productize that. (And in actual actual practice, sometimes patch managers get hacked. Most meaningful security problems sound stupid but are actually hard.)
There have been many efforts over the years at making security idiot-proof in some domain or another, some more successful than others. If you see an angle, I very much encourage you to go for it. Just remember to test your solution on quality idiots. And remember that you are competing with charlatans to sell real medicine to idiots.
It is cultural first and foremost. The lack of talent is an outcome of culture. I'm sure many programmers will specialize and spend time to become security experts if they will be appreciated better and have faster growth. Why waste time and effort to learn something deeply if all the recruiters and managers care about is certification and check boxes.
Why use "heavily biased" to characterize the most common entry points for recent state espionage operations and ransomware attacks.
These ARE the most routinely exploited vulnerabilities.
Attacks on end-consumers usually rely on social engineering, not vulnerability exploitation, especially because Windows, Mac, and Linux has been heavily fortified against basic exploits.
Most of the CVEs on the linked list are corporate gear running the same firmware since the 2000s, which explains why these devices are so heavily targeted right now. Easy exploits, large payouts, win!
I'm not making a value judgement. The list of most commonly-observed exploit vectors is probably interesting on its own merits. But the headline is "Top Routinely Exploited Vulnerabilities", and, if you're a tech startup, these are almost certainly not the most commonly-exploited vulnerabilities in your environment.
You're not making any sense. Do you think tech startups don't use edge devices? Also, since when are tech startups, which account only for a fraction of the economy, the barometer for anything. They're an outlier in an ocean of multiple industry verticals that usually account for most of the GDI and today's employment. The joint advisory is about attacks overall, not tech startups. Trust me when I say that tech startups use gear listed in that advisory. Unless your idea of a tech startup is a mom-and-pop shop that can't afford to run an AD or intranet -- which most do, and are usually using VPNs and network access gateways to control traffic to it, hence potentially vulnerable.
I can see usefulness here as I do manage IT infra at work.. But i do agree its totally different than the Exploits i see attemtpted on my home IPS (which are mostly Netgear, D-Link PHP, webexploit/injections, and camera exploit attempts.)
Probably not too many on HN using Drupal, for example. It's an odd-ball CMS that got implemented by a bunch of government agencies a decade or so ago (and most of them probably haven't been patched since).
Yeah, that caught me by surprise. Based on the title, I was expecting something more like the OWASP top 10 -- something I could consult while doing a security review of a web application I'm developing.
Two of the Microsoft CVEs (CVE-2017-11882, CVE-2020-0787) on this list are listed as "Exploitation Less Likely" if you view Microsoft's own info for those CVEs. I guess you can't trust the vendor to determine how exploitable a vulnerability is?
> I guess you can't trust the vendor to determine how exploitable a vulnerability is?
Not Microsoft at least. Most vendors, and the percentage grows with the size of the vendor, are very coy about it. And I get it: it doesn't look great for your shareholders, and it gets to a point where yes really you should be ashamed (looking at HP Data Protector here (note the irony)), but if you own it up and also put countermeasures and hardening in place then really everyone is going to feel like they got their money's worth in the end. If instead you hide vulnerabilities, not mention them in changelogs so we can't even check which version is fixed or anything, yeah we'll be recommending the client to look at alternatives. (Though it's not us security consultants that ever recommended a sysadmin to put a proprietary VPN in place in the first place, but then there's more at play than purely the security aspect.)
Microsoft's advantage, of course: try getting out of that ecosystem if you have everyone implicitly trained in using Outlook and Windows. Microsoft gets to do with their advisories whatever the hell they like.
Exploitation not being likely after installing the patch is like saying you're not likely to fall if you lie down first.
But yes, of course the #1 recommendation is for our clients to Always Install Patches Immediately. Always. And they never ever do it. For comparison, though, OpenSSH needed to be updated for a critical vulnerability last in... 2002, maybe? Secure protocols can be done, so it's not only the people not installing updates that are to blame here.
Exploitation likeliness after patch doesn't really make sense. maybe you're reading it wrong? See the page for yourself.
Exploitation unlikely at the time of exploit discovery.
A patch has been released.
This means, the reason why it shows up on the list is because people are running unpatched software. And it's really alarming because the 2017 CVE is for Office 2007 that's ~15 years old (with a patch available!).
Then I'm not sure what you meant to say about the patch being available and thus the problem just being not updating. The "exploitation not likely" statement is simply wrong if it's in the top list of this agency right?
Replying to your edit:
> that's ~15 years old (with a patch available!)
I haven't looked into this one, but you mention it's a 2017 CVE. That means the vuln was discovered (not even necessarily patched and disclosed) in 2017 and not 15 years ago. The age of the product isn't the same as how fast they install security updates (but yeah apparently 2-3 years depending on the exact timeline (the stats are from 2020), so that's practically never).
>> I haven't looked into this one, but you mention it's a 2017 CVE. That means the vuln was discovered (not even necessarily patched and disclosed) in 2017 and not 15 years ago.
Sure, but it's a CVE for a 15 year old software. At this point, running 15 year old software unpatched on machines connected to internet is just negligence on user's part. Maybe we do need forced updates as default.
Anecdote: latest set of windows patches did something to Bluetooth, such that when I switch my mouse between machines there's up to a 3 second lag before the cursor is responsive. Big deal, minor nuisance, right? Except if I'm in a Fullscreen application, it causes a blue screen because the os waiting for the mouse to handshake pauses the GPU for some reason, and the GPU-Windows framework panics and blue screens to prevent hardware damage. This has the side effect of corrupting the application that was running during the blue screen, sometimes forcing a reinstall.
I have no idea what patch it was that caused this, nor can I really expect anyone to fix it, how often are most(98%?) users connecting and disconnecting their mouse every day? I'm switching it dozens of times an hour.
Do you have a picture of the bluescreen or was the crash recently?
Since Vista GPU hangs or TDRs don't cause blue screen. It's likely something else that's causing your system to hangup on bluetooth connections. Your best bet is to file a feedback hub bug, if enough people are facing it - our tools will flag either the update or the device drivers identified as common in crash dumps.
If you're keen, I could take a look at your crash dump file. My email is firstname.lastname@microsoft.com (you'll find me at github.com/zeusk)
Microsoft is not managing vulnerability exploit likelihood for their shareholders. Different vendors are more or less conservative about how they rate exploit severity, and nobody is more conservative than the major open source projects, where any memory corruption vulnerability, even if it's a read-only NULL deref, is rated "possible code execution".
You don't deserve the downvotes, but it's worth noting that well known and often exploited vulnerabilities are still, well, exploited, while the planes that came back and were inspected for bullet holes were the ones that were not taken down.
But your point still stands: Even if you are more likely to be hit by one of the vulnerabilities in the list (big dragnet operations are more likely to have used them, and it's easier for other attackers to copy existing and known exploits), it would be absolutely bad to think the lesser known ones are less dangerous. You don't want to be in the first few batches of the lesser known bug's journey to become one of the well known ones...
Generally patch your stuff, basically. Even going by severity instead of popularity is not foolproof, other comments already pointed out how that severity has apparently been misassessed for bugs on this very list.
The vast majority of our computing infrastructure is not actively and forensicly monitored; vulns are either actively patched out, accidently patched out, or 'reset' when services/servers are rolled (often due to "misbehaviour", be it a desktop by a user or a server by a tech), leaving no trace that they were exploited. The vast majority of vendors and sysadmins are incentivised not to reveal that they had an exploit, often by reclassification (exploit -> bug), failure to inform, or refusal to detect.
I think this is what the parent meant by "I'd assert that a good fraction of exploits are never caught/analyzed.".
Afaict as an outsider we account for this with honeypots, which should give us some kind of estimation at least.
What sorts of honeypots are available these days? In 2018 I wandered into honeypots again and windows was the primary host OS for most of them. That's not necessarily and issue, but the rest seemed abandoned or unfinished.
On our subnet I was seeing a couple thousand cve exploits a month, and about the same in "unknown probes" that may or may not have been 0-days. I don't have (or want) access to the entire flows through the main gateway, but setting up a few honeypots with public IP is fine by me.
> Making any decision based on this would be similar to examining warplanes for sign of bullets to determine which parts to reinforce.
I think that’d be great advice, if most current “enterprise software” deployments didn’t have bright flashing strobe lights directly mounted to the un armoured fuel tanks and cockpit blinking out “shoot here to kill” in Morse code.
Once your attack surface doesn’t reveal multiple ways you can be trivially exploited using readily available tools like Shodan and metasploit, then maybe start looking at the places the bullets haven’t hit…
I'm not sure about the point you're trying to make.
The famous reference is about Abraham Wald looking at all of the common places that planes didn't get shot. That's where you put the armor. And it was really effective. (there's another good one about helmets).
Maybe you're saying, yes it's embarrassing to have some static content hosted on some random cloud instance get compromised - but that's clearly not fatal. You have finite resources to devote to security, so pick your battles.
But I think you're saying something else. I don't quite get it.
I'm saying that the sample here is very much biased towards exploits which were detected and analyzed.
Very often, whenever something looks wrong it's just routine to reset and restore.
This is even more common nowadays with clouds made of stateless containers.
I don't think there's as much survivorship bias as you're suggesting - we do, in fact, have the airplane wreckage to inspect, it is just that frequently after-action forensices doesn't happen. But the point is valid.
I think lists like these are primarily useful for evaluating how unfamiliar networks are managed - if you spot anything on the list, likely some bot or volunteer-sysadmin already beat you to it.
And if your scanner doesn't know to look for something on the list, it is probably time to renew your support contract or find a new tool.
From just having skimmed the top of the linked article… I think the conclusion to draw is that “enterprise focused” security advice pretty mush ignores the existence of Apple devices and oses. They’re not part of the gravy train of enterprise 3rd party security billing.
Except that every corporate BYOD user is syncing all of their photos effectively unencrypted (including work related stuff) to iCloud, as well as all of their work chats (also effectively unencrypted) to iCloud Backup via their personal Apple ID.
Pretending that all of the work stuff happens on the work laptop is a bit silly.
42 comments
[ 2.1 ms ] story [ 162 ms ] threadIt will take serious culture changes to "fix" the corporate IT industry. Until there are actually consequences for doing unsafe things or using unsafe products, people will continue to take shortcuts.
My guess is that the reason it's a culture problem is that it's a talent problem. Some big, scary thing that no one knows how to effectively solve is going to result in everyone working to avoid blame rather than solve the problem. And organizations that have to get by with extremely bottom feeder security talent wind up with extremely bottom feeder security knowhow, processes, and intuition.
If you can figure out a way to effectively productize defensive security, that seems to me like a great way to print money. Unfortunately, the problem is that your customers are not good at thinking about security and can't afford to be (and are distracted by trying to solve their actual business problems), and your adversaries are extremely resourceful, persistent, and motivated. Even when great tools are out there, people often fail to use them or break the security in some silly way. For example, in theory, keeping systems patched is a solved problem -- use one of the automated patch managers out there. In practice, doing so correctly is a pretty tall order for a lot of people, and isn't actually easier than creating and carefully following an effective manual procedure. And in actual practice, the problem never was putting in the effort to get to the systems and run the updates, and it never was setting up a patch manager -- organizations getting caught by these common CVEs often do neither. The problem all along was knowing that patching is important important, not just one of a hundred security checkboxes that you'll never check all of. I really don't know how you would productize that. (And in actual actual practice, sometimes patch managers get hacked. Most meaningful security problems sound stupid but are actually hard.)
There have been many efforts over the years at making security idiot-proof in some domain or another, some more successful than others. If you see an angle, I very much encourage you to go for it. Just remember to test your solution on quality idiots. And remember that you are competing with charlatans to sell real medicine to idiots.
These ARE the most routinely exploited vulnerabilities.
Attacks on end-consumers usually rely on social engineering, not vulnerability exploitation, especially because Windows, Mac, and Linux has been heavily fortified against basic exploits.
Most of the CVEs on the linked list are corporate gear running the same firmware since the 2000s, which explains why these devices are so heavily targeted right now. Easy exploits, large payouts, win!
I can see usefulness here as I do manage IT infra at work.. But i do agree its totally different than the Exploits i see attemtpted on my home IPS (which are mostly Netgear, D-Link PHP, webexploit/injections, and camera exploit attempts.)
Not Microsoft at least. Most vendors, and the percentage grows with the size of the vendor, are very coy about it. And I get it: it doesn't look great for your shareholders, and it gets to a point where yes really you should be ashamed (looking at HP Data Protector here (note the irony)), but if you own it up and also put countermeasures and hardening in place then really everyone is going to feel like they got their money's worth in the end. If instead you hide vulnerabilities, not mention them in changelogs so we can't even check which version is fixed or anything, yeah we'll be recommending the client to look at alternatives. (Though it's not us security consultants that ever recommended a sysadmin to put a proprietary VPN in place in the first place, but then there's more at play than purely the security aspect.)
Microsoft's advantage, of course: try getting out of that ecosystem if you have everyone implicitly trained in using Outlook and Windows. Microsoft gets to do with their advisories whatever the hell they like.
So it's more like victims not updating their software.
But yes, of course the #1 recommendation is for our clients to Always Install Patches Immediately. Always. And they never ever do it. For comparison, though, OpenSSH needed to be updated for a critical vulnerability last in... 2002, maybe? Secure protocols can be done, so it's not only the people not installing updates that are to blame here.
Exploitation unlikely at the time of exploit discovery.
A patch has been released.
This means, the reason why it shows up on the list is because people are running unpatched software. And it's really alarming because the 2017 CVE is for Office 2007 that's ~15 years old (with a patch available!).
Replying to your edit:
> that's ~15 years old (with a patch available!)
I haven't looked into this one, but you mention it's a 2017 CVE. That means the vuln was discovered (not even necessarily patched and disclosed) in 2017 and not 15 years ago. The age of the product isn't the same as how fast they install security updates (but yeah apparently 2-3 years depending on the exact timeline (the stats are from 2020), so that's practically never).
Sure, but it's a CVE for a 15 year old software. At this point, running 15 year old software unpatched on machines connected to internet is just negligence on user's part. Maybe we do need forced updates as default.
Anecdote: latest set of windows patches did something to Bluetooth, such that when I switch my mouse between machines there's up to a 3 second lag before the cursor is responsive. Big deal, minor nuisance, right? Except if I'm in a Fullscreen application, it causes a blue screen because the os waiting for the mouse to handshake pauses the GPU for some reason, and the GPU-Windows framework panics and blue screens to prevent hardware damage. This has the side effect of corrupting the application that was running during the blue screen, sometimes forcing a reinstall.
I have no idea what patch it was that caused this, nor can I really expect anyone to fix it, how often are most(98%?) users connecting and disconnecting their mouse every day? I'm switching it dozens of times an hour.
Since Vista GPU hangs or TDRs don't cause blue screen. It's likely something else that's causing your system to hangup on bluetooth connections. Your best bet is to file a feedback hub bug, if enough people are facing it - our tools will flag either the update or the device drivers identified as common in crash dumps.
If you're keen, I could take a look at your crash dump file. My email is firstname.lastname@microsoft.com (you'll find me at github.com/zeusk)
Making any decision based on this would be similar to examining warplanes for sign of bullets to determine which parts to reinforce.
I'd assert that a good fraction of exploits are never caught/analyzed.
But your point still stands: Even if you are more likely to be hit by one of the vulnerabilities in the list (big dragnet operations are more likely to have used them, and it's easier for other attackers to copy existing and known exploits), it would be absolutely bad to think the lesser known ones are less dangerous. You don't want to be in the first few batches of the lesser known bug's journey to become one of the well known ones...
Generally patch your stuff, basically. Even going by severity instead of popularity is not foolproof, other comments already pointed out how that severity has apparently been misassessed for bugs on this very list.
The vast majority of our computing infrastructure is not actively and forensicly monitored; vulns are either actively patched out, accidently patched out, or 'reset' when services/servers are rolled (often due to "misbehaviour", be it a desktop by a user or a server by a tech), leaving no trace that they were exploited. The vast majority of vendors and sysadmins are incentivised not to reveal that they had an exploit, often by reclassification (exploit -> bug), failure to inform, or refusal to detect.
I think this is what the parent meant by "I'd assert that a good fraction of exploits are never caught/analyzed.".
Afaict as an outsider we account for this with honeypots, which should give us some kind of estimation at least.
On our subnet I was seeing a couple thousand cve exploits a month, and about the same in "unknown probes" that may or may not have been 0-days. I don't have (or want) access to the entire flows through the main gateway, but setting up a few honeypots with public IP is fine by me.
I think that’d be great advice, if most current “enterprise software” deployments didn’t have bright flashing strobe lights directly mounted to the un armoured fuel tanks and cockpit blinking out “shoot here to kill” in Morse code.
Once your attack surface doesn’t reveal multiple ways you can be trivially exploited using readily available tools like Shodan and metasploit, then maybe start looking at the places the bullets haven’t hit…
The famous reference is about Abraham Wald looking at all of the common places that planes didn't get shot. That's where you put the armor. And it was really effective. (there's another good one about helmets).
Maybe you're saying, yes it's embarrassing to have some static content hosted on some random cloud instance get compromised - but that's clearly not fatal. You have finite resources to devote to security, so pick your battles.
But I think you're saying something else. I don't quite get it.
Very often, whenever something looks wrong it's just routine to reset and restore. This is even more common nowadays with clouds made of stateless containers.
I think lists like these are primarily useful for evaluating how unfamiliar networks are managed - if you spot anything on the list, likely some bot or volunteer-sysadmin already beat you to it.
And if your scanner doesn't know to look for something on the list, it is probably time to renew your support contract or find a new tool.
Pretending that all of the work stuff happens on the work laptop is a bit silly.