Injected wireless packets ignored without Wireshark.

If you don't want to hear my life story you can just skip to the question.

My neighbor is running an open wireless network. My neighbor next to him is stealing his connection. He sits by his garage with his laptop... I used Wireshark on my laptop to make sure he is actually using my neighbors network. I watched his http traffic and saw a picture of him on his MySpace account. So yeah, I decided I was gonna screw with him somehow. Probably learn a lot in the process too.

When I started I had very little network programming experience. Just a little WinSock. I wrote a very small HTTP server and a DNS server. The DNS server sent my IP for all DNS requests originating from the IP I specify. All other DNS requests are passed to the real DNS server. My neighbor was using the default user/pass for his router, so I set the DNS server on the router to my laptop. So in effect, every website he tried to go to displayed an HTML page that I specified. I just had to set to a very fake "wireless access denied" page. Everyone else on the network didn't know the difference.

The thing is...he keeps on trying to connect to their network. I didn't really like changing the settings on the router every time I wanted to enable or disable the DNS bypass, because the router had to restart and took about 30 sec before you could connect to the network. I don't know how computer literate my neighbors are either. Not sure if they are smart enough to look at their router settings if they keep having their connections reset.

So my next idea was to mess with his TCP connections. Monitor all packets over the air and send a RST packet in response to every packet so every website he went to would display an error. I made the program with raw sockets on Windows. After I completed it I found out that starting with XP SP2 raw sockets were crippled and the packets just wouldn't send. So I rewrote the program using WinPcap. I tested it on my dev machine. I found out that sending RST packets wouldn't work, but I found if you sent FIN ACK packets in response to all ACK packets nothing can be sent via TCP.

Question:
So I ran the program on my wireless laptop and tried to screw with my wireless desktop's TCP connections but...nothing happened. So I installed Wireshark on my desktop to see what was going on and to my surprise it worked. Any webpage I went to timed out. So I turned off capturing with Wireshark and it didn't work again. I just can't figure it out.

So I had the idea I would make another DNS server. This time instead of setting myself as the DNS server I would watch for DNS packets over the air and when I saw one coming from the MAC I specified I responded with my laptop's IP. The real DNS server will respond, but I'm much closer so since mines first that is all that matters. I wrote it with WinPcap and had it working fine on my dev computer. I tried to have my laptop watch my wireless desktop's DNS requests, but again it didn't work. I started capturing with Wireshark and it worked perfectly. All DNS requests pointed to my laptop.

I have been tearing my hair out I don't get why all my packets are ignored when I'm not capturing with Wireshark. The MAC/IP/TCP/UDP/DNS headers are perfect. Two possible ideas I have are prioritization issues which cause my packets to be read later than the real packets. In the case of TCP its read after the SEQ number had changed and thus ignored. My other idea is that the packet is being filtered by the OS (XP SP3 on all comps btw) because it knows they are fake. It can't be anything in the MAC/IP/TCP/UDP headers because all I do is switch all the source and dest fields around. Maybe it is something in the wireless protocol itself? Each comp must have its own ID in the protocol. Maybe if the source ID doesn't match where it was sent to its ignored. That wouldn't necessarily make sense though because it should be possible to get a response via a different route than the way the original packet was sent. Anyone have an suggestions? I can provide the source code for my DNS server if needed.

Hi!

So basically, your method is the following:
Your victim sends a packet to the local DNS server (which is running on your laptop). Your objective is to send back a packet to the victim, with the name of the DNS server as the "Sender", and a matching SYN number. The question is, is the REAL local DNS server getting his DNS request packets? If he does, and your packet arrives later then the real DNS servers, your packet will be discarded because it is not needed anymore.

What is think the problem could be, is the matching number. The UDP packets that your victim's computer sends to the DNS server, has a SYN like serial number. Every DNS request has a number, in order to match the requests to the answers. To fool your victim, you need to provide the exact number.

I hope i made some sense, in a nutshell what you need to do is check if your answer to his request has the right serial number.

You may also want to check out RFC 2535 about DNS-sec (DNS Security). It might contain some useful information.

If you have any questions please ask, and i will try to help you.

Cheers,

katsa

P.S.: RFC 2535 was obsoleted by 4033, 4034, 4035 , and updated by 2931, 3007, 3008, 3090, 3226, 3445, 3597, 3655, 3658, 3755, 3757, 3845
So i guess i was a little 'outdated'

Sorry if I was a little hard to understand. I had a small DNS server program written with WinSock. It would catch DNS requests for the specified host and forward everyone else's on to the real DNS server. I set the DNS server on the router to my laptop so that I wouldn't have to worry about the real DNS server getting the packets.

I didn't really like changing the router settings so instead I'm trying to catch the requests over the air and respond with WinPcap before the real DNS server does. The program works fine when run on the same computer thats being targeted or when Wireshark or any other packet sniffing program I have found is running on the target computer. I am copying the SYN number from the captured packet's DNS header to the DNS header of the fake response. Here is what the packets look like on Wireshark.

Code: Select all: ---------------Query--------------- 0000 00 1c f0 eb 28 cd 00 16 01 56 5d 66 08 00 45 00 ....(....V]f..E. 0010 00 3b b3 fd 00 00 80 11 04 f6 c0 a8 00 6d c0 a8 .;...........m.. 0020 00 01 04 56 00 35 00 27 10 67 33 fa 01 00 00 01 ...V.5.'.g3..... 0030 00 00 00 00 00 00 09 6d 69 63 72 6f 73 6f 66 74 .......microsoft 0040 03 63 6f 6d 00 00 01 00 01 .com..... Ethernet II Destination: D-Link_eb:28:cd Source: Buffalo_56:5d:66 Type: IP (0x0800) Internet Protocol Version: 4 Header length: 20 bytes Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00) Total Length: 59 Identification: 0xb3fd (46077) Flags: 0x00 Fragment offset: 0 Time to live: 128 Protocol: UDP (0x11) Header checksum: 0x04f6 [correct] Source: 192.168.0.109 (192.168.0.109) Destination: 192.168.0.1 (192.168.0.1) User Datagram Protocol Source port: nfsd-keepalive (1110) Destination port: domain (53) Length: 39 Checksum: 0x1067 [correct] Domain Name System (query) Response In: 68 Transaction ID: 0x33fa Flags: 0x0100 (Standard query) Questions: 1 Answer RRs: 0 Authority RRs: 0 Additional RRs: 0 Queries Name: microsoft.com Type: A (Host address) Class: IN (0x0001) ---------------Fake Response--------------- 0000 00 16 01 56 5d 66 00 1c f0 eb 28 cd 08 00 45 20 ...V]f....(...E 0010 00 4b 02 00 00 00 ff 11 37 c3 c0 a8 00 01 c0 a8 .K......7....... 0020 00 6d 00 35 04 56 00 37 00 00 33 fa 81 80 00 01 .m.5.V.7..3..... 0030 00 01 00 00 00 00 09 6d 69 63 72 6f 73 6f 66 74 .......microsoft 0040 03 63 6f 6d 00 00 01 00 01 c0 0c 00 01 00 01 00 .com............ 0050 00 00 00 00 04 c0 a8 00 6e ........n Ethernet II Destination: Buffalo_56:5d:66 Source: D-Link_eb:28:cd Type: IP (0x0800) Internet Protocol Version: 4 Header length: 20 bytes Differentiated Services Field: 0x20 (DSCP 0x08: Class Selector 1; ECN: 0x00) Total Length: 75 Identification: 0x0200 (512) Flags: 0x00 Fragment offset: 0 Time to live: 255 Protocol: UDP (0x11) Header checksum: 0x37c3 [correct] Source: 192.168.0.1 (192.168.0.1) Destination: 192.168.0.109 (192.168.0.109) User Datagram Protocol Source port: domain (53) Destination port: nfsd-keepalive (1110) Length: 55 Checksum: 0x0000 (none) Domain Name System (response) Request In: 60 Time: 0.017950000 seconds Transaction ID: 0x33fa Flags: 0x8180 (Standard query response, No error) Questions: 1 Answer RRs: 1 Authority RRs: 0 Additional RRs: 0 Queries Name: microsoft.com Type: A (Host address) Class: IN (0x0001) Answers Name: microsoft.com Type: A (Host address) Class: IN (0x0001) Time to live: 0 time Data length: 4 Addr: 192.168.0.110 ---------------Real Response--------------- 0000 00 16 01 56 5d 66 00 1c f0 eb 28 cd 08 00 45 00 ...V]f....(...E. 0010 00 5b 00 00 40 00 36 11 c2 d3 c0 a8 00 01 c0 a8 .[..@.6......... 0020 00 6d 00 35 04 56 00 47 7d 95 bf 25 81 80 00 01 .m.5.V.G}..%.... 0030 00 02 00 00 00 00 09 6d 69 63 72 6f 73 6f 66 74 .......microsoft 0040 03 63 6f 6d 00 00 01 00 01 c0 0c 00 01 00 01 00 .com............ 0050 00 0b 96 00 04 cf 2e c5 20 c0 0c 00 01 00 01 00 ........ ....... 0060 00 0b 96 00 04 cf 2e e8 b6 ......... Ethernet II Destination: Buffalo_56:5d:66 Source: D-Link_eb:28:cd Type: IP (0x0800) Internet Protocol Version: 4 Header length: 20 bytes Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00) Total Length: 91 Identification: 0x0000 (0) Flags: 0x04 (Don't Fragment) Fragment offset: 0 Time to live: 54 Protocol: UDP (0x11) Header checksum: 0xc2d3 [correct] Source: 192.168.0.1 (192.168.0.1) Destination: 192.168.0.109 (192.168.0.109) User Datagram Protocol Source port: domain (53) Destination port: nfsd-keepalive (1110) Length: 71 Checksum: 0x7d95 [correct] Domain Name System (response) Request In: 58 Time: 0.038947000 seconds Transaction ID: 0xbf25 Flags: 0x8180 (Standard query response, No error) Questions: 1 Answer RRs: 2 Authority RRs: 0 Additional RRs: 0 Queries Name: microsoft.com Type: A (Host address) Class: IN (0x0001) Answers Name: microsoft.com Type: A (Host address) Class: IN (0x0001) Time to live: 49 minutes, 26 seconds Data length: 4 Addr: 207.46.197.32 Name: microsoft.com Type: A (Host address) Class: IN (0x0001) Time to live: 49 minutes, 26 seconds Data length: 4 Addr: 207.46.232.182

The fact that it only works when I have a packet sniffer running seems like its a problem with timing. Also one thing worth noting. Every fake packet I send sent to the target computer twice. Once by me directly, and again by the router when it picks it up. I came up with a couple ideas while writing this. Maybe I shouldn't be setting the TTL field to 0 on the DNS answer. Maybe I should mess around with some of the urgency flags in the IP header.

I don't know why I didn't think of it before, but I ran Wireshark on my laptop instead of the target computer. Here is the cliff note version of a couple DNS requests. Neither of them worked.

Code: Select all: 12 11.068521 192.168.0.109 192.168.0.1 DNS Standard query A bob189.com 13 11.068602 192.168.0.1 192.168.0.109 DNS Standard query response A 192.168.0.110 14 11.150524 192.168.0.1 192.168.0.109 DNS Standard query response, No such name 15 11.150796 192.168.0.109 192.168.0.1 DNS Standard query A bob189.com.hsd1.mn.comcast.net 16 11.150836 192.168.0.1 192.168.0.109 DNS Standard query response A 192.168.0.110 17 11.220120 192.168.0.1 192.168.0.109 DNS Standard query response, No such name 4 0.002996 192.168.0.109 192.168.0.1 DNS Standard query A hackthissite.org 5 0.003064 192.168.0.1 192.168.0.109 DNS Standard query response A 192.168.0.110 8 0.046503 192.168.0.1 192.168.0.109 DNS Standard query response A 207.210.114.39 56 0.700732 192.168.0.109 192.168.0.1 DNS Standard query A www.hackthissite.org 57 0.700793 192.168.0.1 192.168.0.109 DNS Standard query response A 192.168.0.110 58 0.701830 192.168.0.109 192.168.0.1 DNS Standard query A www.hackthissite.org 59 0.721127 192.168.0.1 192.168.0.109 DNS Standard query response A 192.168.0.110 76 0.769081 192.168.0.1 192.168.0.109 DNS Standard query response CNAME hackthissite.org A 207.210.114.39

When I capture on the target computer I see the fake answer twice. I assumed it was the router passing my packet as well. Now I'm not so sure. Of course I don't know if it receives the packet twice when I don't capture because I can't capture the packets. I only ever see the packet once on the computer running the program. Maybe the one copy I see is the one coming from the router and I don't see the one sent. I don't know. Is it also possible I am responding too fast?

Code: Select all: 12 11.068521 192.168.0.109 192.168.0.1 DNS Standard query A bob189.com 13 11.068602 192.168.0.1 192.168.0.109 DNS Standard query response A 192.168.0.110 13 11.069231 192.168.0.1 192.168.0.109 DNS Standard query response A 192.168.0.110 14 11.150524 192.168.0.1 192.168.0.109 DNS Standard query response, No such name

Ok, here is what seems to be the problem:

Code: Select all: ---------------Fake Response--------------- 0000 00 16 01 56 5d 66 00 1c f0 eb 28 cd 08 00 45 20 ...V]f....(...E 0010 00 4b 02 00 00 00 ff 11 37 c3 c0 a8 00 01 c0 a8 .K......7....... 0020 00 6d 00 35 04 56 00 37 00 00 33 fa 81 80 00 01 .m.5.V.7..3..... 0030 00 01 00 00 00 00 09 6d 69 63 72 6f 73 6f 66 74 .......microsoft 0040 03 63 6f 6d 00 00 01 00 01 c0 0c 00 01 00 01 00 .com............ 0050 00 00 00 00 04 c0 a8 00 6e ........n Queries Name: microsoft.com Type: A (Host address) Class: IN (0x0001) Answers Name: microsoft.com Type: A (Host address) Class: IN (0x0001) Time to live: 0 time <------------- Data length: 4 Addr: 192.168.0.110

The Time to live parameter inside the DNS response tells the target machine, that how long that DNS response is valid.
So basically when you set the time to 0, you are telling the target machine that he needs to renew it.
Try setting the time to live accordingly, and see if you get better results.

Okay i was not completely correct, it does not tell the target machine to renew, but as you can see the target machine ignores 2 of your fake dns packets, and accepts the one legit.

I set the TTL field to 10mins, verified the packet with Wireshark and it didn't change anything. I also had DNS relay turned on with my router. I thought be it might be the router returning cached domain names. I turned it off and that didn't change anything either. I'm still puzzled by the second copy of my packet that gets caught on the target machine. If it were the router sending another copy wouldn't the TTL in the IP header be decremented by one? The two packets are exact duplicates in every way I can see except the arrival time.
Thanks for your time and your suggestions though katsa.

EDIT:
I have been setting the TTL in the IP header to 255. I thought that value might have special meaning so I set it to 16. I still receive two identical packets, but it doesn't work when capturing on the target computer. It still works when run on the target computer though. I set the TTL to 255 again and it worked like it did before. This really has me stumped.

I can only think of Windows XP filtering the fake packets. That would explain why this only works when wireshark is running. Wireshark is processing the packets that would be otherwise discarded by the operating system.
One solution to this is: you need to check the version of the OS of the target computer, and look for a vulnerability for DNS spoofing.

Edit:
I think you ruled out everything, except your initial idea of the OS filtering.
I am sure windows has some ways to defend against attacks like this.

I did some research on dns spoofing specifically with regards to Windows. Apparently there was a vulnerability in many versions of Windows. It always used the same source port, and the ID for the DNS requests wasn't very random. It made brute forcing the ID possible. It implied that if you have the port and ID you are golden. It also said as a fix they randomized the ID. Not to discount the possibility of the OS filtering the packets, but I don't see how it could. I made my packets look identical to the real packets in every way except the IP address of the domain name. I also set the IP address my program filled in to a few different servers on the net. I thought it may be filtering it because it is a local IP. I tried modifying the DNS TTL value to a very large number. Another possibility I came up with is maybe the thread reading the packets doesn't update all that often, and both the real and fake packets were in the buffer when it read it. For some reason it may read backwards. So I had it send 100 copies of every packet. Not that its impossible, but Wireshark should not affect the OS throwing out DNS packets. I guess since the packets themselves seem fine the only thing I can imagine is some sort of filtering.

Oh well..if I can't get it to work does anyone know another method I could use to make web pages not work on a specific computer on an open network?

I was sniffing for my own dns query and response packets to see if i can pinpoint something that differs from your sent packets. The only thing i could notice is that your query came from a well known port, number 1110 UDP, that stands for
nfsd-keepalive (Source port: nfsd-keepalive (1110)). I don't know if this has some things to do with your packets not being accepted, but all my dns queries came from 'random' ports, never a well known one.

I was looking at some alternatives to DNS spoofing. I made an ARP poisoning tool, and I had an interesting idea. What if I use ARP poisoning to help with my DNS spoofing. Give the router my laptop's MAC for the target IP. All packets coming from the actual name servers will be captured by my laptop and summarily executed via free(). I can even pretty my DNS responses up by capturing the real DNS responses and just replacing the IP addresses with my laptop's IP. I should still be able to use the WinHttp API for my HTTP server because the ARP routing table should be fine on my laptop. Even if he tries to bypass the name servers or has some cached he can't do any web surfing because all his WAN are belong to me. I'll start coding it when I wake up and post the results. I'm hoping if I can filter out the real DNS replies, the target will quit ignoring me.

Injected wireless packets ignored without Wireshark.

Injected wireless packets ignored without Wireshark.

Re: Injected wireless packets ignored without Wireshark.

Re: Injected wireless packets ignored without Wireshark.

Re: Injected wireless packets ignored without Wireshark.

Re: Injected wireless packets ignored without Wireshark.

Re: Injected wireless packets ignored without Wireshark.

Re: Injected wireless packets ignored without Wireshark.

Re: Injected wireless packets ignored without Wireshark.

Re: Injected wireless packets ignored without Wireshark.

Re: Injected wireless packets ignored without Wireshark.

Who is online