Blocking particular process from getting terminated

If the malware is in the kernel, then it can attach to your process, have
access to your memory space, and modify it. At that point your process
image is hosed. Depending on when you filter gets loaded versus the malware
there are ways around the file protection, so I can change your protected
application to be malware.

Malware is going to win 99.9% of the time, you may be able to defeat a
specific threat vector, but then all they need is to improve slightly to
bypass that.

Don Burn
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@gmail.com
Sent: Saturday, October 18, 2014 9:19 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Blocking particular process from getting terminated

First, I agree with you, the malware is going to win 99% of the time as
offense is way easier than defense. But for the sake of educational argument
(as I’m not very farmiliar with this), let’s assume that the infection has
occured after my driver is loaded. The driver protects against file
modification via a minifilter FltRegFilter(), and is also protecting against
process termination via ObRegisterCallbacks(). There’s also another routine
blocking remote threads. The attacker cannot modify any binaries, nor use
Read/WriteProcMem(), no TermProc(), no CreateRemoteThread(), no SSDT hooks,
etc. Apart from offline attacks - how do you destroy my process?


NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

Once again, you are trying to engage in battle that can’t be won.

“Let’s give everybody in the city the same locks and keys. Because that’s very convenient.”

“But how about thieves?”

“We’ll install automated guns with face recognition on each door”

The problem you are trying to solve just DOES NOT EXIST in properly configured enterprise.
Windows gives you user accounts, trusted installer, administrative accounts. Allowing users have administrative accounts is as wise as just running Windows 95.

Well, your only bet here is to ensure that the system DOES NOT get infected, and this is what your software may, indeed, achieve (not by some “super-intelligence” on its own but simply by ensuring that no one is able
to run on the target system, apart from those binaries who were explicitly allowed to do so by the user).
This is known as whitelisting, and it is the only approach to the security that is known to work. Basically, this is just the logical equivalent of EXECUTE access flag, i.e. something that has been present on UNIX-like systems since the inception of UNIX…

However, if user allows some malicious kernel module to get loaded all your future attempts to protect the system are doomed to failure.More on it below…

Apart from offline attacks - how do you destroy my process?

Well, let’s say simply by removing all its KTHREADS/ETHREADs from the list of active threads, effectively rendering all your protection useless and turning it into the oblivion. Similarly, all your executable code can get replaced with the sequence of NOPs; all your hooks can get undone, etc,etc,etc - all these tricks can be done by anyone who gets an access to the kernel address space…

In other words, just keep on repeating “whenever a malicious kernel module gets loaded all my bets are off”
mantra until you finally learn to think of it like of the laws of motion, of thermodynamics, etc…

Anton Bassov

>Once you have malicious software with admin or kernel privileges, the game

is over, and you have lost. There is no solution short of reformatting.<

And I suppose the formatter and the entire software path that executes it
(BIOS, media loader etc) needs to reside on an unalterable certified medium
too. How often does that happen?

Mike

----- Original Message -----
From: Tim Roberts
To: Windows System Software Devs Interest List
Sent: Friday, October 17, 2014 5:47 PM
Subject: Re: [ntdev] Blocking particular process from getting terminated

xxxxx@hotmail.com wrote:

This is true 99% of the cases, the remaining 1% are those cases when a
process is vital for the system infrastructure security such as anti
malwares, IPS and IDS. Those kind of softwares have to protect themself
from malicious software trying to terminate their services and processes
or inject arbitrary code into their executable address space, so that’s
when an appropriate protection is vital.

But the problem is unsolvable. Don’t you see that? Whatever your
process can do, a malicious process can do as well, and can also UNDO.
You can’t make your process bulletproof. It’s impossible. The malware
writers are smarter than you are. Once you have malicious software with
admin or kernel privileges, the game is over, and you have lost. There
is no solution short of reformatting.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.


NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

>And I suppose the formatter and the entire software path that executes it
(BIOS, media loader etc) needs to reside on an unalterable certified medium
too. How often does that happen?

Um, every time you boot from a CD?

Yes, I suppose many machines still have those old CD things… and on those
machines that support them, is the CD boot code always in unmodifiable
memory?

Mike

----- Original Message -----
From: xxxxx@broadcom.com
To: Windows System Software Devs Interest List
Sent: Monday, October 20, 2014 2:54 PM
Subject: RE:[ntdev] Blocking particular process from getting terminated

And I suppose the formatter and the entire software path that executes it
(BIOS, media loader etc) needs to reside on an unalterable certified medium
too. How often does that happen?

Um, every time you boot from a CD?


NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

You can always plug a USB CD drive into a box with secure boot BIOS.

Wait. Did somebody just say “USB” and “secure” in the same sentence… in light of all the recent talk about “badusb”?

Peter
OSR
@OSRDrivers

>Wait. Did somebody just say “USB” and “secure” in the same sentence… in light
of all the recent talk about “badusb”?

It all depends on the context. You need to install your OS somehow on a clean disk. You could do that through PXE (is your L2 network secure?), or through a CD (does your laptop have a CD anymore? Can your secureBoot BIOS boot off a CD?) or from a USB stick (badusb again?). Choose one to match your paranoia level.

> And I suppose the formatter and the entire software path that executes it

(BIOS, media loader etc) needs to reside on an unalterable certified medium
too. How often does that happen?

Windows setup CD is enough, it cannot be altered and everything is digitally signed on it.


Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com

>Windows setup CD is enough, it cannot be altered

…which applies only to the media itself.However, it has to be loaded into the memory, right? Therefore,
if boot firmware is compromized it can alter the loaded image…

and everything is digitally signed on it.

…including the code path that performs integrity check - it can be simply jumped over,and that’s it.

Therefore, Mike’s concern is perfectly valid - all OS-level and installer-level protection can get defeated if boot firmware is compromized, and this is what he speaks about…

Anton Bassov

> As far as I am aware, no malware bothers about attempting this as both requires intimate knowledge

of the BIOS update mechanism, the underlying HW platform, and limits the scope of the attack
to a specific line of HW

Well, Martin, there are quite a few things that you are unaware of, which does not necessarily imply that they do not exist, right. Therefore, “I am unaware of XYZ” is not really an argument - after all, Mr.Kyler does not seem to be aware even of the fact that all OEM computers that he buys are more than likely to be produced in China…

Our story here is more or less the same - the very first thing that gets into my head in context of this topic is the article that I read not so long ago about China-produced PCs. According to this article, a large proportion of PCs that are produced in China get their firmware compromized before even leaving the factory gates - indeed, attackers know the precise details of BIOS of their targets and attack particular production lines. This firmware does not have to do anything malicious on its own - instead, it may act just as a back-door for various “general purpose malware titles”, i.e. provide them with a sort of “installation API”.
Then this computer gets exported to the US. Mr.O’Brian buys it his local Walmart and remains blissfully unaware of the possibilities of firmware-level attacks exactly the same way Mr.Kyler remains blissfully unaware of the origins of his PC …

Anton Bassov

> Our story here is more or less the same - the very first thing that gets into my head in context of this

topic is the article that I read not so long ago about China-produced PCs.

And my story is:

  • some Russian hacker connected to Russian national security discovered the Intel’s server motherboards (on which the brand-name servers are usually based) have the hidden secret hypervisor in their BIOS (so that even the primary OS runs as a guest. Yes, Intel’s virtualization HW supports nested hypervisors).
  • the code of this hypervisor is related to BMC (KVP over IP, like Dell’s iDRAC) code, which is encrypted to the degree it cannot be investigated to 3rd parties.
  • Intel’s official opinion on this is “some remote mgmt features related to BMC”.
  • more so. Canadian beta versions of the boards have no such hidden hypervisor, but Chinese released boards have one.

As everybody can understand, this means the code of arbitrary complexity (limited by the BIOS chip size, which is rather large) always running on your server next to being totally transparent to your OS. Also, there is no possibilities of researching this code. Also, the code is added late in the design stage, the board is debugged without it.

I can understand this can be some remote mgmt. Probably some “remote mgmt” for NSA. Remember Snowden?

This by far surpasses the potential malicious UEFI boot apps. First of all, such an app can hardly be this well-encrypted. Second, it can hardly run in parallel with the booted OS without the OS being aware of this.

Compared to this issue, the BadUSB issue “nervously smokes at side”. The user will surely notice the fake keystrokes from the flash-drive-imposting-a-keyboard. Not so with a 2nd guest of the hidden hypervisor.


Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com

> And my story is: - some Russian hacker connected to Russian national security discovered…

Do you somehow realize that making a reference to such a source immediately invalidates whatever
follows this reference in the eyes of any more or less reasonable Western reader, and makes him/her dismiss it just as a complete, utter bollocks, probably without even being bothered to read it further???
I would say that your chances of being taken seriously are comparable to those of someone who refers to David Icke et al while speaking to educated and mentally stable people. There is, indeed, a VERY good reason for such a seemingly arrogant attitude, as we will see it shortly…

Intel’s server motherboards (on which the brand-name servers are usually based)have the hidden
secret hypervisor in their BIOS (so that even the primary OS runs as a guest. Yes, Intel’s virtualization
HW supports nested hypervisors).

  • Intel’s official opinion on this is “some remote mgmt features related to BMC”.

As everybody can understand, this means the code of arbitrary complexity (limited by the BIOS
chip size, which is rather large) always running on your server next to being totally transparent
to your OS
. Also, there is no possibilities of researching this code.

Now let’s open Intel Developer’s Manual (I hope it is not yet banned in Russia as a source of subversive information, is it), Volume 3B, Chapter26 “SYSTEM MANAGEMENT MODE”

As you can see it with your own eyes, there is absolutely nothing in your source’s “revelations” that has not been documented and thoroughly described in Intel’s official documentation - you just gave it a wrong interpretation and turned the whole thing into yet another paranoid conspiracy theory…

Anton Bassov

On 21-Oct-2014 18:08, Maxim S. Shatskih wrote:

  • some Russian hacker connected to Russian national security discovered the Intel’s server motherboards (on which the brand-name servers are usually based) have the hidden secret hypervisor in their BIOS (so that even the primary OS runs as a guest. Yes, Intel’s virtualization HW supports nested hypervisors).

A “big secret”, hah. This is the vPro/AMT thing (or some previous spin
of it). http://en.wikipedia.org/wiki/Intel_vPro
The Intel processor listings clearly state which models have it.
And you can figure out which sort of customers demanded this “feature”.

Compared to this issue, the BadUSB issue “nervously smokes at side”. The user will surely notice the fake keystrokes from the flash-drive-imposting-a-keyboard. Not so with a 2nd guest of the hidden hypervisor.

Which user? This is for managing servers. Or servicing the PCs in
certain “serious” orgs at night or during weekends.

– pa

>Which user? This is for managing servers. Or servicing the PCs in certain “serious” orgs at

night or during weekends.

The way I understood it, Max mixes up rootkits that run in SMM, with Intel AMT technology, as well as with IPMI. Concerning the rootkits that run in SMM, there is nothing particularly new about them - IIRC, a rootkit that runs in SMM was first demonstrated, as a proof-of-concept thing, at Black Hat conference back in 2008. Rootkits of this kind were, indeed, exploited by NSA( you may find the link below to be of interest)…

http://leaksource.info/2013/12/30/nsas-ant-division-catalog-of-exploits-for-nearly-every-major-software-hardware-firmware/

Concerning AMT and IPMI, I guess they may be quite useful for NSA hackers as well, but still,contrary to Max’s belief, there is nothing even remotely clandestine about these things - they are very-well described by Intel…

Anton Bassov

> Do you somehow realize that making a reference to such a source

I’m just too lazy to google for a Russian article, which I was reading around a year ago.

But the article was absolutely genuine, with the true name of the guy (connections to national security is his own words, but the technical stuff there, including screenshots, was convincing).

Now let’s open Intel Developer’s Manual (I hope it is not yet banned in Russia as a source of
subversive information, is it), Volume 3B, Chapter26 “SYSTEM MANAGEMENT MODE”

How SMM is related to hypervisors?

Only skinhead and fundamental Muslim texts are banned in Russia as “sources of subversive information”, there is even a public registry of them.


Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com

> Concerning AMT and IPMI, I guess they may be quite useful for NSA hackers as well, but

still,contrary to Max’s belief, there is nothing even remotely clandestine about these things - they are
very-well described by Intel…

IPMI is IIRC the TCP-based protocol of “get/put property” verbs used in remote mgmt.

Yes, the server side of IPMI is in the same BMC chip, which uses BIOS-embedded firmware.

And yes, it can trivially be clandestine. The BMC firmware is encrypted, so no one knows what actually goes on there, besides the publicly available BMC stuff.

And yes, the presence of a BIOS-provided hypervisor just after boot can really be tested by a small app.


Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com

> A “big secret”, hah. This is the vPro/AMT thing (or some previous spin

of it). http://en.wikipedia.org/wiki/Intel_vPro

What is new here is that the firmware code for this feature is encrypted and nobody knows what is really in it, besides the usual Dell iDRAC implementation.


Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com

> How SMM is related to hypervisors?

Please note that you are the only one who speaks about " hypervisors" and “secret CPU features” here…

However, if someone really wants to remain totally transparent to the OS-level software SMM is, apparently,
the best way to go - this is a total terra incognita to the OS…

Anton Bassov