Tim Broberg | 4 Aug 2009 03:26
Favicon

IPv6 address fuzzing?

Is it practical to fuzz IPv6 addresses?
 
When I try this, I get "socket.gaierror: [Errno -2] Name or service not known" at scapy/route6.py:192.
 
    def route(self, dst, dev=None):
        """
# ...
        try:
            inet_pton(socket.AF_INET6, dst)
        except socket.error:
            dst = socket.getaddrinfo(savedst, None, socket.AF_INET6)[0][-1][0]
            # TODO : Check if name resolution went well
 
It tries to do inet_pton on the address, but the address is a raw hex string instead of an ASCII IPv6 addr like it is when I stuff the addr in by hand.
 
Is fuzzing just broken for IPv6 addrs?
 
Is fuzzing just a bad idea for IPv6 addrs?
 
TIA,
    - Tim.

The information and any attached documents contained in this message
may be confidential and/or legally privileged. The message is
intended solely for the addressee(s). If you are not the intended
recipient, you are hereby notified that any use, dissemination, or
reproduction is strictly prohibited and may be unlawful. If you are
not the intended recipient, please contact the sender immediately by
return e-mail and destroy all copies of the original message.
James Harr | 4 Aug 2009 07:09
Picon

Re: IPv6 address fuzzing?

The entire IPv4 space is 32 bits, with subnets generally 8 bits in size.


I'm not entirely up to speed on how IPv6 net blocks will be handed out, but IPv6 zero-config (or whatever it's called this week) gives you a 64 bit subnet. If you can hit a million machines a second, it'll take you around 557 millennia to hit every host on that network. Fuzzing a network would probably produce similar numbers.

Part of that address is based on the machines MAC addresses. If you knew someone uses a specific vendor, you could go look up their OUI and just scan those macs. Dell, for example, has four 24 bit OUIs, which leaves you at a more feasible number of 67 million. When we get a batch of new computers/servers in at work, a lot of times the MACs are serial (or close to it); If you wanted to get real fancy, you could search around the MAC addresses that you found via fuzzing.

In all honesty, you might have better luck dictionary attacking DNS, passively listening, or some completely different approach.

... and no, I don't have an answer to your scapy question. Just thought the security implications of IPv6 were interesting.


On Mon, Aug 3, 2009 at 8:26 PM, Tim Broberg <Tim.Broberg <at> exar.com> wrote:
Is it practical to fuzz IPv6 addresses?
 
When I try this, I get "socket.gaierror: [Errno -2] Name or service not known" at scapy/route6.py:192.
 
    def route(self, dst, dev=None):
        """
# ...
        try:
            inet_pton(socket.AF_INET6, dst)
        except socket.error:
            dst = socket.getaddrinfo(savedst, None, socket.AF_INET6)[0][-1][0]
            # TODO : Check if name resolution went well
 
It tries to do inet_pton on the address, but the address is a raw hex string instead of an ASCII IPv6 addr like it is when I stuff the addr in by hand.
 
Is fuzzing just broken for IPv6 addrs?
 
Is fuzzing just a bad idea for IPv6 addrs?
 
TIA,
    - Tim.

The information and any attached documents contained in this message
may be confidential and/or legally privileged. The message is
intended solely for the addressee(s). If you are not the intended
recipient, you are hereby notified that any use, dissemination, or
reproduction is strictly prohibited and may be unlawful. If you are
not the intended recipient, please contact the sender immediately by
return e-mail and destroy all copies of the original message.

Picon
Favicon

Re: IPv6 address fuzzing?

> Is it practical to fuzz IPv6 addresses?
>
> When I try this, I get "socket.gaierror: [Errno -2] Name or service  
> not known" at scapy/route6.py:192.

What did you type ?

Guillaume

--
Guillaume Valadon / ギョーム バラドン
guedou <at> hongo.wide.ad.jp

---------------------------------------------------------------------
To unsubscribe, send a mail to scapy.ml-unsubscribe <at> secdev.org

Tim Broberg | 4 Aug 2009 18:49
Favicon

RE: IPv6 address fuzzing?

What I typed is below, with similar actions for IPv4 and IPv6.

What I'm doing is poking at an API, so I don't much care what the addresses really are.

I'm just surprised to see fuzz generate a machine value and send it to pton, which appears to want an internal
value passed in.

You're probably right, James, that there isn't much sense fuzzing these values out to the network, even if
limited to 64-bit scope.

Sounds like this is a "Why would you do that?!" condition.

    - Tim.

>>> class MyIPv4Packet(Packet):
...     name = "MyIPv4Packet"
...     fields_desc = [
...         SourceIPField("src","dst"),
...         IPField("dst", "127.0.0.1")
...         ]
...
>>> class MyIPv6Packet(Packet):
...     name = "MyIPv6Packet"
...     fields_desc = [
...         SourceIP6Field("src", "dst"), # dst is for src  <at>  selection
...         IP6Field("dst", "::1")
...         ]
...
>>> print "Gen Packets"
Gen Packets
>>> p4=MyIPv4Packet()
>>> print "Show Packets"
Show Packets
>>> p4.show()
###[ MyIPv4Packet ]###
  src= 127.0.0.1
  dst= 127.0.0.1
>>> print "Build Packets"
Build Packets
>>> p4.show2()
###[ MyIPv4Packet ]###
  src= 0.0.0.0
  dst= 127.0.0.1
>>> print "Fuzz Packets"
Fuzz Packets
>>> q4=fuzz(p4)
>>> print "Show Fuzzed Packets"
Show Fuzzed Packets
>>> q4.show()
###[ MyIPv4Packet ]###
  src= 10.0.2.15
  dst= 242.100.68.35
>>> print "Build Fuzzed Packets"
Build Fuzzed Packets
>>> q4.show()
###[ MyIPv4Packet ]###
  src= 10.0.2.15
  dst= 68.78.121.178
>>>
>>> print "Gen Packets"
Gen Packets
>>> p6=MyIPv6Packet()
>>> print "Show Packets"
Show Packets
>>> p6.show()
###[ MyIPv6Packet ]###
  src= ::1
  dst= ::1
>>> print "Build Packets"
Build Packets
>>> p6.show2()
###[ MyIPv6Packet ]###
  src= ::1
  dst= ::1
>>> print "Fuzz Packets"
Fuzz Packets
>>> q6=fuzz(p6)
>>> print "Show Fuzzed Packets"
Show Fuzzed Packets
>>> q6.show()
###[ MyIPv6Packet ]###
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.6/site-packages/scapy/packet.py", line 794, in show
    vcol(f.i2repr(self,fvalue)))
  File "/usr/lib/python2.6/site-packages/scapy/layers/inet6.py", line 200, in i2repr
    return self.i2h(pkt,x)
  File "/usr/lib/python2.6/site-packages/scapy/layers/inet6.py", line 231, in i2h
    iff,x,nh = conf.route6.route(dst)
  File "/usr/lib/python2.6/site-packages/scapy/route6.py", line 192, in route
    dst = socket.getaddrinfo(savedst, None, socket.AF_INET6)[0][-1][0]
socket.gaierror: [Errno -2] Name or service not known
>>> print "Build Fuzzed Packets"
Build Fuzzed Packets
>>> q6.show()
###[ MyIPv6Packet ]###
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.6/site-packages/scapy/packet.py", line 794, in show
    vcol(f.i2repr(self,fvalue)))
  File "/usr/lib/python2.6/site-packages/scapy/layers/inet6.py", line 200, in i2repr
    return self.i2h(pkt,x)
  File "/usr/lib/python2.6/site-packages/scapy/layers/inet6.py", line 231, in i2h
    iff,x,nh = conf.route6.route(dst)
  File "/usr/lib/python2.6/site-packages/scapy/route6.py", line 192, in route
    dst = socket.getaddrinfo(savedst, None, socket.AF_INET6)[0][-1][0]
socket.gaierror: [Errno -2] Name or service not known
>>>

________________________________________
From: Guillaume Valadon / ギョーム バラドン [guedou <at> hongo.wide.ad.jp]
Sent: Tuesday, August 04, 2009 1:43 AM
To: scapy.ml <at> secdev.org
Subject: Re: [scapy.ml] IPv6 address fuzzing?

> Is it practical to fuzz IPv6 addresses?
>
> When I try this, I get "socket.gaierror: [Errno -2] Name or service
> not known" at scapy/route6.py:192.

What did you type ?

Guillaume

--
Guillaume Valadon / ギョーム バラドン
guedou <at> hongo.wide.ad.jp

---------------------------------------------------------------------
To unsubscribe, send a mail to scapy.ml-unsubscribe <at> secdev.org

The information and any attached documents contained in this message
may be confidential and/or legally privileged.  The message is
intended solely for the addressee(s).  If you are not the intended
recipient, you are hereby notified that any use, dissemination, or
reproduction is strictly prohibited and may be unlawful.  If you are
not the intended recipient, please contact the sender immediately by
return e-mail and destroy all copies of the original message.

---------------------------------------------------------------------
To unsubscribe, send a mail to scapy.ml-unsubscribe <at> secdev.org

Pedro Abranches | 4 Aug 2009 22:15
Picon

TCP ack and sequence number long ints

Hi everyone.

I'm having some problems in the ack and seq fields of a TCP packet in scapy.

###[ TCP ]###
        sport= www
        dport= 58227
        seq= 4094236693L
        ack= 2946596713L

Why do seq and ack are long ints? Their real value, in this case, is 1
and 5 (seen with wireshark). Why does this happen? Is it some bug?

---------------------------------------------------------------------
To unsubscribe, send a mail to scapy.ml-unsubscribe <at> secdev.org

Francesco Piccinno | 4 Aug 2009 22:29
Picon
Gravatar

Re: TCP ack and sequence number long ints

Wireshark shows relative ack and sequence numbers instead of absolute
ones as default. You could disable this feature in Preferences -> TCP
by disabling 'Analyze TCP sequence numbers' and 'Relative sequence
numbers and window scaling' options.

--
Best regards,
Francesco Piccinno

2009/8/4 Pedro Abranches <pedrof.abranches <at> gmail.com>:
> Hi everyone.
>
> I'm having some problems in the ack and seq fields of a TCP packet in scapy.
>
> ###[ TCP ]###
>        sport= www
>        dport= 58227
>        seq= 4094236693L
>        ack= 2946596713L
>
> Why do seq and ack are long ints? Their real value, in this case, is 1
> and 5 (seen with wireshark). Why does this happen? Is it some bug?
>
> ---------------------------------------------------------------------
> To unsubscribe, send a mail to scapy.ml-unsubscribe <at> secdev.org
>
>

---------------------------------------------------------------------
To unsubscribe, send a mail to scapy.ml-unsubscribe <at> secdev.org

Jochen Bartl | 4 Aug 2009 22:33
Picon
Gravatar

Re: TCP ack and sequence number long ints

Hi Pedro,

this isn't a bug. The numbers which are displayed by Scapy are correct.
Wireshark displays relative sequence numbers by default. You can disable
relative sequence numbers in Wireshark's preferences:

Preferences -> Protocols -> TCP -> Relative sequence numbers and window
scaling

best regards,

Jochen

On Tue, 2009-08-04 at 21:15 +0100, Pedro Abranches wrote:
> Hi everyone.
> 
> I'm having some problems in the ack and seq fields of a TCP packet in scapy.
> 
> ###[ TCP ]###
>         sport= www
>         dport= 58227
>         seq= 4094236693L
>         ack= 2946596713L
> 
> Why do seq and ack are long ints? Their real value, in this case, is 1
> and 5 (seen with wireshark). Why does this happen? Is it some bug?
> 
> ---------------------------------------------------------------------
> To unsubscribe, send a mail to scapy.ml-unsubscribe <at> secdev.org
> 
Pedro Abranches | 4 Aug 2009 23:37
Picon

Re: TCP ack and sequence number long ints

Thanks for the quick answers.
By the way, while I'm studying the TCP protocol deeper, I'm writing a
library in python that can reassemble and analyze TCP connections on
the network. I'm using scapy with it.
Do you known any other python library which does the same?

Thanks,
Pedro Abranches

2009/8/4 Jochen Bartl <jochen.bartl <at> gmail.com>:
> Hi Pedro,
>
> this isn't a bug. The numbers which are displayed by Scapy are correct.
> Wireshark displays relative sequence numbers by default. You can disable
> relative sequence numbers in Wireshark's preferences:
>
> Preferences -> Protocols -> TCP -> Relative sequence numbers and window
> scaling
>
> best regards,
>
> Jochen
>
>
> On Tue, 2009-08-04 at 21:15 +0100, Pedro Abranches wrote:
>> Hi everyone.
>>
>> I'm having some problems in the ack and seq fields of a TCP packet in scapy.
>>
>> ###[ TCP ]###
>>         sport= www
>>         dport= 58227
>>         seq= 4094236693L
>>         ack= 2946596713L
>>
>> Why do seq and ack are long ints? Their real value, in this case, is 1
>> and 5 (seen with wireshark). Why does this happen? Is it some bug?
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, send a mail to scapy.ml-unsubscribe <at> secdev.org
>>
>

---------------------------------------------------------------------
To unsubscribe, send a mail to scapy.ml-unsubscribe <at> secdev.org

Dirk Loss | 5 Aug 2009 07:10
Picon
Favicon

Re: TCP ack and sequence number long ints

Pedro Abranches wrote:
> By the way, while I'm studying the TCP protocol deeper, I'm writing a
> library in python that can reassemble and analyze TCP connections on
> the network. I'm using scapy with it.
> Do you known any other python library which does the same?

"pynids is a python wrapper for libnids, a Network Intrusion Detection 
System library offering sniffing, IP defragmentation, TCP stream 
reassembly and TCP port scan detection."

http://pilcrow.madison.wi.us/pynids/

But its last release was on 31 Jan 2005 so it probably won't work with 
recent libnids versions.

Pynids is used for example by flowgrep: 
http://www.monkey.org/~jose/software/flowgrep/

Regards
Dirk

---------------------------------------------------------------------
To unsubscribe, send a mail to scapy.ml-unsubscribe <at> secdev.org

Pedro Abranches | 5 Aug 2009 16:47
Picon

Re: TCP ack and sequence number long ints

Thanks a lot Dirk. That was really what I was looking for. I'll test
it right now with some older libnids version.

Pedro Abranches

2009/8/5 Dirk Loss <lists <at> dirk-loss.de>:
> Pedro Abranches wrote:
>>
>> By the way, while I'm studying the TCP protocol deeper, I'm writing a
>> library in python that can reassemble and analyze TCP connections on
>> the network. I'm using scapy with it.
>> Do you known any other python library which does the same?
>
> "pynids is a python wrapper for libnids, a Network Intrusion Detection
> System library offering sniffing, IP defragmentation, TCP stream reassembly
> and TCP port scan detection."
>
> http://pilcrow.madison.wi.us/pynids/
>
> But its last release was on 31 Jan 2005 so it probably won't work with
> recent libnids versions.
>
> Pynids is used for example by flowgrep:
> http://www.monkey.org/~jose/software/flowgrep/
>
> Regards
> Dirk
>
> ---------------------------------------------------------------------
> To unsubscribe, send a mail to scapy.ml-unsubscribe <at> secdev.org
>
>

---------------------------------------------------------------------
To unsubscribe, send a mail to scapy.ml-unsubscribe <at> secdev.org


Gmane