0

using the popular bettercap tool and observing responses I had two doubts that also concerns some theoretical questions:

  1. Bettercap allows you to arp spoof entire ranges of ip-s (e.g. an entire /24 subnetwork you're in), but as far as I know do an arp spoofing attack consists in "telling" the router (the gateway) that the ip xxx.xxx.xxx.xxx correspond to your physical address (MAC) and not to the one of the target: it is possible to do so for RANGES of ip-s? Can an ARP table contain a range of ip-s instead of a single one as an entry?

  2. Bettercap also allows you to launch a proxy you can use to "interact" with traffic when you're spoofing it; in the case of https proxy (SSL strip DISABLED by default) bettercap outputs some information about the https request header (for example user-agent ecc...), but what I know is that https is no more than http over SSL (TLS), so I was not expecting the tool to read https headers... What am I missing?

daya
  • 167
  • 2
  • 6
  • 20
ela
  • 125
  • 5
  • An ARP spoofing attack isn't necessarily against the gateway. It can be targeted at any host. Instead, it might be against the entire network to trick everyone into thinking you are they gateway. It can also be done simultaneously against the gateway and another host in order to capture traffic bidirectionally. – multithr3at3d Sep 23 '18 at 16:15

1 Answers1

0

Can an ARP table contain a range of ip-s instead of a single one as an entry?

There is no need for a range. But an ARP table can have multiple IP associated with the same MAC. It is actually not uncommon for servers to have multiple IP addresses on the same physical interface.

... but what I know is that https is no more than http over SSL (TLS), so I was not expecting the tool to read https headers... What am I missing?

The https proxy is doing a man in the middle attack against TLS, i.e. generating certificates on the fly. Of course, unless the https client is either buggy or specifically setup to accept these certificates as trusted, the client will complain that the connection is insecure because the certificate is not trusted.

Steffen Ullrich
  • 184,332
  • 29
  • 363
  • 424
  • could you please make the second point a little more clearer to me? Let's say client A makes and HTTPS request to server B and attacker C with https proxy on is in the middle and intercept the request, how can him read the request? Are you telling to me that the attacker tells to the client A that he is server B issuing a false certificate? – ela Sep 23 '18 at 12:41
  • @AlessioMartorana: *"Are you telling to me that the attacker tells to the client A that he is server B issuing a false certificate?"* - exactly. And unless the attacker either hacked the original server B to get the original certificate or hacked a trusted CA or hacked the client A to trust the attackers certificate, a properly implemented client will not trust the fake certificate and complain. – Steffen Ullrich Sep 23 '18 at 13:34