Simple script: random (garbage) fuzzer

[Ron (list)]

Hey,

Somebody requested a NSE script to fuzz with random garbage on all
ports. It isn't *terribly* useful, but it could be a good way to exhaust
bandwidth/test for really bad services.

I may do more fuzzer scripts later, but I've attached this one.

I realize this doesn't do a whole heck of a lot, but anybody mind if I
check this in?

Thanks
Ron

--
Ron Bowes
http://www.skullsecurity.org/

description = [[
A very simple fuzzer -- this will send garbage (random) junk on every open port. Runs until the server closes the connection, and never receives any data.
]]
---
--@usage
-- nmap --script fuzz-garbage <host>
--
--@output
-- n/a
--
-- @args chunksize The size of the chunks to send (default: 1024).
-- @args stopafter Stop after sending this many bytes. This will be rounded up to the next
--       chunksize.
-----------------------------------------------------------------------

author = "Ron Bowes"
copyright = "Ron Bowes"
license = "Same as Nmap--See http://nmap.org/book/man-legal.html"
categories = {"intrusive","dos"}

-- Set the runlevel to >2 so this runs last (so if it DOES crash something, it doesn't
-- till other scans have had a chance to run)
runlevel = 2

portrule = function(host)
        return true
end

function get_data(size)
        local data = ""

        for i=1, size, 1 do
                data = data .. string.char(math.random(0xFF))
        end

        return data
end

function go(host, port)
        local status, err
        local chunksize = nmap.registry.args.chunksize or 1024
        local stopafter = tonumber(nmap.registry.args.stopafter)
        local socket = nmap.new_socket()
        local amt = 0

        -- Set the random seed
        math.randomseed(os.time())

        status, err = socket:connect(host.ip, port.number)
        if(not(status)) then
                return false, "Couldn't connect: " .. err
        end

        while true do
                local data = get_data(chunksize)
                status, err = socket:send(data)
                if(not(status)) then
                        return false, string.format("Finished sending data: %s (%d bytes already sent)", err, amt)
                end
                amt = amt + chunksize

                if(stopafter and amt >= stopafter) then
                        return true, string.format("Finished sending %d bytes\n", stopafter)
                end
        end

        return true, "Working!"
end

action = function(host, port)
        local status, result = go(host, port)

        if(not(status)) then
                if(nmap.debugging() > 0) then
                        return "ERROR: "  .. result
                end
        else
                return result
        end
end


_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/

[Fyodor]

On Fri, Nov 06, 2009 at 10:13:46AM -0500, Ron wrote:
> Hey,
>
> Somebody requested a NSE script to fuzz with random garbage on all
> ports. It isn't *terribly* useful, but it could be a good way to exhaust
> bandwidth/test for really bad services.

Nice.  Did they request it on a public forum somewhere that you can
link to?  It would be interesting to know more about the use case they
have in mind.

Maybe it should include a stopafter limit by default?  That way it
doesn't go forever for people who acidentally specify it (perhaps
among other scripts) without specifying the stopafter arg.

Also, you might want to make this output line more clear:
return false, string.format("Finished sending data: %s (%d bytes already sent)", err, amt)

You might want to note that it failed to send more data and thus the
service may have crashed.  Otherwise it looks pretty similar to the
successful finish case:

return false, string.format("Finished sending data: %s (%d bytes already sent)", err, amt)

> I realize this doesn't do a whole heck of a lot, but anybody mind if I
> check this in?

I'm on the fence on this one, but I'm not opposed to checking it in
(as long as it is changed to complete at some point by default).  I
suppose one can always do this sort of thing with the likes of "cat
/dev/urandom | ncat --send-only target port", but the NSE script lets
Nmap find the open ports for it, and also handles many ports at once.

Cheers,
-F
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/

[Ron (list)]

Fyodor wrote:

> On Fri, Nov 06, 2009 at 10:13:46AM -0500, Ron wrote:
>> Hey,
>>
>> Somebody requested a NSE script to fuzz with random garbage on all
>> ports. It isn't *terribly* useful, but it could be a good way to exhaust
>> bandwidth/test for really bad services.
>
> Nice.  Did they request it on a public forum somewhere that you can
> link to?  It would be interesting to know more about the use case they
> have in mind.

No, I'm doing a class right now and the instructor mentioned it. His
case was primarily finding low-hanging fruit services on certain systems.

It might be need to write fuzzers for specific protocols, too. HTTP
fuzzer, SMB fuzzer, etc etc. That's something I hadn't really thought of
using NSE for before.

> Maybe it should include a stopafter limit by default?  That way it
> doesn't go forever for people who acidentally specify it (perhaps
> among other scripts) without specifying the stopafter arg.
Sure, any suggestions on how long it should go for?

Most services do terminate the connection pretty fast when they receive
garbage, so it actually doesn't run forever. But that obviously isn't a
safe assumption.

> Also, you might want to make this output line more clear:
> return false, string.format("Finished sending data: %s (%d bytes already sent)", err, amt)
>
> You might want to note that it failed to send more data and thus the
> service may have crashed.  Otherwise it looks pretty similar to the
> successful finish case:
>
> return false, string.format("Finished sending data: %s (%d bytes already sent)", err, amt)
I'll revisit the language.

>
>> I realize this doesn't do a whole heck of a lot, but anybody mind if I
>> check this in?
>
> I'm on the fence on this one, but I'm not opposed to checking it in
> (as long as it is changed to complete at some point by default).  I
> suppose one can always do this sort of thing with the likes of "cat
> /dev/urandom | ncat --send-only target port", but the NSE script lets
> Nmap find the open ports for it, and also handles many ports at once.
Yeah, I agree.

>
> Cheers,
> -F

Ron
--
Ron Bowes
http://www.skullsecurity.org/
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/

[Jon Kibler-2]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Fyodor wrote:

> On Fri, Nov 06, 2009 at 10:13:46AM -0500, Ron wrote:
>> Hey,
>>
>> Somebody requested a NSE script to fuzz with random garbage on all
>> ports. It isn't *terribly* useful, but it could be a good way to exhaust
>> bandwidth/test for really bad services.
>
> Nice.  Did they request it on a public forum somewhere that you can
> link to?  It would be interesting to know more about the use case they
> have in mind.
>

Re: Use case for this script?

I have not had a chance to look at this NSE script. However, random garbage
generators are a VERY useful testing tool, especially against embedded systems
(printers, VoIP phones, environmental sensors, etc.) and real-time systems
(SCADA, PLCs, DCS, security, HVAC, etc.). They very rapidly identify brittle IP
stacks and how well systems handle unexpected traffic.

I regularly use custom protocol fuzzers, and such tools as ISIC, SING, nemesis,
fragrouter, etc., to generate random packets to test the stability of systems to
unexpected traffic. All serve a very useful purpose when testing embedded or
real-time systems, which tend to be less network-stable than are traditional
computers.

That said, nmap itself can be a dangerous tools against embedded systems. When
doing a vulnerability assessment or pen test, one of the stipulations in my
contract is that the customer must identify every non-traditional computer on
their network (including printers), unless they specifically want them included
in the test. If they want them included, they must agree to assume all liability
for damages that may result from these systems being tested. I have had a simple
nmap scan of a network cause security systems to crash and burn (actually have
to replace boards!) to the point that they lock people in rooms, and the
maglocks had to be drilled off the doors to get the people out of the room. I
have had nmap cause HVAC systems to either shut down, or turn on full heat or
A/C, because the scan blew the control board. I have also had nmap crash other
"stuff" that I cannot talk about.

The ability of a system or device to handle random garbage on the network is a
critical part of any security testing. I would think this script may be able to
serve in that capacity. I will have to take a look at it when I get a chance.

Jon Kibler
- --
Jon R. Kibler
Chief Technical Officer
Advanced Systems Engineering Technology, Inc.
Charleston, SC  USA
o: 843-849-8214
c: 843-813-2924
s: 843-564-4224
s: JonRKibler
e: Jon.Kibler@...
e: Jon.R.Kibler@...
http://www.linkedin.com/in/jonrkibler

My PGP Fingerprint is:
BAA2 1F2C 5543 5D25 4636 A392 515C 5045 CF39 4253


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkr1tywACgkQUVxQRc85QlNFhACfaIzUfxi9odhcTgqHrOsukF7+
pocAnRTFBPtYZTDJtZuoOmGCv36tHlOA
=hSl+
-----END PGP SIGNATURE-----




==================================================
Filtered by: TRUSTEM.COM's Email Filtering Service
http://www.trustem.com/
No Spam. No Viruses. Just Good Clean Email.


_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/

[Fyodor]

On Sat, Nov 07, 2009 at 07:23:43AM -0500, Ron wrote:
> Fyodor wrote:
> > On Fri, Nov 06, 2009 at 10:13:46AM -0500, Ron wrote:
>
> > Maybe it should include a stopafter limit by default?  That way it
> > doesn't go forever for people who acidentally specify it (perhaps
> > among other scripts) without specifying the stopafter arg.
> Sure, any suggestions on how long it should go for?

Maybe 1MB per service?

> > Also, you might want to make this output line more clear:
> > return false, string.format("Finished sending data: %s (%d bytes already sent)", err, amt)
> >
> > You might want to note that it failed to send more data and thus the
> > service may have crashed.  Otherwise it looks pretty similar to the
> > successful finish case:
> >
> > return false, string.format("Finished sending data: %s (%d bytes already sent)", err, amt)
> I'll revisit the language.

You made a good point that most services will close the connection
quickly when they receive garbage, so I suppose we don't need to
really sound an alarm.  But it would be nice to note that the remote
host closed the connections and maybe you could put the number of
bytes sent and received before it closed.

A neat option (probably non-default) might be to connect back of the
remote side closes the connection.  That way you can report if the
service has completely crashed.

Cheers,
-F
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/