Hi everyone,
I've been evaluating ettercap's features in my LAN and now I got a problem that I just can't solve. After 2 days trying to find out what's going on, I finally gave up. So, here I am, asking for a few clarification words. :) Maybe I've missed something. Heh.
My main distro is not BT, but Debian squeeze. I would try ettercap's forum for this issue, but it seems to be "dead". As I believe it's not directly Debian related, the place containing people with enough knowledge on the subject would be here. Hope it's not a problem (and this is the right forum to do so).
I'm running ettercap NG-0.7.3 in Debian squeeze, kernel 2.6.33-amd64.
So, here we go: ettercap's built-in dissectors don't work at all, as it seems to receive corrupt/malformed packets from the network. SSL dissector, which uses iptables for redirection does works though. Strangely enough, if I fire wireshark and start capturing, I can see the packets correctly (and a lot of out-of-order or duplicated ACKs, which I believe is normal.. sort of). Since I used official packages from Debian repo, I tried to compile ettercap myself, with --enable-debug and see if there was any clues about what's going on in its logs. Unfortunately, no. Dissectors aren't fired, never (except for the SSL), and no relevant log entry.
I booted BT4 Final to give it a try. To my surprise, it does works! ettercap sees all packets correctly, dissector works perfectly. Even dissector-dependent plugins (for URL sniffing), like remote_browser works.
Tried the same ettercap parameters with 2 different wifi cards: Intel 4965AGN and a external RTL8187L. Same results, Debian = corrupt packets, BT = 100%. Here is the command line I've used in the tests:
Code:
ettercap -Tq -M arp:remote -i wlan0 /192.168.1.1/ /192.168.1.7/ (.1 = GW / .7 = Target)
Here is a sample packet dump from both distros, with target visiting yahoo (trimmed the log, just the initial packets are enough, as the same behavior occurs in the other packets):
Debian
Code:
Sat Apr 3 00:27:44 2010
UDP 192.168.1.7:38563 --> 192.168.1.1:53 |
.)...........ww w .yahoo. com.....
Sat Apr 3 00:27:44 2010
UDP 192.168.1.1:53 --> 192.168.1.7:38563 |
.)...........ww w .yahoo. com..................fp.wg1.b...+.......:......
Sat Apr 3 00:27:44 2010
TCP 192.168.1.7:39979 --> 200.152.168.178:80 | S
Sat Apr 3 00:27:44 2010
TCP 200.152.168.178:80 --> 192.168.1.7:39979 | SA
Sat Apr 3 00:27:44 2010
TCP 192.168.1.7:39979 --> 200.152.168.178:80 | A
Sat Apr 3 00:27:44 2010
TCP 192.168.1.7:39979 --> 200.152.168.178:80 | AP
LYwArdhObVDnZEZeRFdFiwDvwxmM_j7RiEiWs-; GZ=Z=0.
.
.pt>(function(){
var b,d,e,f;function g(a,c){if(a.removeEventListener){a.removeEventListener("load",c,false);a.removeEventListener("error",c,false)}else{a.detachEvent("onload",c);a.detachEvent("onerror",c)}}function h(a){f=(new Date).getTime();++d;a=a||window.event;var c=a.target||a.srcElement;g(c,h)}var i=document.getElementsByTagName("img");b=i.length;d=0;for(var j=0,k;j<b;++j){k=i[j];g(k,h);if(k.complete||typeof k.src!="string"||!k.src)++d;else if(k.addEventLi
Sat Apr 3 00:27:44 2010
TCP 200.152.168.178:80 --> 192.168.1.7:39979 | A
BT
Code:
Sat Apr 3 00:42:50 2010
UDP 192.168.1.7:52383 --> 192.168.1.1:53 |
Q............ww w .yahoo. com.....
Sat Apr 3 00:42:50 2010
UDP 192.168.1.1:53 --> 192.168.1.7:52383 |
Q............ww w .yahoo. com..................fp.wg1.b...+......."......
Sat Apr 3 00:42:50 2010
TCP 192.168.1.7:40942 --> 200.152.168.178:80 | S
Sat Apr 3 00:42:50 2010
TCP 200.152.168.178:80 --> 192.168.1.7:40942 | SA
Sat Apr 3 00:42:50 2010
TCP 192.168.1.7:40942 --> 200.152.168.178:80 | A
Sat Apr 3 00:42:50 2010
TCP 192.168.1.7:40942 --> 200.152.168.178:80 | AP
GET / HTTP/1.1.
Host: ww w. yahoo. com.
User-Agent: Mozilla/5.0 (X11; U; Linux armv6l; en-us; rv:1.8.1) Gecko/20061010 Firefox/2.0 Midori/0.2.2.
Accept: application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5.
Accept-Encoding: identity.
Cookie: B=f7kbq9p5qcvg2&b=3&s=nl; fpc=d=ylesXqt4UbE9H..wHoKnfp4gka.8zmm.FUjsr5LvHV3peW86CTzUoQrP6IaBskkW8qSEEpYzUjODh9BWYlo9w5IXHsLfg7sldIc1Yb42bMrXzsLBuLyg0v5oURAaIqKksQP.t_HXCK2N1pZ1RrihsnCsJLy244.qSc0_EZsoj43RSQOeSEJD_Jojekhlg1Qwm7Z2n.M-&v=2.
.
Sat Apr 3 00:42:50 2010
TCP 200.152.168.178:80 --> 192.168.1.7:40942 | A
As you can see in Debian, the packets are likely incomplete or with some "offset", so the dissectors, nor plugins, can correctly parse useful data from it. ARP poisoning is working perfectly, as shown by chk_poison and wireshark.
The first DNS resolution packets (UDP) seems to be OK in both distros, but not TCP ones.
I have no idea on where to look now. Maybe something is trashing the packets before it arrives in ettercap.
If someone have one (or many) ideas to share, I'll be very grateful. :) If more info are needed, please tell me, I'll promptly reply.
Best regards.
0day.today (was: 1337day, Inj3ct0r, 1337db)
OSVDB Vulnerabilities
Exploit-DB
SecurityFocus Vulnerabilities
Bugtraq
XSSed
Packet Storm Security Headlines (1 unread)
Sophos security news
Penetration Testing
SecuriTeam
BackTrack Linux Forums
Threatpost
SecDocs
carnal0wnage.attackresearch.com
Carnal0wnage
Darknet
The Exploitant
Hack a Day
Wirevolution
![Permalink for '[dos / poc] - Midori Browser 0.3.2 Denial Of Service Object++ Exploit'](/themes/lilina/web//media/mark_off.gif.pagespeed.ce.FiDKaoEBZK.gif)