Ok - to clear the confusion - this is done by spoofing and placing
yourself on that local segment - and you can obtain any MAC address you
are able to connect to - note I pulled the MAC of the IP of the guy that
asked me to look at it - this was done by sitting on his network with a
spoofed packet to his game server and did an ARP Request. I'll just
tell you its very possible and its done everyday - I do not feel its my
place to tell someone how to 'hack' and/or spoof to gain access to a
segment of a network to listen to the broadcasted traffic.
Britt
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Frank
Stollar
Sent: Wednesday, July 23, 2003 1:28 PM
To: [EMAIL PROTECTED]
Subject: Re: [hlds_linux] Reporting Server Hackers
Well, nice you give an complete answer on my questions. But there are
some points I strongly disagree:
Britt Priddy (PZGN) wrote:
> I understand the logic you're thinking and how easy it is to 'sniff'
> traffic even on a network that is not inline - but all you have to do
> is get an arp request from the IP in question - which then gives you
> the MAC Address of that Network card
Sorry that is impossible as, like Mad said already, MAC addresses are
for local links only and do not cross over routers.
> Ie - say you have a web server running - I can
> establish a connection with that server and knowing its MAC Address
> and IP - I can lock onto and watch all inbound/outbound traffic (in
> TCP Packet view) - save the log - then parse through it to see the
> data - its time consuming as hell.
I will try me in clearifing:
###----------###---------###
^ ^ ^
Victim Router Attacker
If you establish a connection to 'Victim' you will send an ARP request
for that IP to the router between us. This router itself know, that this
IP you request is on the other side. So the router will answer _your_
ARP-request with HIS MAC. Ok, now you are sending the IPv4 packet with
destination IPv4 of 'Victim' to the MAC address you got from your
ARP-request, the MAC of the router. The router itself does also not know
the MAC for the IP of the 'Victim' and send also an ARP-reqeust to the
left side. This will be answerd by the 'Victim' machine by his MAC. Now
the router is sending your IPv4 packet to the MAC of 'Victim'. When
Victim wants to answer the packet it goes vice versa, send an
ARP-request which will be answered by the router. Send the IP packet to
the router which will ARP-request the IP of 'Attacker' and will send the
answering IP packet to the MAC of Attacker but with his OWN MAC.
> As for your machine - I see SSH running that's pretty much it as far
> as anything I can connect to to establish an open connection. IP
> 141.84.69.34 = MAC = 00:09:b7:27:84:a0 Almost 99% UDP traffic is seen
> - which as you probably know is just raw data in clear text (probably
> your cs/tfc server)
Look for yourself:
bigbadaboom:~# ifconfig
eth0 Link encap:Ethernet HWaddr 00:00:CB:56:56:CC
inet addr:10.150.127.30 Bcast:10.150.127.255
Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:121311890 errors:1 dropped:0 overruns:0 frame:0
TX packets:99285661 errors:60 dropped:0 overruns:0 carrier:60
collisions:0 txqueuelen:100
RX bytes:2021109323 (1.8 GiB) TX bytes:1738254273 (1.6 GiB)
Interrupt:10 Base address:0xc00
eth0:0 Link encap:Ethernet HWaddr 00:00:CB:56:56:CC
inet addr:141.84.69.34 Bcast:141.84.69.255
Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Interrupt:10 Base address:0xc00
As you can see is the HWaddr=MAC not the same you specified. The 99% UDP
traffic is easy to guess, if you scan the machine for services and found
a few CS servers running. This can be provided with nmap or similiar
port scanners.
> I seen you had players online and did not want
> to chance interfering with that so I did not try connecting to your
> half-life ports to gain a connection. So I did it to a friends server
> and it basically floods you with UDP traffic - which is in clear text
> but also has binary data in the UDP packets - but if you streamed that
> to a file for a good awhile and had the patience to thumb through it -
> sooner or later you'd see what you was looking for.
If you are disturbing connections of the victim, you are not sniffing
anymore. The definition of 'sniffing' is to read the data of the packets
of a established connection without modifing or altering them. If you
are do ARP spoofing, which is also very limited, you are distroying the
connections between 'Victim' and 'Client'. This can be compensated to a
certain degree but is also easly detectable.
> And in someone just posted:
> ">It cannot be done until you compromise one of linkpath routers or
> you will be connected with that router through Ethernet link.
> >>Ofcourse arpspoofing is detectable and certain protection measures
> can be achieved by using proper software/hardware. "
> This comment is very close to how it is achieved - its hard to explain
> and its just a tool that an inteligent hacker came up with - and I
will
> not post it due to the nature of this program. It does fool the dest.
> MAC after the ARP request to gain the info and construct the packet to
> listen (which makes it thinks its on the same segment when its not) -
> and yes - if you have an inline intrustion detection system or strong
> firewall - you can stop this because there is a flaw in the spoofed
> packet that is built - and note I'm only referring to IPv4.
Sorry but this reads like nonsense. I really give my best to see any
sense in 'fool the dest. MAC after the ARP request'. Which destination
MAC on which side of the network? And what is 'which makes it thinks its
on the same segment when its not' ? Whom makes it think? The Victim? The
router or all the routers between you and the victim?
Again some grafics:
$$$-----###-----###-----###-----###-----%%%
|
|
&&&
$$$ = Victim
### = Routers
%%% = Attacker
&&& = Client having connection to Victim $$$
Ok, please descripe how you will alter the ARP cache of all routers
between you and the Victim? As every router does only see the MAC of its
neigbhours and ARP-requests are not routed at all.
Espacially this would be very hard if anywhere between two routers is no
ethernet-link but ATM or any other Layer2 protocol. In no other Layer2
are ARPs present. How you will spoof someting which is not available in
that enviroment? That is very interesting as I know 4 hops from my
server I am connected to an ATM backbone, neglating all ARP requests.
> I have not
> tried filtering UDP only because it forces me to have an open
> connection to the destination address - and I think this prog was for
> TCP mainly but it will read UDP traffic but make that its primary
> connection because there is no sequence or format to a UDP packet vs.
> a TCP packet.
Spoofing is much more easy to UDP than TCP as this is a connectionless
protocol. Later I will provied some links descibing how ARP-spoofing is
done.
> Anyway - didn't mean to make an up-roar over this - if you search
> around, I'm sure you'll find more tools that you'd care to know about
> that these script kiddies have access to - but most of them require
> knowledge of tcp packet headers and its contents, etc. Some conversion
> of binary to decimal, etc
There are really good explantations or ARP and ARP-spoofing:
http://www.rootsecure.net/content/downloads/pdf_downloads/arp_spoofing_i
ntro.pdf
and drafts dealing with it:
http://www.ietf.org/internet-drafts/draft-dattathrani-tcp-ip-security-01
.txt
As can be clearly seen, all ARP attacks are only dealing ins ethernet
LANs, switched at most but no routers at all. And 'conversion vom binary
to decimal' can be done with in windows included calculator, so no
challange at all.
But I'm real interested in this subject. If you have arguments against
mine, don't hesitate to share with us. See this as a challenge not an
offence.
cheers
Frank
_______________________________________________
To unsubscribe, edit your list preferences, or view the list archives,
please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
_______________________________________________
To unsubscribe, edit your list preferences, or view the list archives, please visit:
http://list.valvesoftware.com/mailman/listinfo/hlds_linux
