Netgear RP614 leaking - Networking

This is a discussion on Netgear RP614 leaking - Networking ; Chill Out a écrit : > > Are you sure thats what it says?? Yes, quite. > I read that packet came from MAC ff:....06:14 The 14-byte hexadecimal string after MAC= is the MAC *header* and not only the source ...

+ Reply to Thread
Page 2 of 3 FirstFirst 1 2 3 LastLast
Results 21 to 40 of 44

Thread: Netgear RP614 leaking

  1. Re: Netgear RP614 leaking

    Chill Out a écrit :
    >
    > Are you sure thats what it says??


    Yes, quite.

    > I read that packet came from MAC ff:....06:14


    The 14-byte hexadecimal string after MAC= is the MAC *header* and not
    only the source MAC address of the received packet. The first 6 bytes
    are the destination address, the next 6 bytes are the source address and
    the last 2 bytes are the ethertype (or the data length when its value is
    less than decimal 1500).

    > which is most likely the
    > ethernet port on the Netgear 614rp, as a returned normal WWW request
    > from 208.71.112.64 to the user at 10.00.0.101.


    No, as someone already said an HTTP communication would use TCP instead
    of UDP.

  2. Re: Netgear RP614 leaking

    On Thu, 11 Sep 2008, in the Usenet newsgroup comp.os.linux.networking, in
    article , Mark Hobley wrote:

    >Pascal Hambourg wrote:
    >
    >> Please don't edit. This is useless and confuse people here. The
    >> scope of a MAC address is limited to the connected ethernet link,
    >> so you won't be attacked because you posted it. What else did you
    >> edit ? If you edited the ethertype 06:14, what is the original
    >> value ?


    http://standards.ieee.org/regauth/ethertype/eth.txt

    [compton ~]$ zgrep "^[0-9][0-9]14 " rfcs/ieee.ethertype.eth.gz
    8114 - 8118 Software Consulting Services Protocol unavailable.
    8914 Brocade FIP Storage Access Protocol
    [compton ~]$

    There is no 0x0614 type.

    >I did not edit the ethertype. However, the internal MAC address and
    >internal station IP have been falsified.


    Please don't waste everyone's time this way.

    >I believe that it is possible to compromise a network if you know the
    >internal MAC addresses and station IP addresses being used.


    Only if the attacker is already on your LAN. In that case it doesn't
    matter, because it's far to late.

    >> Unless the routing is very asymmetric, this host is not next to your
    >> router.

    >
    >You are correct. The host is not next to my router.


    UDP is trivial to spoof - you might try using a packet sniffer to see
    what's inside that packet. Don't bother posting it if you are going
    to edit things. Then look at RFC0768, RFC0791 and RFC0894 help you to
    interpret it. RFC1700 is obsolete, but you can look at that to
    interpret variables within the packet headers.

    0768 User Datagram Protocol. J. Postel. August 1980. (Format: TXT=5896
    bytes) (Also STD0006) (Status: STANDARD)

    0791 Internet Protocol. J. Postel. September 1981. (Format: TXT=97779
    bytes) (Obsoletes RFC0760) (Updated by RFC1349) (Also STD0005)
    (Status: STANDARD)

    0894 A Standard for the Transmission of IP Datagrams over Ethernet
    Networks. C. Hornig. April 1 1984. (Format: TXT=5697 bytes) (Also
    STD0041) (Status: STANDARD)

    1700 Assigned Numbers. J. Reynolds, J. Postel. October 1994. (Format:
    TXT=458860 bytes) (Obsoletes RFC1340) (Obsoleted by RFC3232)
    (Status: HISTORIC)

    Old guy

  3. Re: Netgear RP614 leaking

    Moe Trin wrote:

    > Only if the attacker is already on your LAN. In that case it doesn't
    > matter, because it's far to late.


    No. There are other security related issues to be aware of.

    > UDP is trivial to spoof - you might try using a packet sniffer to see
    > what's inside that packet. Don't bother posting it if you are going
    > to edit things.


    I am not going to publish addresses of machines with a security related query,
    or information about how to compromise networks within my care. I don't
    understand why you think I need to do this.

    Mark.

    --
    Mark Hobley,
    393 Quinton Road West,
    Quinton, BIRMINGHAM.
    B32 1QE.

  4. Re: Netgear RP614 leaking

    Mark Hobley wrote:

    > Moe Trin wrote:
    >
    >> Only if the attacker is already on your LAN. In that case it doesn't
    >> matter, because it's far to late.

    >
    > No. There are other security related issues to be aware of.


    Please educate the group and provide some details.

  5. Re: Netgear RP614 leaking

    On Fri, 12 Sep 2008, in the Usenet newsgroup comp.os.linux.networking, in
    article <3tsqp5-kti.ln1@neptune.markhobley.yi.org>, Mark Hobley wrote:

    >Moe Trin wrote:


    >> Only if the attacker is already on your LAN. In that case it doesn't
    >> matter, because it's far to late.

    >
    >No. There are other security related issues to be aware of.


    Then why are you posting anything? Your paranoia is preventing those
    who do know something about networking from providing anything more
    than handwaving suggestions. Fine. Work it out yourself.

    >> UDP is trivial to spoof - you might try using a packet sniffer to see
    >> what's inside that packet. Don't bother posting it if you are going
    >> to edit things.

    >
    >I am not going to publish addresses of machines with a security related
    > query, or information about how to compromise networks within my care.
    >I don't understand why you think I need to do this.


    -rw-rw-r-- 1 gferg ldp 22582 Feb 6 2004 Reading-List-HOWTO

    "TCP/IP Illustrated, Volume 1 - The Protocols", W. Richard Stevens,
    Addison-Wesley, ISBN 0-201-63346-9, 1994, 1996, 576 pgs, US$79.99

    That's out of print, but you should be able to find it in any decent
    technical library, or on the web.

    Old guy

  6. Re: Netgear RP614 leaking

    Moe Trin a écrit :
    >
    > UDP is trivial to spoof


    Right, but IP spoofing does not explain the non-IPv4 ethertype nor the
    broadcast destination MAC address in the frame.

  7. Re: Netgear RP614 leaking

    On Thu, 18 Sep 2008, in the Usenet newsgroup comp.os.linux.networking, in
    article , Pascal Hambourg wrote:

    >Moe Trin a écrit :


    >> UDP is trivial to spoof


    >Right, but IP spoofing does not explain the non-IPv4 ethertype nor
    >the broadcast destination MAC address in the frame.


    The non-IPv4 ethertype is explainable by the fact that the O/P was
    altering the packet details, because he felt that information would
    give every hacker the key to own his network. The destination MAC
    being a broadcast, while the IP was a unicast suggested a crafted
    packet - arping, or hping for example, but given that the data was
    obviously falsified, it was a waste of time to analyze it further.
    That's why I referred the O/P to the RFCs and Stevens' book, to
    either let him learn that his paranoia was excessive, or so that he
    could solve the problem on his own.

    Old guy

  8. Re: Netgear RP614 leaking

    Boon wrote:

    > Please educate the group and provide some details.


    Using the same provider, you could use someone elses internet connection
    under certain circumstances, if you have this information.

    Mark.

    --
    Mark Hobley,
    393 Quinton Road West,
    Quinton, BIRMINGHAM.
    B32 1QE.

  9. Re: Netgear RP614 leaking

    Moe Trin a écrit :
    >
    >>>UDP is trivial to spoof

    >
    >>Right, but IP spoofing does not explain the non-IPv4 ethertype nor
    >>the broadcast destination MAC address in the frame.

    >
    > The non-IPv4 ethertype is explainable by the fact that the O/P was
    > altering the packet details


    This is what I thought first, but when I asked for confirmation the OP
    replied in that he hadn't
    altered the ethertype.

    > The destination MAC
    > being a broadcast, while the IP was a unicast suggested a crafted
    > packet - arping, or hping for example


    But then such a packet must have been sent directly from a host on the
    internal LAN. It could not have been sent from the outside and forwarded
    by the router, because the router would have written correct data in the
    MAC header.

  10. Re: Netgear RP614 leaking

    On Fri, 19 Sep 2008, in the Usenet newsgroup comp.os.linux.networking, in
    article , Pascal Hambourg wrote:

    >Moe Trin a écrit :


    >> The non-IPv4 ethertype is explainable by the fact that the O/P was
    >> altering the packet details

    >
    >This is what I thought first, but when I asked for confirmation the OP
    >replied in that he hadn't
    >altered the ethertype.


    The original post said:

    ][nnnnnnn,nnnnn] Inbound IN=eth0 OUT=
    ]MAC=ff:ff:ff:ff:ff:ff:00:01:02:03:04:05:06:14 SRC=208.71.112.64
    ]DST=10.0.0.101 LEN=72 TOS=0x00 PREC=0x00 TTL=254 ID=nnnnn PROTO=UDP
    ]SPT=80 DPT=38458 LEN=52

    and the "00:01:02:03:04:05:06" just screams "FALSIFICATION" - which is
    why I was looking at the xx14 Ethertypes.

    >> The destination MAC being a broadcast, while the IP was a unicast
    >> suggested a crafted packet - arping, or hping for example

    >
    >But then such a packet must have been sent directly from a host on the
    >internal LAN. It could not have been sent from the outside and forwarded
    >by the router, because the router would have written correct data in the
    >MAC header.


    He would also have had to configure the router to forward UDP - either
    all ports, or merely 80/udp - to this system. I would have to agree
    that the more likely source is something on the internal LAN.

    Old guy

  11. Re: Netgear RP614 leaking

    Moe Trin wrote:

    > He would also have had to configure the router to forward UDP - either
    > all ports, or merely 80/udp - to this system.


    Hmmm. Port 80 is forwarded, but not to this station. Could it be that
    the web server station is somehow "reflecting" UDP traffic?

    (The webserver is thttpd, if that matters.)

    There is no option to specify port forwarded by protocol within this
    router. A port is either forwarded, or not forwarded on the Netgear RP614.

    Mark.

    --
    Mark Hobley,
    393 Quinton Road West,
    Quinton, BIRMINGHAM.
    B32 1QE.

  12. Re: Netgear RP614 leaking

    Moe Trin a écrit :
    >
    > The original post said:
    >
    > ][nnnnnnn,nnnnn] Inbound IN=eth0 OUT=
    > ]MAC=ff:ff:ff:ff:ff:ff:00:01:02:03:04:05:06:14 SRC=208.71.112.64
    > ]DST=10.0.0.101 LEN=72 TOS=0x00 PREC=0x00 TTL=254 ID=nnnnn PROTO=UDP
    > ]SPT=80 DPT=38458 LEN=52
    >
    > and the "00:01:02:03:04:05:06" just screams "FALSIFICATION"


    Yes it does. :-) This is also a reason why I asked for confirmation.
    Besides, the packet being logged by iptables means that the IPv4 stack
    picked it, and I may be wrong but I strongly doubt that the IPv4 stack
    would pick a packet without the IPv4 ethertype.

  13. Re: Netgear RP614 leaking

    Mark Hobley a écrit :
    >
    > I believe that it is possible to compromise a network if you know the internal
    > MAC addresses and station IP addresses being used.
    >
    > Using the same provider, you could use someone elses internet connection
    > under certain circumstances, if you have this information.


    Ah, now I think may have an idea of what you are talking about. Actually
    I have two different cases in mind.

    1) Your provider is a cable ISP who uses the client's MAC address as a
    means of - poor - authentification. Does this still exist ? Note that it
    uses the external MAC address of your router, not the internal one
    (although they could be the same, depending on the model). A "neighbour"
    sharing the same link could spoof your external MAC address to be
    authenticated as if it were you - and possibly use your public IP
    address. However he does not use your connection, nor has access to your
    internal network.

    2) A "neighbour" sharing the same link could create a route to your
    station IP address using your external MAC or public IP address as
    gateway. Note that again it uses the external MAC address of your
    router. If your router does not filter incoming connections, the
    neighbour could reach your station.

    Are you in either of these situations ?

  14. Re: Netgear RP614 leaking

    On Sat, 20 Sep 2008 13:11:33 +0200, Pascal Hambourg rearranged some
    electrons to say:


    >
    > 1) Your provider is a cable ISP who uses the client's MAC address as a
    > means of - poor - authentification. Does this still exist ?


    I belive my ISP (TWC) is looking for the MAC address of the cable modem;
    but nothing beyond that.

  15. Re: Netgear RP614 leaking

    On Sat, 20 Sep 2008, in the Usenet newsgroup comp.os.linux.networking, in
    article , Pascal Hambourg wrote:

    >Moe Trin a écrit :


    >> The original post said:
    >>
    >> ][nnnnnnn,nnnnn] Inbound IN=eth0 OUT=
    >> ]MAC=ff:ff:ff:ff:ff:ff:00:01:02:03:04:05:06:14 SRC=208.71.112.64
    >> ]DST=10.0.0.101 LEN=72 TOS=0x00 PREC=0x00 TTL=254 ID=nnnnn PROTO=UDP
    >> ]SPT=80 DPT=38458 LEN=52


    >Besides, the packet being logged by iptables means that the IPv4 stack
    >picked it, and I may be wrong but I strongly doubt that the IPv4 stack
    >would pick a packet without the IPv4 ethertype.


    Not only that, but this also says that it's UDP and the 'LEN' numbers
    look like IPv4. That would be a lot of coincidences. If that were
    the case, he should be using the source to pick national lottery
    numbers - it's hitting better odds than pure chance.

    Old guy

  16. Re: Netgear RP614 leaking

    On Sat, 20 Sep 2008, in the Usenet newsgroup comp.os.linux.networking, in
    article , Pascal Hambourg wrote:

    >Mark Hobley a écrit :


    >> I believe that it is possible to compromise a network if you know the
    >> internal MAC addresses and station IP addresses being used.


    No - especially with NAT on the cable modem.

    >Ah, now I think may have an idea of what you are talking about. Actually
    > I have two different cases in mind.


    But both of those only provide Denial Of Service - pretty easily
    detected - not compromising the O/P's systems. It's the same as if
    you were to have a duplicate MAC on the LAN.

    >1) Your provider is a cable ISP who uses the client's MAC address as a
    >means of - poor - authentification. Does this still exist ?


    I'm not sure that has been the case for many years. The "bad guy"
    would have to be able to hack the cable modem to mess with the DOCSIS
    MIB signalling. Not impossible, but pretty easy to detect from the
    "victim's" (and provider's) point of view.

    >If your router does not filter incoming connections, the neighbour
    >could reach your station.


    I'm not using a Netgear RP614, but the advertisements for that unit
    claims it does NAT and Stateful Packet Inspection. One would hope that
    the manufacturer has heard of RFC2827 which is about 8 years old.

    Old guy

  17. Re: Netgear RP614 leaking

    david wrote:

    > I belive my ISP (TWC) is looking for the MAC address of the cable modem;
    > but nothing beyond that.


    You might be right.

    Mark.

    --
    Mark Hobley,
    393 Quinton Road West,
    Quinton, BIRMINGHAM.
    B32 1QE.

  18. Re: Netgear RP614 leaking

    Pascal Hambourg wrote:

    > 2) A "neighbour" sharing the same link could create a route to your
    > station IP address using your external MAC or public IP address as
    > gateway.


    He can do all sorts of things if he has your MAC address and IP address.

    Feeling safe is not enough to protect you. There are ships that have been sunk
    even though the crew felt safe (HMS Sheffield).

    Mark.

    --
    Mark Hobley,
    393 Quinton Road West,
    Quinton, BIRMINGHAM.
    B32 1QE.

  19. Re: Netgear RP614 leaking

    Pascal Hambourg wrote:

    > As I said, it keeps track of outgoing packets. Incoming packets matching
    > an outgoing packet are forwarded to the original sender.


    Ok. That makes sense. However, I am not sure whether that behaviour is always
    desireable. Not all UDP packets require a reply, and looking quickly at
    the UDP header layout, there are no flags to determine whether or not a reply
    is desirable. If the remote host sends a UDP datagram (reply) to a host
    on the network following receipt of a UDP datagram from the host on the
    network, presumeably the UDP reply will be forwared to the local station,
    regardless of whether or not this was expected.

    I am wondering whether this gives a remote host the possibility of
    connecting to an internal UDP service on a local machine, because the
    local machine send a UDP message to the remote host seconds earlier.

    Say for example, a local station behind the router runs two unrelated
    services, foo and bar.

    foo is an internal service that is used on the LAN that sends out
    password information on receipt of a UDP datagram on port 10000.

    bar is an unrelated service that sends a UDP datagram to remotehost,
    for example a time signal.

    Say remotehost has been configured to send a UDP password request to
    port 10000, on receipt of a time signal.

    As service bar sends out the time signal, the router notes that remotehost has
    recently active UDP activity and can reply to the local station. The
    remotehost sends out a UDP password request to port 10000. The router
    receives this and forwards the password request to the local station (or
    does it know better?) The local station receives this request and sends
    the password to remotehost as requested.

    Could this happen or are there additional steps that the router takes to
    prevent this from happening?

    Mark.

    --
    Mark Hobley,
    393 Quinton Road West,
    Quinton, BIRMINGHAM.
    B32 1QE.

  20. Re: Netgear RP614 leaking

    Mark Hobley a écrit :
    > Pascal Hambourg wrote:
    >
    >>2) A "neighbour" sharing the same link could create a route to your
    >>station IP address using your external MAC or public IP address as
    >>gateway.

    >
    > He can do all sorts of things if he has your MAC address and IP address.


    Your *external* address. He won't be able to do anything with an
    internal MAC address.

    > Feeling safe is not enough to protect you.


    Obfuscation is not either. Security through obscurity does not work.

+ Reply to Thread
Page 2 of 3 FirstFirst 1 2 3 LastLast