Results 1 to 8 of 8

Thread: Security issues with a port scanner

  1. #1
    Junior Member
    Join Date
    Oct 2003
    Posts
    2

    Security issues with a port scanner

    Hullo. I'm designing a port scanner for a basic info security class, and one of the assignment requirements is to list the security concerns of such a program--basically, what possible risks to security this port scanner might pose. The port scanner is meant to be used by an administrator to determine what vulnerabilities exist in the network (and the program takes in input by the user to specify what exactly a vulnerability is).

    As far as I can tell...the scanner should be designed in a way that a) it is accurate in its reporting of port statuses and vulnerabilities, b) the program requires installation by an administrator (so a malicious user can't use the scanner to detect vulnerabilities), c) the scanner completes its work in a reasonable amount of time without hogging resources, and d) the scanner doesn't open up any vulerabilities itself when it is executed.

    These seem kind of trivial and obvious...are there any other security issues I might be missing?

  2. #2
    Antionline's Security Dude instronics's Avatar
    Join Date
    Dec 2002
    Posts
    901
    Hello Dnguyen

    I'm designing a port scanner for a basic info security class, and one of the assignment requirements is to list the security concerns of such a program--
    I would say the concerns are:

    1 - It would provide information as to what services the target computer is offering.

    2 .- Depending on the capabilities of that scanner, information such as OS fingerprinting, firewall/network fingerprinting, and uptime can be gathered.

    3 - It would make aware that a target host is alive.

    4 - Depending on the scan types and/or methods, it could maybe even crash a host.

    5 - It could maybe even bypass a firewall, and use IDS evading techniques.

    6 -. Depending on who or what the target it, there might be legal issues behind the scan attempts.

    The port scanner is meant to be used by an administrator to determine what vulnerabilities exist in the network
    That is always a good idea to only let priveleged users have the option to install and use such a tool.
    Maybe even add an option to log in verbose anything that application might do, just incase someone obtains access to it afterall. That way you can afterwards determine who scanned what, using what methods.

    (and the program takes in input by the user to specify what exactly a vulnerability is)
    Im sorry, i dont follow that point concerning the input to "what a vulnerability" is.

    the scanner should be designed in a way that a) it is accurate in its reporting of port statuses and vulnerabilities,
    I dont think that you can get any other info other than seeing if a port is in "STATE - LISTEN".
    As for the vurnerability, i guess it would depend on what you specified on the "user input" you mentioned above.

    the scanner completes its work in a reasonable amount of time without hogging resources,
    If your on a nix system, you can control that point using 'nice' and 'renice', and by viewing it using 'top'. Dont make the code to big on this point, since the system can help you out there (if its on a *nix system that is).

    d) the scanner doesn't open up any vulerabilities itself when it is executed.
    I would say that this point CAN ONLY apply for known vurnabilities which dont react nicely to scan types. You would have to know "vurnerabilities to come" in order to prevent that, for so far unknown weaknesses.


    In general, a port scanner is not the basic idea to discover vurnerabilities. One thing you maybe could consider is..... to mark certain ports as a sort of risk... such as telnet, and normal ftp (since they are not encrypted). Ofcourse that is not a vurnerability, but if your a bit paranoid about security, then you would avoid using or recomending these sort of services.

    In addition, you could let that scanner get information from a database which would have to supply information about known weaknesses for several services, like the Open SSL that was released a few days ago, or unpatched systems, but thats taking it a bit far for a port scanner.

    Security issues also means... to limit the use of the scanner not only by the user itself, but also by what the scanner can do. The more options you give this scanner, the more dangerous it is.

    I hope i understood you and that i said something that might be of help.

    Good luck on your project.

    Cheers.
    Ubuntu-: Means in African : "Im too dumb to use Slackware"

  3. #3
    Banned
    Join Date
    May 2003
    Posts
    1,004
    I dont think that you can get any other info other than seeing if a port is in "STATE - LISTEN".
    closed/open/filtered

    If your on a nix system, you can control that point using 'nice' and 'renice', and by viewing it using 'top'. Dont make the code to big on this point, since the system can help you out there (if its on a *nix system that is).
    Basically all multiuser and real time operating systems have the ability to run tasks at varying priority levels or when cpu/memory/whatever usage is below X%.

    I would say that this point CAN ONLY apply for known vurnabilities which dont react nicely to scan types. You would have to know "vurnerabilities to come" in order to prevent that, for so far unknown weaknesses.
    You can use a safe structure to secure against future application level weaknesses.

    I understood the question differently than instronics and assumed that Dnguyen was actually asking what new risks will be introduced to the network along with the scanner.

    First off you would need some sort of organization between those users that would be doing the scanning and those users that manage the IDS/network logs. You have two primary choices and each comes with a cost:

    1. Somehow communicate/schedule internal scans so that all relevant parties are privy to the hows and whens. this will save a misunderstanding leading to an investigation over fishy logs. The cost here may be minimal to extensive depending on the size and structure of the system.
    2. Modify the scanner to evade the log/IDS perhaps by means of a signature or other such means. This may save the added communication/structure required, but could open a _very_ minor but _very_ real hole where an internal attacker could mimic the same method.

    You need to determine which of these aproaches runs the smallest cost on your system to make you choice.

    catch

  4. #4
    Antionline's Security Dude instronics's Avatar
    Join Date
    Dec 2002
    Posts
    901
    Thanks catch for your input. I guess i should have a coffee or 2 when i wakeup instead of posting straight away. I did forget the closed/open/filtered part. I also didnt know if/how windows can also set priorities the same way that a *nix can.

    /me hides in shame

    Cheers.
    Ubuntu-: Means in African : "Im too dumb to use Slackware"

  5. #5
    Junior Member
    Join Date
    Oct 2003
    Posts
    2
    Originally posted here by instronics

    Security issues also means... to limit the use of the scanner not only by the user itself, but also by what the scanner can do. The more options you give this scanner, the more dangerous it is.

    Yep, this is what I'm looking for...exactly what kind of options could I give the scanner that would introduce new security risks?

  6. #6
    Junior Member
    Join Date
    Nov 2001
    Posts
    3
    you could introduce a lot of potentially "risky" options.
    1) the ability to do "Half-open", FIN/ACK, RST, and other types of scanning methods not detectable by many Network IDS packages.
    2) optional banner grabbing for determining the service running on the port
    3) automated online searches for known vulnerabilities to these services
    4) automated scanning of targets
    5) scanning ranges of IPs
    6) packet fragmentation
    7) http proxy scanning
    8) ftp "proxy" scanning
    9) determining who owns a particular IP, then querying public databases for all domains and IP ranges owned by them

    the list goes on and on. Essentially, imagine combining nmap with nessus and amap, with a few modifications. You've now got yourself one hell of a sys-admin's nightmare. any kid on the street could fire it up and have it auto-download all the scripts needed for breaking into a particular system, as well as detailed logfiles of the scans.

    Aaron
    \"I don\'t care what you learned in C++ class today, you never let your friends touch your private parts.\"

  7. #7
    Senior Member
    Join Date
    Jan 2002
    Posts
    1,207
    Remember that an important consideration is to try not to accidentally do DoS on the box(es) you are scanning. Connecting too fast or hanging up too quickly can cause some services to stop responding or produce peculiar messages on the logs of the target boxes.

    In this respect, TCP SYN scans work much better than connect() scans because they don't complete the connection - hence they don't wake the application up.

    Most applications that use tcp are expecting the client to speak a particular protocol, not hang up immediately. This means that if the client does hang up straight away, they sometimes log this as an error.

    This may also apply to UDP scans, but there's no easy way of doing a UDP scan without alerting the application to it.

    Slarty

  8. #8
    Senior Member
    Join Date
    Mar 2003
    Posts
    245
    Excellent suggestions all-around.

    I also like to have options for contolling the speed of the scan, the send port number (traffic that looks like DNS_traffic gets through many firewalls), as well as the ability to randomize the host list to break up the scan a little.

    It is quite instructive to run scans like these against your_own_network to see what is being caught by IDS, security logging, and other facilities you have running that are supposed to alert you to this kind of activity.

    Best of luck on your scanner.

    -- spurious
    Get OpenSolaris http://www.opensolaris.org/

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •