Do I have to mention the naming of acronyms has gone overboard?
Or, DIHTMTNOAHGO if you will.
Microsoft says it has suspended several third-party developer accounts that submitted malicious Windows drivers for the IT giant to digitally sign so that the code could be used in cyberattacks. In tandem with its Patch Tuesday rollout this week, the tech goliath also revoked certificates used to sign the bad drivers, and …
Meh. This has been going on forever, the key statement is ""In these attacks, the attacker had already gained administrative privileges on compromised systems prior to use of the drivers,". The only thing different here is that there is at least _some_ audit trail due to the signing about who wrote the code.... the fact that Microsoft signed it is less relevant than it sounds (prior to Microsoft signing, this was effectively done by a cross-cert from Microsoft to particular 3rd party CAs... net - same thing).
However, there are _plenty_ of drivers out there that export functions to just about any process to read/write kernel memory, modify/terminate processes etc. For instance, Process Hacker was used to attack Sony Pictures years and years back. Microsoft's own SysInternals procexep.sys can _also_ terminate protected processes via a driver as well (indirectly at least - it can close handles - close the right handle and you can cause a process to exit).
The thing to actually watch out for are drivers that are not actual _device_ (as in hardware) drivers. Software drivers have their uses and there is nothing wrong with them per se... but you should audit them more closely. If you are running a driver from, say a major AV vendor, but you don't use their software... you are probably looking at a problem. Or you have procexp.sys but aren't using procmon. And so on.
Signing does provide security value in several ways - there is an audit chain to some extent - somebody somewhere does in fact have to swear they are up to no good and sign contracts to that effect. Not everything has to be a technical solution. The second way is actually fairly important - it's very difficult to create a polymorphic driver because of the signing requirement - while there are lots of 'bad' drivers and many more abusable drivers out there... the number is not infinite, and you can in fact build effective rulesets around them.
The dystopian part here is that as a driver developer... quite a lot of process to get through to ship some code. Annoying, I don't like it, but I'm not arguing against it either.
Having gone through this process... The vetting is done by a 3rd party CA issuing an EV certificate to the company. That certificate is used to sign submissions to the Microsoft signing process. (before Microsoft did the signing directly, the CA cert was used to sign the drivers since the CA had a Microsoft issued cross-cert). The 'Extended Validation' in an EV cert is... 1) can you pay $400? 2) Do you have an attorney that will attest that you are you and answer a phone call to repeat the same?
I suspect the latter is the weak link since it is not clear how the attorney is vetted as actually being a member of their respective bar association, nor would I trust in professional ethics in all places equally. (see also: the Panama papers). Some number of years back Microsoft was talking about doing the vetting directly and cutting out the 3rd party CAs entirely. Probably a good move, but I've not heard much about it since.
Hey Google ! Are you paying attention ?