I will keep this short. Using ObRegisterCallbacks, I can block process termination or an application’s access to a process etc. I get Callbacks and I can alter desired access parameter to achieve my goals.
I also used PsSetLoadImageNotifyRoutine where I get notification of an app loading EXE, DLL, SYS, … But I can’t do anything about it, I just get the notification.
How can I make block/prevent/filter some drivers from being loaded just like I do for processes using ObRegisterCallbacks? I want to avoid dirty hacks as much as possible.
Any ideas? Please put me in the right direction and hopefully I’ll figure the rest out.
Use a minifilter to block the file create/read/section_sync (your choice).
Otherwise it’s dirty hacks in the Ps path.
On Thu, Feb 11, 2016 at 9:11 PM, wrote:
> Hello all, > > I will keep this short. Using ObRegisterCallbacks, I can block process > termination or an application’s access to a process etc. I get Callbacks > and I can alter desired access parameter to achieve my goals. > > I also used PsSetLoadImageNotifyRoutine where I get notification of an app > loading EXE, DLL, SYS, … But I can’t do anything about it, I just get the > notification. > > How can I make block/prevent/filter some drivers from being loaded just > like I do for processes using ObRegisterCallbacks? I want to avoid dirty > hacks as much as possible. > > Any ideas? Please put me in the right direction and hopefully I’ll figure > the rest out. > > Thank you guys > > — > NTDEV is sponsored by OSR > > Visit the list online at: < > http://www.osronline.com/showlists.cfm?list=ntdev> > > MONTHLY seminars on crash dump analysis, WDF, Windows internals and > software drivers! > Details at http: > > To unsubscribe, visit the List Server section of OSR Online at < > http://www.osronline.com/page.cfm?name=ListServer> ></http:>
> How can I make block/prevent/filter some drivers from being loaded just like I do
for processes using ObRegisterCallbacks?
Exactly the same way other drivers may try to do the same with yours - you are trying to fight a war that cannot be won. Another,and more important point to consider is WHY you think you should be allowed to do it, in the first place.Look - if driver is allowed to be load by the system it means things were configured this way by the Admin user, and anyone who tries to deny admin user to configure the system the way they wish…well, search NTDEV archives, and pay a special attention to Mr.Burn’s reactions and statements on the topic. Just to give you an idea, I am going to provide an example of his relatively soft reaction to things that you are trying to do
@Paul McDonough, Thank you very much for the suggestion! Is there any “hackish” way that someone might try and load a driver without actually writing to disk? How about starting a driver with .abc extension? Wouldn’t it bypass our filter?
@Anton Bassov, I’m totally against your “Mr.Burn” quote. First of all, it’s not a game of who wins, who loses. My driver will load at beginning and will prevent ALL other drivers, unless it’s approved. That simple. Sometimes I approve a driver, then my driver will allow it to be loaded, sometimes I don’t. That’s it. No need to call it a never ending war.
So I personally don’t think this rises to the level of a Mr. Burn type
response regardless of what Anton has to say.
Generally, it’s a chicken and egg problem like you said. If you are loaded
first (ELAM driver for example) and put policies in place to stop other
drivers from loading after you, then you win (generally). ***HOWEVER***,
and I’m making a pretty standard assumption here based on the question that
you are writing some kind of anti-malware software, so in this case
whatever type of filtering you have in place doesn’t matter. Do some
research on Uroburos to learn more about direct to kernel injections and
the hackish ways your filtering scheme will fail.
On Thu, Feb 11, 2016 at 10:11 PM, wrote:
> @Paul McDonough, Thank you very much for the suggestion! Is there any > “hackish” way that someone might try and load a driver without actually > writing to disk? How about starting a driver with .abc extension? Wouldn’t > it bypass our filter? > > @Anton Bassov, I’m totally against your “Mr.Burn” quote. First of all, > it’s not a game of who wins, who loses. My driver will load at beginning > and will prevent ALL other drivers, unless it’s approved. That simple. > Sometimes I approve a driver, then my driver will allow it to be loaded, > sometimes I don’t. That’s it. No need to call it a never ending war. > > — > NTDEV is sponsored by OSR > > Visit the list online at: < > http://www.osronline.com/showlists.cfm?list=ntdev> > > MONTHLY seminars on crash dump analysis, WDF, Windows internals and > software drivers! > Details at http: > > To unsubscribe, visit the List Server section of OSR Online at < > http://www.osronline.com/page.cfm?name=ListServer> ></http:>
@Paul McDonough, Thank you very much for the suggestion! Is there any
“hackish” way that someone might try and load a driver without actually
writing to disk? How about starting a driver with .abc extension? Wouldn’t it
bypass our filter?
@Anton Bassov, I’m totally against your “Mr.Burn” quote. First of all, it’s not a
game of who wins, who loses. My driver will load at beginning and will
prevent ALL other drivers, unless it’s approved. That simple. Sometimes I
approve a driver, then my driver will allow it to be loaded, sometimes I don’t.
That’s it. No need to call it a never ending war.
The answer to the question depends on who your enemy is. If your enemy is users trying to install software you haven’t approved, then it’s unlikely anyone will go around the protection you have put in place (unless they really want to, or unless they have physical access to the machine, then all bets are off).
If your enemy is malware, then malware always wins because malware always gets to make the first move. If someone with enough determination wants to get around your driver then they will load your driver onto their test machine, take it to pieces, and keep throwing things at it until something gets around it. You say your driver “will load at the beginning” - malware will find a way of loading their driver (or inserting their kernel hook, or whatever) first, and they won’t release it unto the world until it does.
So it would help a lot if you would tell us who you are trying to protect, and from whom.
@James and @Paul: Thank you for responses. But when you guys say “if malware driver loads, now it won’t let you…” yes. I don’t think that’ll ever happen. If that happens, that’s cool, that’s totally different story. If someone takes my code apart, finds something special for it (hopefully never will happen), then we’ll patch and move on, let’s skip this part.
I want to prevent all normal drivers, no special exploit for my driver, no special throwin things at my driver, just malware or not, I want to block all drivers.
As for Urobros, how it can bypass my urobros?
So if we skip these requirements, how can I block drivers from being loaded?
If you only care about file based drivers and have a threat profile of
average users, like I said originally, use a minifilter.
On Thu, Feb 11, 2016 at 10:44 PM, wrote:
> @James and @Paul: Thank you for responses. But when you guys say “if > malware driver loads, now it won’t let you…” yes. I don’t think that’ll > ever happen. If that happens, that’s cool, that’s totally different story. > If someone takes my code apart, finds something special for it (hopefully > never will happen), then we’ll patch and move on, let’s skip this part. > > I want to prevent all normal drivers, no special exploit for my driver, no > special throwin things at my driver, just malware or not, I want to block > all drivers. > > As for Urobros, how it can bypass my urobros? > > So if we skip these requirements, how can I block drivers from being > loaded? > > Thank you > > — > NTDEV is sponsored by OSR > > Visit the list online at: < > http://www.osronline.com/showlists.cfm?list=ntdev> > > MONTHLY seminars on crash dump analysis, WDF, Windows internals and > software drivers! > Details at http: > > To unsubscribe, visit the List Server section of OSR Online at < > http://www.osronline.com/page.cfm?name=ListServer> ></http:>
No. I’m not here to provide tips that could be used for nefarious
purposes. There is plenty of research you can find that shows ways to
bypass restrictions on driver loading, special filters or not. And doing a
little red-teaming against your software on your own would probably do you
some good because I think you still have a lot to learn.
On Thu, Feb 11, 2016 at 10:54 PM, wrote:
> @Paul, tell me about a trick that would bypass any filtering in place by a > driver. > > I’m not sure, but as far as I know, you can load a driver with .abc > extension, how your original minifilter would help? > > — > NTDEV is sponsored by OSR > > Visit the list online at: < > http://www.osronline.com/showlists.cfm?list=ntdev> > > MONTHLY seminars on crash dump analysis, WDF, Windows internals and > software drivers! > Details at http: > > To unsubscribe, visit the List Server section of OSR Online at < > http://www.osronline.com/page.cfm?name=ListServer> ></http:>
> First of all, it’s not a game of who wins, who loses. My driver will load at beginning and
will prevent ALL other drivers, unless it’s approved. That simple
I repeat my questions:
What makes you believe it is your driver who is loaded first and things don’t go the other way around?
Why do you think you have the right to decide who gets loaded and why it cannot go the other way around?
I know you must be developing some security product - after all, I worked on the security product ABC which, apart from other things, was required to disable all the hooks by the security product XYZ (as well as all other products of a gven class) which, in turn, was trying to ensure these hooks are not disabled. Funny thing to watch, don’t you think…
@Anton Bassov, I’m totally against your “Mr.Burn” quote.
Read the above example, imagine ABC and XYZ on the same system, consider the frequency of BSODs on the target machine, and, at this point, you will see that Mr.Burn’s statement has a point, at least in respect of A and B parts.In fact, I quoted his statement for the sole purpose of being ironical about his (over)reactions, as well as about the way he tends to express himself, but still I have to admit that his attitude has at least some relevance here…
@James and @Paul: Thank you for responses. But when you guys say “if
malware driver loads, now it won’t let you…” yes. I don’t think that’ll ever
happen. If that happens, that’s cool, that’s totally different story. If someone
takes my code apart, finds something special for it (hopefully never will
happen), then we’ll patch and move on, let’s skip this part.
I want to prevent all normal drivers, no special exploit for my driver, no
special throwin things at my driver, just malware or not, I want to block all
drivers.
As for Urobros, how it can bypass my urobros?
So if we skip these requirements, how can I block drivers from being loaded?
The best place to start then would probably be to lurk on forums that discuss the tricks malware uses to do the same things.
I do hope you realise that you are creating software that “does not play well with others”, and if your software is installed on a computer it will cause other software on there to fail, so you can understand why people on this list are reluctant to encourage you to develop such software. You would be doing yourself a tremendous favour by sharing more about why you want to do this, and who is going to be using this software (is it paying customers? Is this for internal use only? Are you planning on installing it alongside shinything.exe without telling the user?) as without this information most people will think you are developing malware and won’t want to help you.
There’s a long history here, Mr. Tester, of people asking questions like this in this forum… and getting answers like this.
Unless your software is integrated with the OS and the hardware platform at a very basic level (think ELAM and secure boot), it really IS a race of who can get installed first. For many products, that’s “good enough for market requirements.” There is often a, ah, reluctance I’d call it, among some of the devs on this list to accept that the reality of market requirements is often different than the academic exercise of creating an iron-clad solution. On such topics, many folks here would make the perfect the enemy of the possible.
And of course there’s the “who’s PC is this anyway” viewpoint. With those folks, you’ll get nowhere.
So… in short… “File System Filter Driver” seems to be the right answer, though that’s not quite as simple as it might sound, as I think you pointed out (who says the image has to be in \windows\system32\drivers? Who says it needs to be named *.sys? How do you know if it’s a driver, then?). But these factors are precisely why creating value-added products is, ah, value added.
If these “market requirements” include “drawing seven red lines that are strictly perpendicular to one another, with at least one of them having been drawn in a form of a kitten because customers like cute animals, and doing all the above partly with green ink and partly with transparent one”…well, then these requirements are, indeed, different from an " academic exercise" of creating a solution that may actually work…
And where do you think one may get with a “solution” that renders most of the software installed on user’s machiue unusable, and, to make things even worse, does not allow a user to terminate(and sometimes even cleanly uninstall) itself???
Well, parsing PE header seems(at least to me) to be a trivial and straightforward task…
Microsoft has tightened the nuts on what drivers can and what cannot do in Win10/Srv2016.
Patching executable code in memory is now a strict no-no, since Device Guard will notice it and fail it, probably failing the whole machine in the process.
But, on the other side, Microsoft provided more documented technologies to do this, like ELAM.
So:
for modern Windows, ELAM is a solution for boot-time drivers.
for older Windows this is a research topic. For instance, you can patch the PsLoadedImageList entry (like TrueCrypt did to hook the hiber_xxx image instance). Or you can patch DriverEntry in memory, etc.
for non-boot drivers, you can fail NtCreateSection(SEC_IMAGE), or fail the file open with EXECUTE flags (both will also fail some other stuff, like the file’s icon or VersionInfo resource access), from a FltMgr minfilter.
Again please understand that you cannot always win Core Wars. Use the undocumented stuff and hooking only if absolutely necessary, and there is no documented way, even much harder documented way.
@Aleh Kazakevich: Thank you! I already tried that. Works sometimes in Win7 x64 for some drivers, but doesn’t work for some other. It shows write to read_only memory exception.
I tried to do MDL, lock, change permission to writable etc. but I wasn’t able to do that. Maybe I’m doing it wrong?
@Maxim: Let’s say we use patching for older windows versions (Win 7, 8 only). How can I enable write permission in x64? I don’t want to use CR and WP trick.