DNS Hijacking

This is probably the wrong place to ask this, I don’t know.

I run an internet filtering company.

I am interested in client side DNS Hijacking.

The reason is… we could implement an internet filter through DNS that
would be lighting fast.

Is it possible to force a DNS to be used for all connections on computer
using a client piece?

The client could also then have specific additions for the computer, maybe
use a different dns for certain domain names that should not be blocked.

The client could also do some keyword filtering in urls maybe.

Who should I talk to about developing this?

Paul Payton
Clean Internet
cleaninternet.com

You need NDIS IM filter driver here - you’ve got to filter TCP or UDP packets that are sent by TCPIP itself, i.e. unrelated to TDI requests that get sent to //Device//TCP or //Device//UDP. IIRC, when you call gethostbyname(), Winsock just sends a private IOCTL directly to //Device//IP (AFD.SYS is not involved here), in response to which TCPIP generates TCP or UDP packet with destination port 53, and sends it to DNS server. Once IOCTL is private, it means that filtering //Device//IP is not going to lead you anywhere - although you can disassemble the OS and discover the target IOCTL, the slightest system update is going to shatter your solution to pieces.

Therefore, you need NDIS-level solution. Whenever you see a packet with destination port 53,
check the domain name that it wants to resolve. If you don’t want a given domain name to get resolved,
report the packet as being sent successfully without actually sending it anywhere, and, in a short while,
forge a response from DNS server which claims that the given name cannot get resolved, and indicate it to TCPIP. Pure and simple. Similarly, instead of resolving the target name X, you can substitute name Y for it, send it to the server, and, upon receiving the reply, report name X as being resolved. Therefore, TCPIP will believe that the IP address xxx.xxx.xxx xxx corresponds to name X, while, in actuality, it corresponds to name Y. In other words, you can do whatever you like - please note that this solution is fully “supported”, so that it is going to work everywhere…

Anton Bassov

Actually, after thinking a bit, I came to the conclusion that, unless you want to substitute DNS names for one another (in fact, the kind of thing I would rather expect from some piece of malware, rather than from a “law-abiding and responsible” driver), you may let DNS requests go to DNS server without any filtering, and, instead, concentrate on responses. Capture all responses from DNS server, and, instead of indicating them up the stack, forward them to a user-mode app/service that takes a decision whether a given query should be allowed to get resolved. If yes, it will leave it intact, otherwise, it will forge a packet with a negative response. In either case, it will resubmit a packet to your control object, so that your driver will indicate it up the stack…

Certainly, if you filter incoming packets at NDIS level you have to handle IP fragmentation, but it should not be that complex…

Anton Bassov

Paul Payton wrote:

If your wanting to block specific urls on a local machine, there are
quite a few ways, each has it’s advantages and drawbacks.

1.) Create an LSP filter - effective but flaky and a poorly documented
interface. Most adware/spyware apps
will most likely attack it.

2.) To use a bad word, ‘hook’ GetHostByName. There is a simple example
of doing this on codeproject
that uses the MS detours library, but you’ll have licensing issues there.

3.) IPHLPAPI.DLL exports several functions that can be used to block
domains (after resolving the IP),
PfAddFiltersToInterface for example. I tried this method, but after a
few thousand IP’s, no error, but
failure occurred and it no longer worked.

4.) Usermode service resolves names to IP’s, then passes the IP via
IOCTL to a filter hook driver to
drop the connection (not recommended - don’t think this type of driver
is even supported in Vista?).

5.) As Anton recommended, NDIS intermediate driver - would work but
would be a pain in the ass
it implement (in my view - haven’t played around a lot in this area).

6.) HTTP loop-back proxy - easy but limited. Browser config required.

7.) DNS loop-back proxy - was a pain in the ass for reasons I can’t
remember other than fighting Indy 10’s
dns server component. Never could figure out it’s interface fully
regarding zone files etc… I did get it looping back
for name resolution, just got lost in what I was trying and my A.D.D.
lead me to something else of greater
interest.

8.) BHO - very effective but only works with IE… I figure FF supports
something like this, never really looked
into it.

9.) service to install and update the HOSTS file daily. Works, but on
some systems after you get a few hundred
entries the system begins lagging if you don’t disable “dns client
services”.

As you can see, all of these possibilities suck for the most part. If
you have a local database of URLS to block,
and you want it to be browser/app agnostic and look for keywords within
the url, I think the hooking
approach is really your best method. Yes hooking is evil, but in
usermode it isn’t as bad as in the kernel.

Just some ideas for you to think about. I’m sure others on this list
might have some comments on these 9
approaches - or possible other ways which I’d love to hear about.

Good luck and Get Rich,

Matt

This is probably the wrong place to ask this, I don’t know.

I run an internet filtering company.

I am interested in client side DNS Hijacking.

The reason is… we could implement an internet filter through DNS that
would be lighting fast.

Is it possible to force a DNS to be used for all connections on computer
using a client piece?

The client could also then have specific additions for the computer, maybe
use a different dns for certain domain names that should not be blocked.

The client could also do some keyword filtering in urls maybe.

Who should I talk to about developing this?

Paul Payton
Clean Internet
cleaninternet.com


NTDEV is sponsored by OSR

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

Matt,

Apart from injecting a DLL that hooks all calls of interest into all processes in the system, all user-mode solutions may work only on process-wide basis. Therefore, if you want to it it on system-wide one (and I believe this is what the OP wants), you need either a driver or UM hooking DLL in all processes. . Taking into consideration the fact that target calls may be made by COM components that you cannot arrive to via analyzing PE header, UM hooking DLL seems to be rather problematic option

I would say that , although it *does* involve some work and has plenty of details that are “not-so-obvious” to NDIS newbie, NDIS IM filter is the best possible solution here…

Anton Bassov

xxxxx@hotmail.com wrote:

I can’t disagree really. As I said in my last post, “all of these
possibilities suck for the most part”. I honestly think using an external
proxy is the best way (what I think he is using currently).

Apart from injecting a DLL that hooks all calls of interest into all processes in the system, all user-mode solutions may work only on process-wide basis. Therefore, if you want to it it on system-wide one (and I believe this is what the OP wants), you need either a driver or UM hooking DLL in all processes. . Taking into consideration the fact that target calls may be made by COM components that you cannot arrive to via analyzing PE header, UM hooking DLL seems to be rather problematic option

Point taken, but I believe the OP is really only interested in
FireFox.exe and IExplorer.exe. I’m making the assumption his business is
designed to keep children
away from the vast porn industry online; most COM components that would
be used here and could bypass a hook would not be browsers, but other
internet applications
that can’t display nasty things (like updater’s).

I would say that , although it *does* involve some work and has plenty of details that are “not-so-obvious” to NDIS newbie, NDIS IM filter is the best possible solution here…

While I think your a pretty smart guy, I do think your playing down many
of the complexities the OP will face while heading down this path. I
don’t get the sense that
the OP has *ANY* kernel development experience. Besides learning the
complexities that come with any kernel component, he will be processing
raw fragmented
data off the wire. If I recall correctly, DNS is a UDP protocol, in my
belief that would make it a whole hell of a lot harder to reconstruct IP
fragments without a seq#.
Then again, I’ve never played around at this level and really don’t know
much about this other than my assumptions. If Dns is UDP, I have no idea
how prevalent
fragmentation is or could become - or how difficult piecing it back
together would be. Hopefully I might pick up some information here.

I do wish MS included a ‘real’ way to block domains, or at least
provided a callback interface of some sort…

Matt

Anton Bassov


NTDEV is sponsored by OSR

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

Matt wrote:

and after hitting send, I started thinking about how could UDP not have
a seq #… Still under the TCP suite,
so that can’t be right…

I had to look this up, my bad… Last time I really read about it
was 5 or more years ago during jury duty…

oops…

Matt

xxxxx@hotmail.com wrote:

I can’t disagree really. As I said in my last post, “all of these
possibilities suck for the most part”. I honestly think using an external
proxy is the best way (what I think he is using currently).

> Apart from injecting a DLL that hooks all calls of interest into all
> processes in the system, all user-mode solutions may work only on
> process-wide basis. Therefore, if you want to it it on system-wide
> one (and I believe this is what the OP wants), you need either a
> driver or UM hooking DLL in all processes. . Taking into
> consideration the fact that target calls may be made by COM
> components that you cannot arrive to via analyzing PE header, UM
> hooking DLL seems to be rather problematic option
>
Point taken, but I believe the OP is really only interested in
FireFox.exe and IExplorer.exe. I’m making the assumption his business
is designed to keep children
away from the vast porn industry online; most COM components that
would be used here and could bypass a hook would not be browsers, but
other internet applications
that can’t display nasty things (like updater’s).
>
> I would say that , although it *does* involve some work and has
> plenty of details that are “not-so-obvious” to NDIS newbie, NDIS IM
> filter is the best possible solution here…
>
While I think your a pretty smart guy, I do think your playing down
many of the complexities the OP will face while heading down this
path. I don’t get the sense that
the OP has *ANY* kernel development experience. Besides learning the
complexities that come with any kernel component, he will be
processing raw fragmented
data off the wire. If I recall correctly, DNS is a UDP protocol, in my
belief that would make it a whole hell of a lot harder to reconstruct
IP fragments without a seq#.
Then again, I’ve never played around at this level and really don’t
know much about this other than my assumptions. If Dns is UDP, I have
no idea how prevalent
fragmentation is or could become - or how difficult piecing it back
together would be. Hopefully I might pick up some information here.

I do wish MS included a ‘real’ way to block domains, or at least
provided a callback interface of some sort…

Matt
> Anton Bassov
> —
> NTDEV is sponsored by OSR
>
> 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
>
>


NTDEV is sponsored by OSR

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

>If I recall correctly, DNS is a UDP protocol

Normally yes. However, AFAIK, DNS over TCP (the same port 53) is also possible…

in my belief that would make it a whole hell of a lot harder to reconstruct IP fragments without a seq#.

Please note that sequence numbers have nothing to do with fragmentation - the former is TCP-specific feature (i.e. transport layer), while the latter is done by IP (i.e. network layer). IP header has all info that you need for re-assembling the packet

If Dns is UDP, I have no idea how prevalent fragmentation is or could become

DNS packets are pretty small…

Anton Bassov

I think this may be more than what the OP actually needs.

If I understand correctly, I think the OP is now using an HTTP proxy type of mechanism, with regular DNS, and is facing an increasing customer base - therefore looking for a faster solution.

A simple service that monitors the DNS settings for active network adapters, setting them to the CleanInter.net DNS proxy should suffice.

Paul, I looked at your company’s product a few years ago. Your web page isn’t exactly specific on how it works, so I could be wrong in my analysis. Either way, good luck!

-Steve Cleary

> I think this may be more than what the OP actually needs.

Can be - probably, Matt and myself are, indeed, deciding upon the most efficient way to shoot a fly with a canon…

Anton Bassov

Wow, thanks for all your input…
I currently use a TDI Driver written by Cristi Berneanu.

It works in conjunction with a service that together block key words in urls, domains, and queries a filter server for blocked categories that the url would fall into. Caches those results and either allows the response from the original requested server or redirects it to a blockpage.

This has nothing to do with DNS…

It conflicts with firewalls and some anti-virus software.
I don’t have the source code. Cristi has disappeared.

I need someone to either rewrite this without the bugs… build another solution with either NDIS or Winsock or come up with a new solution all together for filtering.

DNS is one of those possibilities.

Paul

Sounds like a pretty massive reverse-engineering job. First recommendation is for you to hire a detective to track down Cristi… :slight_smile:

Thomas F. Divine

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-321312-
xxxxx@lists.osr.com] On Behalf Of xxxxx@cleaninter.net
Sent: Wednesday, April 16, 2008 6:56 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] DNS Hijacking

Wow, thanks for all your input…
I currently use a TDI Driver written by Cristi Berneanu.

It works in conjunction with a service that together block key words in
urls, domains, and queries a filter server for blocked categories that
the url would fall into. Caches those results and either allows the
response from the original requested server or redirects it to a
blockpage.

This has nothing to do with DNS…

It conflicts with firewalls and some anti-virus software.
I don’t have the source code. Cristi has disappeared.

I need someone to either rewrite this without the bugs… build another
solution with either NDIS or Winsock or come up with a new solution
all together for filtering.

DNS is one of those possibilities.

Paul


NTDEV is sponsored by OSR

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

> It conflicts with firewalls and some anti-virus software.

I need someone to either rewrite this without the bugs…

The fact that a driver conflicts with some crappy FW / AV software does not yet imply that it is buggy.
Test it under DriverVerifier first. If it works perfectly well under Verifier and the problem FW/ AV software
is unable to pass Verifier test, you have to contact FW/ AV softwares vendors with the request to fix
their crap, rather than requesting the rewrite of a good driver. If it is unable to pass Verifier test either…
well, then, probably, indeed, it makes sense to rewrite it I would strongly advise you to request a “proper” solution, i.e. the one that is able to pass DriverVerifier test, so that, in case if it conflicts with the AV/PF, you can request AV/PF vendor to fix their software. Adjusting it to the needs of AV/PF is really a no-brainer - today it conflicts with Kaspersky; after getting adjusted to it it starts conflicting with ZoneAlarm and so on and so forth…

Anton Bassov