Wired passthrough with packet dump?

[Tech]

Would it be possible to set the device in passive passthrough, or active, and have it dump the traffic (tcpdump or the like)? Traffic in through the WAN port and out through LAN and use the wireless for management, and USB for storage.

[digininja]

You mean like this?

http://www.digininja.org/interceptor/

[ravenium]

In all fairness, the biggest problem I had with the interceptor was that the hardware used to initially build it was no longer available, and at the time using it with any other iteration of hardware was extremely involved. As in, "you'd better have a FON or you're going to have to figure out how to recompile/configure/build everything".

I'm not sure if that's changed, but given that the mk4 is meant to make the concepts of MITM (and other stuff) more accessible to the masses (and give us a standardized platform for our toys as well), this seems somewhat against the spirit of the project to just say "it's already been done, go here". Most of the tools on the pineapple have already "been done", too, but the mk4 makes it standardized and easier (as above).

Apologies if I misinterpreted your reply, but I think an interceptor mod for the mk4 would be an excellent use of its capabilities and perhaps a revival of the concept on better (and actual available) hardware.

[telot]

haha digininja just likes to show off his accomplishments - and who can blame him! ;)

You're right though ravenium, the pineapple hardware is an ideal candidate to replace the interceptor. If you dig back in the forums to when the mark4 first came out (with its dual ethernet ports) you'll see plenty of hints from Seb (who took over development of the pineapple for the mark3 and mark4) about possible interceptor functionally with the mark4. He has yet to deliver obviously, as I suspect he's run into some roadblocks. If thats not the case Seb, and you're holding back...oh man oh man that'd make an awesome christmas present! But I can see having difficulties in regards to the bridging required for karma'd victims to have internet access being incompatible with the bridging required for intercepting. I've always been hopeful that the interceptor functionality might come out as a separate firmware (perhaps from the man himself? /poke digininja) that we can load in lieu of the pineapple firmware. Or perhaps a button to switch "modes" or something.

Of course the ideal would be plugging in an ethernet cable from a switch to the wan port, using that for internet to karma'd victims (meaning the full jasegar pineapple functionality) plus also intercepting things to and fro the wired victim(s) plugged into the lan port - with mad tcpdumping everything to the USB drive and ettercapping the shit out of everyone and rick rolling and evil java pages and BEEF and OH MY GOD TAKE MY MONEY NOW right? Yeah...

Hopefully this will spur some lively conversation from the two virtuoso's who created these awesome tools that we all love so dearly

telot

Edited November 9, 2012 by telot

[Sebkinne]

The roadblock I hit was really just time. I'll push out a basic version before christmas I hope. That gives me time to work on some other things we have planned!

[Tech]

Digininja's interceptor is great, although I would be more than happy just dumping the traffic (with or without a filter) on USB storage.

Telot is thinking very similar to what I'm wishing for :) Adding MITM attacks for cabled clients aswell would be great. Interceptor functionality with wireless transfer even better.

[AlexSka]

You can do it :

* create bridge [eth0 + eth1]

* switch lan interface to wlan0

* install tcpdump

* capture all traffic with saving on flash drive or remotely with wireshark

nano /etc/condfig/network[/CODE]

change line :

[CODE]
config interface lan
option ifname eth0
[/CODE]

to

[CODE]
config interface lan
option ifname wlan0
[/CODE]

for connection via WiFi

delete another configs & add

[CODE]
config 'interface' 'sniff'
option 'type' 'bridge'
option 'proto' 'none'
option 'ifname' 'eth0 eth1'
option 'auto' '1'
[/CODE]

restart network services

[CODE]
/etc/init.d/network restart
[/CODE]

now you can run :

[CODE]
tcpdump -vv -i br-sniff -w /usb/capture.cap
[/CODE]

you can read this: http://wiki.openwrt.org/doc/uci/network

Edited November 9, 2012 by AlexSka

[ravenium]

I'm always definitely in awe of the sheer number of cool things that are contributed and the time you spend giving to the community. Props have been given before, but I'll gladly give them again :)

USB storage would be nice, but I could see it filling quickly for a hardwired pcap. I think the advantage of the interceptor would be the wifi rebroadcast - I can slip the device behind an existing connection (let's say a register during a physical engagement as an arbitrary example) and sit back in the comfort of a nearby location to observe. Granted that's the harder part from the looks of things - well, that and the ability to not bulldoze the existing functionality.

[AlexSka]

You can always use it :

root@bt:~# mkfifo /tmp/pineapple-rx
root@bt:~# ssh pineapple_ip “tcpdump –s 0 –U –n –w - -i br-sniff” > /tmp/pineapple-rx
[/CODE]

[CODE]
root@bt:~# wireshark –k –i /tmp/pineapple-rx
[/CODE]

for remote capturing

where br-sniff = bridged(eth0 + eth1)

br-lan = wlan0 for ssh connection

Edited November 13, 2012 by AlexSka

[governor]

After having the inspiration from my pineapple, I played around with AP121U a couple of months ago and this was the result:

http://blog.kadiraltan.com/homemade-inline-network-sniffer/

Some experiences as much as I remember: dumping wired traffic to USB and having access via WiFi (smb/ssh/ftp etc.) worked very smoothly. Web mitm along with dnsspoof, tcpdump, ettercap etc... The performance was up to 40-60mbits while tcpdump'ing (if I recall correctly). Possible to use for VOIP pentest with appropriate tools. Also set the reset button to a default connectivity options for recovery (was easy to kick yourself out accidently while massing around). Wireshark, Cain, networkminer etc. can analyze the dump via smb during tcpdump if you connect a Windows via Wifi, otherwise backtrack is your friend for the rest anyway. As far as I remember only sslstrip caused memory issues. Beside that it was possible to implement various scenarios.

[WatskeBart]

nano /etc/condfig/network[/CODE]

Little typo there ;) it should be:

[CODE]
nano /etc/config/network
[/CODE]