Jump to content

arp packages in wifi behind ap?


GermanNoob

Recommended Posts

Hi there,

I'm not sure if I should post that here or in the Pineapple section. But as it is more a general question, I decided to give it a try here...

Set-Up:

I connect with the WifiPineapple to an Wifi. To get MITM I decided to arpspoof one of the clients in the wifi network.

Everything worked fine, but I'm thinking now about detection methods of that attack... Can my arp packages been seen behind the ap (meaining on the LAN side)? I suppose they shouldn't be as the packages are directly addressed with the MAC of the victim and therefore there isn't a need for the AP to bring them into the LAN. 

Can anybody answer this question for me? I'm probably not able to setup an testing environment for the end of next week...

Thanks in advance!

GermanNoob

Link to comment
Share on other sites

ARP packets don't pass through routers so if you do a broadcast then it will be seen by all devices on the same subnet. If you target a single device then, if it is on the same subnet, it will get the packet.

I think, if I read your question right, that if the AP is acting as a NAT device then the ARP packets you send won't hit the LAN but if it is just a bridge then they will.

Link to comment
Share on other sites

1 hour ago, digininja said:

In which case, ask the owner. If you can't then you probably shouldn't be doing this type of thing against it.

Hi @digininja,

it seems that I wasn't clear about my intention... Sorry, for that! I'm not going to do something illegal. I  just want to understand how big the risk of arp spoofing in the described setup is and if countermeasures like IDS behind the AP would work or what would have to be done to work. Of course I will set up a test environment, but I can't do that before next week as I'm on a short vacation at the moment...

9 hours ago, IDNeon said:

Try if it assigns IP addresses or not.  A Bridged AP shouldn't assign IP addresses.

Hi @IDNeon,

sorry, if my following question is dumb as shit... IP assigning is working over DHCP. During the IP assignment process the client will only test the received IP with an ARP package (as far as I understood). While also a bridge could be configured to forward DHCP packages to the DHCP server (DHCP-relay agent), I didn't find anything that it also relays ARP packages...

So, I think that I could still get an IP address (not from the AP but from the DHCP server in the LAN behind) and ARP packages might still stay only in the WIFI... Am I wrong? 

Link to comment
Share on other sites

Basically ARP packets (not packages) are layer two and so don't leave their network segment. If it is a bridge, then it would probably be considered a flat network, everything on the same subnet, and so ARP packets would traverse all across it. If it is routing (acting as a NAT device) then packets would not traverse it.

To work out if it is bridging or not, probably the easiest way is to look at the other devices on the network with you. If they are all wireless except the AP, then you are probably on a wifi subnet and so the AP is a router, if there are wired devices as well then it might be a flat network.

You can also traceroute out of the network and look at the hops. If it goes from your internal IP to an external then it is likely a flat network, if there are multiple internal IPs before the external then there is some routing going on.

Lots of possibly and likely there as there are always exceptions, you just have to learn to spot them.

Link to comment
Share on other sites

11 hours ago, GermanNoob said:

Hi @digininja,

it seems that I wasn't clear about my intention... Sorry, for that! I'm not going to do something illegal. I  just want to understand how big the risk of arp spoofing in the described setup is and if countermeasures like IDS behind the AP would work or what would have to be done to work. Of course I will set up a test environment, but I can't do that before next week as I'm on a short vacation at the moment...

Hi @IDNeon,

sorry, if my following question is dumb as shit... IP assigning is working over DHCP. During the IP assignment process the client will only test the received IP with an ARP package (as far as I understood). While also a bridge could be configured to forward DHCP packages to the DHCP server (DHCP-relay agent), I didn't find anything that it also relays ARP packages...

So, I think that I could still get an IP address (not from the AP but from the DHCP server in the LAN behind) and ARP packages might still stay only in the WIFI... Am I wrong? 

There is no "only in the WIFI".

WIFI is a method of network access but isn't a "network" unto itself.

The network is all addressing....what broadcast and collision domains are you in?  That's the fundamentals.

ARPs work in a broadcast domain.  A collision domain may be the same as the broadcast domain, but it may not be the same.

Anything else requires routing.

The concept of collision and broadcast domains are obfuscated now but basically we say "subnets" to describe broadcast domains but you'll miss critical components of a network if you forget the two are actually separate.  Collision/Broadcast represents a physical/logical problem.  While subnets is completely logical and has nothing to do with the physical devices it exists on.

To the heart of your question, what happens to ARP packets, depends entirely on what collision and broadcast(subnet) domains it exists in.

A bridged AP exists in the same collision domain as the switch it is plugged into.

A NAT AP is its own collision domain.

If you can think of a way to test what collision domains you are in, you can accurately determine this feature of the switch.


Soooooo, your question can your ARP be seen on the LAN port.  Someone mentioned if you target a device ... not sure what they mean, if a device's MAC isn't in the ARP table, then your ARP will be sent across an entire broadcast domain until it bumps into a router, and will be like ripples in a pond reflecting off trees in the pond which represent other ports that are searching for the MAC address you are requesting.

The only way that won't happen is if the AP is itself performing NAT.

To prove that without having authentic access to the LAN, requires some creative fail-state testing.

What does all devices fail-state to?

10/100 Half-Duplex.

Hence why collision domain should still matter.

 

Link to comment
Share on other sites

See the diagram below.

While almost everyone thinks of a network now as the broadcast domain (logical not even physically, that is layer 2 and 3, not even layer 1) a broadcast and collision domain are INITIALLY layer 1 concepts.

If you apply fail-state tests like I described you can answer your question because the collision domain is physically different from other collision domains.

Your question is more accurately "is my device in its own collision domain" or not.

Because that tells you how it's behaving regarding NAT/Bridge as others have suggested you want to know.

 

broadcast-domain.png?w=428&h=255

Link to comment
Share on other sites

Sorry for the multiple replies, I'm working and work is hectic per usual so I'm piece-mealing this together.

Refer to the previous diagram, notice from left to right, a switch, a hub, and a router.

Your task, should you choose to accept it, is to cause the ports to fail to 10/100/half-duplex and prove if your device is acting like a switch/router, or a hub.

I put switch/router together because functionally in the above diagram both devices segregate their collision domains because they are built to do so.

A bridged AP, should not.

This is more authoritative than looking around the office for what kind of connections there are.

And if you did not have physical access to a building but only access to its wifi from the parking lot, this could be an important tool in your inventory for knowing what your traffic is doing.

You can do this fail-state test passively.

Link to comment
Share on other sites

Thank you very much, @IDNeon for your detailed answer! I really appreciate the time you invested in trying to help me!

10 hours ago, IDNeon said:

Soooooo, your question can your ARP be seen on the LAN port.  Someone mentioned if you target a device ... not sure what they mean, if a device's MAC isn't in the ARP table, then your ARP will be sent across an entire broadcast domain until it bumps into a router, and will be like ripples in a pond reflecting off trees in the pond which represent other ports that are searching for the MAC address you are requesting.

As I have access to the network using wifi. So if I understand you right, then I could do this:

Asking a device that is also connected using wifi for its hardware address. As I got that within my ARP table I could arpspoof that device and as the packets are already addressed to the hardware address of the target it shouldn't be sent over the whole network where an IDS could be used.

Is that right? 

Link to comment
Share on other sites

To keep it simple, if your ARP poison attack worked for a MITM, then the arp packets CAN be seen on the victims side of the network. As digininja explained above, ARP works at layer 2 to identify MAC addresses, and match them to corresponding IP addresses at layer 3 (link layer to IP mappings), but ARP does not leave the same subnet due to it's layer 2 connectivity.

Open up wireshark, and you'll see ARP packets between two devices, are using their MAC addresses to speak to each other in the Ethernet II frames(should see no IPv4 frame). At the bottom of the packet, you'll see the reply with sender MAC and IP. The query is sent unicast to the gateway with a "Who has x.x.x.x? Tell x.x.x.x < where x.x.x.x is the IP  addresses being asked for and who to tell is what at each IP, and the gateway does a broadcast to the whole subnet until one of the devices replies with the data it queried for. This associates the MAC to IP relationship for the ARP reply and tables, and why we can attack it because we can spoof this request and reply with false info broadcast across the network telling the gateway we are a victims IP with our MAC and the victim, that we are the gateway with our MAC. When that happens, everyone updates their ARP table (link layer to IP mappings) with the false info until the query is reset either by stopping the fake ARP broadcast and sending good data to repopulate tables, or times out and things restore themselves after a normal ARP takes place by a machine that queries for the IP of another. A ping of another machine can also reset this which should trigger an ARP reply, even if the ping itself is blocked. This is also a way to see if a machine is up, even when a PING is blocked, but it shows up in your arp table after the ping is sent. ;)

Link to comment
Share on other sites

On 3/4/2017 at 0:06 AM, GermanNoob said:

Thank you very much, @IDNeon for your detailed answer! I really appreciate the time you invested in trying to help me!

As I have access to the network using wifi. So if I understand you right, then I could do this:

Asking a device that is also connected using wifi for its hardware address. As I got that within my ARP table I could arpspoof that device and as the packets are already addressed to the hardware address of the target it shouldn't be sent over the whole network where an IDS could be used.

Is that right? 

Well if I understand your question right, then yes you should be able to arpspoof your traffic on the network and piggy-back on the traffic of legitimate devices as long as it doesn't need to be routed, but the reply will only go back to the devices you spoofed depending on how the AP makes a connection to each device, and depending on how creative you are in building your packets (i.e you could arguably change the return mac to what you want it to be but defeats the purpose of spoofing).

Might be easier to connect authentically with a bunch of virtual adapters with their own MAC addresses

Edited by IDNeon
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...