Slashdot Mirror
Unhealthy Sniffing
Simon Doring writes "Stefan Esser did it again. Yesterday he reported 13 remote root vulnerabilities in Ethereal. Time to teach all those sniffing kiddies an unhealthy lesson. The next LAN party will be a lot of fun."
← Back to Stories (view on slashdot.org)
network sniffers are useful for other things as well.
just this spring had to use ethereal on one networking course to follow ethernet packets, which computer was asking what from who, how the router affected the packets and how a hub is different from a switch(all and all quite basic stuff but still it was quite useful for gaining insight to the different protocols in real world like situation)..
how about the windows port?
world was created 5 seconds before this post as it is.
Sounds like a good time to check out Ettercap
Short Description:
Ettercap is a multipurpose sniffer/interceptor/logger for switched LAN.
It supports active and passive dissection of many protocols (even ciphered ones) and includes many feature for network and host analysis.
The right way to do passive scanning is with an ethernet cable that has the tx leads removed. It is physically impossible to effect the network, as far as I understand it (not very far).
I imagine that the right way to do passive wifi scanning would require support from your driver and hardware, to ensure that you were not transmitting any packets at all.
And no, I don't know anything about Ethereal. I'll shut up now.
There are no trails. There are no trees out here.
Yeah, I don't like remote root exploits any more than the next guy, but are there a lot of people who run this 24/7? For the one hour a week I run this tool, I'm not AS concerned as if it was my OS with those vulnerabilities *cough*Windows*cough*.
Yes, I am an agent of Satan, but my duties are largely ceremonial.
These bugs can also be used to catch war drivers. Another trick I've seen in a white paper was to transmit fake traffic from an unused IP address and watch for reverse DNS lookups.
'SBEMAIL!' is better than a goat!!
Yea, but a common way to configure the sensors is to have one side plugged into the "trusted" internal network and the other side as an un-addressed interface in promiscuous mode. Ideally this would prevent someone on the outside from ever hopping into your internal LAN, but even if you cut the tx leads, the recent vulnerabilities in snort and I assume ethereal would allow a remote attacker on the untrusted network to exploit your sensor and gain access to your internal net which undoubtably has access to the Internet through some mechanism to talk back to the attacker. Lovely. Moral of the story is to use an isolated admin net for the sensors so if they get compromised, no big deal.
The right way to do passive scanning is with an ethernet cable that has the tx leads removed.
Can't do that with UTP. The link pulse travels over the same wire, so the hub or switch will deactivate the port and you won't see any traffic at all. What you can do is cut the TX pin on the AUI connector when using an external tranceiver, but nobody uses those any more.
In BSD derivatives, you can up an interface without giving it an address, attach to it with bpf and set it in promiscuous mode. You'll see all the traffic on the wire, but none of it will go into the network stack and no outgoing traffic will be generated unless you do it yourself.
(I write network analysis software for a living)
Ethereal is a valuable network diagnostic tool. It has saved my ass a couple of times, and it has been helpful many times. I was the only person in my Networks class in college that was able to do my assignments from my room, everybody else had to go to the lab to use the commercial sniffer.
On the other hand, 13 vulnerabilities isn't too terrible and hopefully they'll get them patched up straight away. I'm sure that your average commercial packet sniffer probably is probably just as bad or worse, and those bugs aren't getting fixed.
-73, de n1ywb
www.n1ywb.com
Thanks to ProPolice on OpenBSD, these stack overflows will only lead to a crash, not a root exploit on this OS.
Gentoo has a project called "Hardened Gentoo" where the stack overflow would just chrash the Ethereal.It's time the bigger Linux distros implement similar technology (that exist as PaX).
(I write network analysis software for a living)
I write VB front ends to SQL databases for a living.
I'm going to go with you on this one.
There are no trails. There are no trees out here.
I use tcpdump to capture what is on the wire... which is run as root.
Then, as a non-root user, I pull the data into ethereal.
I do this because the network is over a thousand miles away and the machines don't even have X on them... so... I capture remotely and then look at the data on my workstation.
--Phillip
Can you say BIRTH TAX
You've got to hand it to the ethereal team for their quick fixes.
The bottom of the advisory states that they were made aware on the 5th of March, and by the 23rd of March all the holes were fixed.
So, yes, they did let them know, and the holes have already been fixed.
"From my cold, dead hands you damn, dirty apes!" - CH
It's in TFA:
Disclosure Timeline
5 March 2004
Ethereal developers were contacted by email telling them about 10(of the 13) holes. 6 holes were closed the same day EIGRP, IGAP, ISUP and BGP.
7 March 2004
IRDA hole closed (after checking specs)
8 March 2004
PGM hole closed (after checking specs)
9 March 2004
NetFlow hole closed (after checking specs)
17 March 2004
UCP holes were discovered and mailed to vendor
19 March 2004
UCP and TCAP holes closed (after checking specs)
22 March 2004
Ethereal developers have releases a mini advisory urging their users to upgrade to version 0.10.3 which will be released later this week
23 March 2004
Public Disclosure
Want to improve your Karma? Instead of "Post Anonymously", try the "Post Humously" option.
Another case of needing a new moderation...
I touch computers in naughty places
It's true that you can't just cut the tx wire, but you _can_ rig it so a hub can see it but no xmit will occur.
Search google for "sniffer +stealth". There is a site with plans to build a non-transmitting cable. It also discusses the theory of how it works. (I can't verify a link because those kinds of sites are blocked here at work.) It involves cutting _one_ of the TX wires and inserting a capacitor in series to form a hi-pass (or is it low-pass?) filter. This causes the hub to see all "1" bits (and out of parity) from the NIC. The hub will turn on the link light even though it never gets good data, so then the NIC can receive just fine.
I've built one of these into an inline RJ-45 coupler and it works great. As explained on the site, the value of the capacitor depends in the ethernet speed, so it's different for 10mb or 100mb.You were 80% angel, 10% demon. The rest was hard to explain. - Over The Rhine
"Math in a song is good."-Linford
Can't do that with UTP. The link pulse travels over the same wire, so the hub or switch will deactivate the port and you won't see any traffic at all. What you can do is cut the TX pin on the AUI connector when using an external tranceiver, but nobody uses those any more.
In BSD derivatives, you can up an interface without giving it an address, attach to it with bpf and set it in promiscuous mode. You'll see all the traffic on the wire, but none of it will go into the network stack and no outgoing traffic will be generated unless you do it yourself.
(I write network analysis software for a living)
Ok.. UTP 101.. let's use EIA/TIA568B FastEthernet here (toss this out if you're sniffing GigE traffic)...
pin 1 -> white/orange
pin 2 -> orange
pin 3 -> white/green
pin 6 -> green
Following traffic from switch to host, the pins are as follows:
pin 1: RX+ (receives from host)
pin 2: RX-
pin 3: TX+ (transmits to host)
pin 6: TX-
The *proper* way to do this is start with a normal cable. At the host end, cut into the cable jacketing a little ways up from the terminator and cut the white/orange and orange wires, then solder lead 1 to 3 and lead 2 to lead 6 (white/orange to white/green and orange to green). Do this for the side of the cable headed towards the switch and leave pins 1 & 2 "dangling" to the host. The cable is unidirectional and it can only connect between the switch and host *one way*. This is safer than depending on an unaddressed promiscuous port because there is phyically *no way* for data to get to the switch from the host, but the host will see everything on the wire.
You can get a little more freaky and use a small capacitor inline (I can't recall the value at the moment, but it's specific to the speed of the wire) to simply put too much noise to pass traffic but not so much as to drop the connection, but the solution above works just swimmingly well if you're handy doing small task soldering and wire stripping.
(I sniff networks for a living)