The Practical Examination of Your System (Network Vulnerability Assessments)

Network vulnerability assessment is a hands-on approach in ascertaining your system's obvious vulnerabilities and their locations. There are many risks that are associated with these types of audits that go largely ignored by senior managers.

Experience Note An auditor was examining the business' network software development process for compliance to the company's policy and procedures. She discovered the programmers and engineers were not observing any of the policy requirements and were basically approaching their development phases in a haphazard fashion. She detailed her findings in a preliminary report to senior managers who told her that they had evolved past the SDLC and other quality methods. Instead, they were writing their code, installing it, and using the network vulnerability assessment as a quality control to determine any weaknesses existing in their software. Her audit report findings were lengthy and specific.

In conducting network and other types of practical vulnerability assessments, it is paramount that auditors adopt a holistic view of auditing. Auditing is the process by which prohibited, abusive, and irregular activities are found and reported. If a concerted auditing effort is adopted, the entire system consisting of the three pillars of human resources, data and physical facilities will be measured as part of risk management and operational efficiency.

Vulnerability assessments only measure those vulnerabilities that are within the scope of the rules of engagement, the knowledge of the auditors, and those system vulnerabilities that are present at the time of the assessment. It should be made clear that network vulnerability assessments must be considered as part of the whole audit picture. They are not a substitute for poor systems design and management.

Network vulnerability assessments are the part of the audit program whose purpose is the practical identification of system vulnerabilities. If vulnerabilities are found, and they will be found, they will be reported as findings, accompanied by recommendations in the audit report. It is a fair statement that you cannot repair system weaknesses, unless you locate them first. If during a comprehensive audit, senior managers fail to locate and repair system vulnerabilities, it is a safe bet that attackers inside and outside the organization will find and exploit them. The general goals and objectives of system vulnerability assessments are as follows:

  • Measure levels of system risks.

  • Ascertain practical compliance with organization's policies and procedures. (This usually involves a high-degree of employee and senior manager embarrassment.)

  • System vulnerability assessments comprise an important part of the comprehensive auditing effort and clearly demonstrate professional due diligence.

    Audit team members should be carefully selected for their experience, people skills, communications skills, good judgment, system knowledge, and knowledge of software and intrusion and attacker tactics. It is recommended they have a good knowledge of programming in languages such as C, C++, Java, and PERL. Programming skills and network knowledge enable auditors to review open source tools, fix or modify them, and write their own programs, if necessary. It is worth remembering that running automated tools without an understanding of the underlying protocols and issues is dangerous and generally will not provide sufficient insight when documenting findings in the audit report. Skills such as persuasive sales are a valuable commodity if the audit team is going to engage in social engineering. Often the question is asked if this is "white-hat," "black-hat," or "gray-hat" system attacking.

    Experience Note Personally, the author thinks the "hat" business is a bit of nonsense. Some organizations are caught up in the idea of hiring individuals of questionable character, but who have a great deal of skill. Many are convicted felons. Think of this example, "Would you hire a professional thief to make a security survey of your business?" Prudent business managers should engage professionals of known abilities with impeccable references, not soon-to-be indicted attackers.

    Questions arise whether organizations should outsource system vulnerability assessments or develop the skills internally. Correct answers are not easily decided as there are advantages and disadvantages to both sides. There is some degree of risk in outsourcing vulnerability assessments unless a significant amount of research is done.

    Experience Note There are many outside "system security consultants" that are reformed attackers. Some have even spent time in prison for their criminal behavior, while others have been defendants in lawsuits centered in their unlawful behavior.

    So before contracting outside vulnerability auditors, it is prudent to discuss their backgrounds, experience, bonding, the length of time they have been in business, and references. Demand they provide a long list of satisfied clients and a few that were not so satisfied. Contracts should be carefully crafted enumerating liabilities and responsibilities.

    It is strongly recommended that several lawyers, having experience with services of this nature, review the details of the contract before being finalized.

    It is the practice of most consultants to spend an inordinate amount of time keeping skills current to explore and exploit system weaknesses. For some, their skills' improvement and bragging rights are something that borders on obsession. On their own time, they explore system weaknesses to the exclusion of other pursuits. Many consultants can tell you about successfully gaining root access to systems that were considered impregnable by its owners. Regardless, if the decision is made to use contractors, your sensitive assets are subject to capture by the outsiders. You are giving them the key to the business' crown jewels.

    Experience Note It is quite likely that today's system audit consultant will not be employed by the firm for more than a short time. She knows your system's vulnerabilities when she decides to exploit them.

    If the organization decides to develop inside talents, there are many suitable training courses available that can provide the skills necessary to perform a respectable system vulnerability assessment. Training of this nature is valuable and can be used as part of an employee development program. It is important to note that systems auditing skills are a serious commitment in that they require constant upgrading and expansion as new technologies emerge and new weaknesses are announced.
  • Specialized Auditing Matters - UNIX Shadow Password File

    On a UNIX/Linux system without a shadow password file installed, user password information is stored in the /etc/passwd file. Although popular literature will state passwords are encrypted, technically they are actually encoded rather than encrypted. The algorithm used to encode the password is a one-way hash function, ensuring that the encoded password cannot be feasibly decoded. Essentially, this means the algorithm encodes the password in one direction, but makes it mathematically infeasible to reverse the process. When a UNIX user uses an authorized password, it is encoded in a randomly generated value sometimes referenced as the "salt."

    This means the password could be stored in 4096 different combinations. When a user logs into the system and provides a password, the salt is first retrieved from the encoded password. The salt value supplied password is encoded with the retrieved salt value, and then compared with the encoded password. If the two values match, the user is authenticated and permitted to access the system.

    Password cracking software programmers know all this and simply encrypt a dictionary of words using all possible 4096 salt values and compare them to the already encoded passwords. They will compare the encoded passwords in the /etc/passwd file with the cracker's database. Once they find a match, they have the password for the account. This is known as a dictionary attack.

    Think of it in terms of an eight-character password encoded to 4096 times 13 character strings. A dictionary of about 400,000 words, names, common passwords, and simple variations easily fit in a hard drive of 5GB. The program needs only to sort and check for matches.

    Along with passwords, the /etc/passwd file contains user IDs and group IDs that are used in the systems programs. In order for UNIX to function, the /etc/passwd file must be read by everyone. If you were to change the file so no one can read it, the first command of ls -l will display all the user and group IDs.

    Having a shadow password file solves the problem by relocating the passwords to another file, /etc/shadow, with access privileges set to root. By moving the passwords to the /etc/shadow file, administrators are effectively keeping attackers from having access to the encoded passwords with which to perform a dictionary attack.

    Format of the /etc/passwd File

    A nonshadowed /etc/passwd file has the following format:

    user name:passwd:UID:GID:full_name:directory:shell

    user name = the user (login) name

    passwd = the encoded password

    UID = numerical user ID

    GID = numerical default group ID

    full_name = the user's full name is held here in this field that can also store information other than just the full name

    directory = user's home directory (full path name)

    shell = user's login shell (full path name)

    For example:

    user name: Tbge08pfz4wuk:503:100:Full Name:/home/user

    where Tb is the salt and ge08pfz4wuk is the encoded password. The encoded salt/password could just as easily have been kbeMVnZM0oL7I and the two are exactly the same password. As was stated earlier, there are 4096 possible encoding combinations for the same password.

    Once the shadow password file is installed, the /etc/passwd file would instead contain the entry:

    user name:x:503:100:Full Name:/home/user name: /bin/sh
    The x in the second field in this case is a place-holder. The format of the /etc/passwd file did not change. It no longer contains the encoded password. This means that any program that reads the /etc/passwd file does not actually need to verify passwords and it will operate correctly. The passwords are now relocated to the shadow file /etc/shadow.

    Format of the Shadow File
    The /etc/shadow file contains the following information:

    user name:passwd:last:may:must:warn:expire:disable:reserved


    user name = the user name

    passwd = the encoded password

    last = days since Jan. 1, 1970 that password was last changed

    may = days before password may be changed

    must = days after which password must be changed

    warn = days before password is to expire that user is warned

    expire = days after password expires that account is disabled

    disable = days since Jan. 1, 1970 that account is disabled

    reserved = a reserved field

    Auditors must review the implementation of shadow password files in UNIX/Linux implementations. It is important to note that this UNIX audit guide is intended only to spur auditors to look at the potential areas that should be reviewed because there are many versions of UNIX as well as a great number of applications supported by it. Here are three specialized Web sites that may provide some guidance on auditing UNIX password files:

    Popular Posts