And just when I thought replacing all my Adobe Flash controls with Telerik
Who would of thought that a simple add-on control to the Microsoft stack could cause so many problems?
Multiple criminals, including at least potentially one nation-state group, broke into a US federal government agency's Microsoft Internet Information Services web server by exploiting a critical three-year-old Telerik bug to achieve remote code execution. The snafu happened between November 2022 and early January, according to …
If the customer's IT doesn't have their own Telerik annual developer subscription for a few hundred per year then they won't have access to Telerik component updates. And IT may lack the knowledge and build scripts to update, run test scripts and deploy themselves, if the development work was outsourced.
How many business .Net apps will never get updated from .net framework 3.5? We were quoted 40 grand to bring a fairly straightforward internal small business azure hosed application from .net core 4 LTS to .net 6 LTS. No feature changes.
Not sure how I feel about the statement: " And IT may lack the knowledge and build scripts to update, run test scripts and deploy themselves, if the development work was outsourced."
I'd be inclined to call that a failure on management's part, not the guys in IT. Most IT guys would jump at the chance to learn something new and apply it. Then there is the point that if your IT dept isn't trained or don't have the bandwidth or skills, why aren't management employing someone to fill that gap? Again, the finger points back at management.
Add into that your comment "If the customer's IT doesn't have their own Telerik annual developer subscription for a few hundred per year then they won't have access to Telerik component updates." - I'd ask why not? The business surely should have the necessary licences in place to support the tools they are using to do business? If it's outsourced (sigh), then wouldn't such requirements be included in the support contract?
Security is hard at the best of times. We're almost always on the back-foot. But management STILL seem to treat security as an unnecessary expense, right up to the point they get caught out and are facing fines. Until such times as the penalties outweigh the cost of prevention, I don't ever see this changing.
I take the force of your argument, but validating serialized object data is rather more complicated than validating tainted inputs for things like SQL injection.1 Typically with third-party components (or even components developed within the organization by another team) those are just presented to the application developers as opaque blobs. A pen tester, or someone who follows secure-development practices, will often recognize a serialized object (for the languages they're used to working in) and raise a flag, but when a manager says "here, use this component we bought", catching marshalled [sic] pickles can be difficult.
1Of course no application should ever be vulnerable to SQL injection in the first place, because it shouldn't be constructing ad hoc queries but using parameterized statements, stored procedures, or the like. The same goes for command injection, format-string attacks, XSS, and most of the other tainted-data issues. But that doesn't mean input sanitization isn't still a good idea.
"Why the duck would any organisation be using IIS (especially on a public facing site)?"
...because the application vendor only supports IIS? ...it come with Windows and is easy to setup?
"It's a massive pain"
Pain?
"and full of holes. Apache, nginx, lighttpd, etc are much more suited to the role."
All of those products have had multiple security vulnerabilities last year. and some of them have had vulns this year as well.
I think IIS isn't any worse on the hole aspect, but feel free to correct me with some statistics.
Some statistics, courtesy of NVD searches. IIS: 178 CVEs. Apache httpd: 289 CVEs. nginx: 39 CVEs.
So Apache httpd does indeed have quite a lot more published vulnerabilities, but nginx has much fewer. On the other hand, Apache is much more widely used (40% versus 11% for IIS), so we can expect more attention paid to it. On the other other hand, nginx has a bigger market share than IIS too, and while nginx is a much newer and less stovepiped code base than Apache httpd and has a lot fewer features, it's not at all clear that it really has only 13% as many flaws as Apache.
In short, statistics like these are meaningless. And what's likely far more important in practice is how likely an organization is to configure the server properly, and many components factor into that.