| I l@ve RuBoard |
Our internal penetration testing usually consists of three scenarios: the evil consultant, the disgruntled employee, and the dishonest cleaning staff. These persons all have access and opportunity for unauthorized activity. Hackers have been known to dress up as cleaning staff or to actually obtain a job as a janitorial person to gain internal access and to open back doors for access later from the outside. Each scenario entails nearly the same procedures with a little variation. For the evil consultant scenario, we ask the system administrator to give us an account normally given to a consultant or vendor. Many times consultant accounts have been restricted in some way or placed into a group with fewer access rights than a normal employee user account. However, even with these restricted accounts consultants have access to many resources and information that could enable them to gain unauthorized access to critical data. For the disgruntled employee scenario, we just obtain a normal user ID and see what assets we can access or abuse. For the cleaning staff scenario, we plug a laptop into the network and see where it will take us.
All internal testing requires coordination with company personnel to make sure access to the facilities and proper user IDs (for each scenario) are established. Also, close coordination helps limit your liability. When you conduct testing internally, you have more opportunity to unintentionally damage the network. Internal coordinators should be consulted before performing any testing that could harm the network or critical resources. Also, the internal coordinators can act as witnesses to defend you against unwarranted accusations. Sometimes system administrators blame a system problem that arises during the time of the testing on the test, even if it is totally unrelated. By having a member of the company or department observing your activities, you can provide a reasonable alibi against these accusations.
For the evil consultant scenario, we set up in a conference room or separate workspace. Depending on company policy, we use either a company-owned workstation or our own laptops. (Some organizations do not allow outside laptops on the network or even onto the premises.) We sign on with the consultant account and move onto the next stages of the test. Then we load our tools, if possible, and start the discovery phase.
For the disgruntled employee, the situation is nearly the same. We usually use a corporate workstation and sign on as a normal employee. From there, we attempt to gain administrator access over the system. We then load our tools and move on from there. If we cannot gain administrator access over the local system, we continue with applicable test procedures.
The cleaning staff scenario usually requires us to be creative. We normally either use our laptops or take over a workstation during off hours when fewer company employees are on site. Hopefully we are able to find a live network jack outside of normal view. If the client uses DHCP we plug in to the network, obtain a DHCP address, and move on. If the client does not use DHCP, we have to find a valid IP address if we want to do anything more than sniff the network. First, we try to walk around and look for clues. Many times companies list IP addresses on computers, workstations, or other devices for troubleshooting purposes. If you find one of these addresses, you can do one of two things: either use an address one or two numbers higher or lower than the address and hope it works, or disconnect the device and use its address until you can find another. Once you have obtained the IP address you can perform a ping sweep to find an open, unused address and use that for the remainder of the testing.
You need to be careful when using static IP addresses. If you select one already in use, you may cause IP address conflicts and be discovered. Select your IP addresses wisely. As a system administrator, take note of the ways a casual observer could determine your internal IP addressing scheme and guard against it. Disable unused network jacks, look for IP conflicts, and do not openly display machine IP addresses.
| I l@ve RuBoard |