Robin’s segment regarding ARP was good value, even if two_ovens’ comment regarding multiple APs is true (you do get a different MAC for every AP when extending a ESSs). The tool comes with source so this could be fixed with a white-list. A good method to defend yourself against mitm IP attacks is to use a layer-2 authenticated PPPoE connection to your gateway or OpenVPN with cert stored on USB key and hung around your neck.

The botnet stuff is good, just another reason to white-list known outbound traffic and push all http via a logged proxy.

Make sure you get the Google map road blogging stuff setup cause I want to follow the journey.

Snubs, hope your father gets well soon.

Good luck!

Snubs, hope things go well for your Dad.

Anyway, live on pashion! So vicariously through you, I can too!

Good luck guys.

to whom it may concern,
in order to bypass the human detector and moderation mailing, use firefox 3.5.2 and noscript (whatever the newest one is). post your comment with noscript blocking. when the human detector comes up, no image will be displayed. hit continue and you’ll get an error. hit back twice to go back to your post. disable noscript (allow all) then post the comment again.
once that’s done, both comments will be displayed (bug 1) and the second of those will post directly without waiting for moderation (bug 2).
sorry about the double posting. and the posting without moderation.

keep up the good work.

Regards,
Tener Hades.

So I was wondering why the Brit decided that the only reason for a default router MAC addr to change was multihoming/load balancing when extended service sets (ESSs; WLANs with more than on access point) do exactly that, by design. Especially in you example: airports. Airports utilize a huge ESS wireless network. The SSID remains containt the default router’s MAC – that which the AP connects to – remains constant, but the AP’s MAC, which is passed to the client, changes as the user roams and changes from access point to access point.

btw, multihomes and load balancers won’t change their mac addresses because my connection to my default gateway is much faster than my gateway’s connection to the internet. and all of your routers have static port-security for their next hop addresses anyways. right?

I also had a problem with the tool you advertised for, CaffeinatID or whatever. From a technical perpective, the demonstration with that tool was that it could watch ARP information by querying the DARP list on the local machine. So if the tool is started after the poisoning occurs, the tool is useless; or less than useless because after the offending packets stop coming at your host, it will pop-up a false-positive of “Hey, now you’re using the correct router. You should have been worried, but I couldn’t tell”

Also, you mentioned Ettercap. Ettercap itself, IIRC, allows and assists in the use of 4 different kinds of MITM attacking. The one I’d like to focus on is DHCP poisoning because it applies to the situation of wireless access points more so than ARP.

You see, ARP can me made semi-static: A simple shell script in any real OS (or a lengthy program in Windows) has the ability to grab the very first ARP response from the default router (note: a legitimate response and not an unrequested “reply” like those that arpspoof sends), and put it into a file and drop the connection, alert the user (syslog, zenity, both?). Therefor ARP is a terrible medium for MITMing due to predictability (I won’t even get into timing of responses from legitimate routers). Furthermore, ARP poisoning can be bypassed easily with static ARP tables. And less easily with another shell script (if an unrequested reply comes in, filter all activity and wait for the next out-of-line “reply”. when it comes, find out the difference in time from the first so we can predict when another one will come. put the user back online. everytime an unreq’d arp reply comes in: take the user offline, request an arp for the default router’s IP. time the response so we have a better idea of if it’s right. use THAT arp. put the user back online. and later on.. if we get more than, say, 180 unrequested replies, then put a static entry for the correct router in the arp cache and wait for the skiddie to lose interest)

DHCP poison-based MITM attacking is much cleaner. Even with a race condition between attacker and router (to get to client). At that point. You only talked about WLANs though, why not just FakeAP?

Longer story short, you covered one the oldest and most thought-about poisoning techniques…… Bombshell? Why not cover something interesting?

like rooting an android and performing tcpdump from it… without it ever leaving you pocket

BTW, Love the show. Where are you guys out of?
Regards,
Tener Hades.

So I was wondering my the Brit decided that the only reason to for a default router MAC addr to change was multihoming/load balancing when extended service sets (ESSs; WLANs with more than on access point) do exactly that, by design. Especially in you example: airports. Airports utilize a huge ESS wireless network. The SSID remains containt the default router’s MAC – that which the AP connects to – remains constant, but the AP’s MAC, which is passed to the client, changes as the user roams and changes from access point to access point.

I also had a problem with the tool you advertised for, CaffeinatID or whatever. From a technical perpective, the demonstration with that tool was that it could watch ARP information by querying the DARP list on the local machine. So if the tool is started after the poisoning occurs, the tool is useless; or less than useless because after the offending packets stop coming at your host, it will pop-up a false-positive of “Hey, now you’re using the correct router. You should have been worried, but I couldn’t tell”

Also, you mentioned Ettercap. Ettercap itself, IIRC, allows and assists in the use of 4 different kinds of MITM attacking. The one I’d like to focus on is DHCP poisoning because it applies to the situation of wireless access points more so than ARP.

You see, ARP can me made semi-static: A simple shell script in any real OS (or a lengthy program in Windows) has the ability to grab the very first ARP response from the default router (note: a legitimate response and not an unrequested “reply” like those that arpspoof sends), and put it into a file and drop the connection, alert the user (syslog, zenity, both?). Therefor ARP is a terrible medium for MITMing due to predictability (I won’t even get into timing of responses from legitimate routers). Furthermore, ARP poisoning can be bypassed easily with static ARP tables. And less easily with another shell script (if an unrequested reply comes in, filter all activity and wait for the next out-of-line “reply”. when it comes, find out the difference in time from the first so we can predict when another one will come. put the user back online. everytime an unreq’d arp reply comes in take the user offline, request an arp for the default router’s IP. time the response so we have a better idea of if it’s right. use THAT arp. put the user back online. and later on.. if we get more than, say, 180 unrequested replies, then put a static entry for the correct router in the arp cache.

DHCP poison-based MITM attacking is much cleaner. Even with a race condition between attacker and router (to get to client). At that point, though, why not just FakeAP?

Longer story short, you covered one the oldest and most thought-about poisoning techniques…… Bombshell? Why not cover something interesting?

like rooting an android and performing tcpdump from it… without it ever leaving you pocket