< Day Day Up > |
Imagine that you were asked by your neighbors to steal the bicycle of their child. The child does not know that you are going to attempt to steal it, but the parents want to judge how difficult it would be if someone were to try to steal it. You know that stealing is illegal, and you wonder if it is still wrong if the parents authorize you to do it. The parents ask you to do them this favor and tell them the results. Penetration testing is no different from this analogy. You are being asked to perform a task that would otherwise be illegal. Often, the employees of the company have no idea what you are up to, being unaware that the management has requested a penetration test to be done. Informing employees especially IT staff might lead to inaccurate results because they might attempt to harden their systems to prevent your access. Going back to the analogy, what if in the process of stealing the bicycle you discover that the back tire looks loose? If the tire comes undone, it could cause harm to the rider. You wonder if you should attempt to take the tire off to see if it is easily undone, even though the owners have not asked you to. In penetration testing, you might discover that a host appears susceptible to denial of service (DoS) attacks. A DoS attack is an attack that prevents a host from functioning in accordance with its intended purpose. Such attacks can have a severe impact on daily operations, preventing users from working or preventing customers from accessing the company website. Because of the severe impact of DoS attacks, they are not usually allowed in penetration testing. When they are, they are usually performed after hours when their impact would be minimal. It is unethical to perform a DoS attack on your target if the testing contract does not allow for such. Your contract should state, however, that you cannot guarantee against DoS during testing because the unexpected does happen. Sometimes scanning tools that would otherwise be harmless cause unexpected results. Have a disclaimer clause and communicate to your client that DoS attacks will not be willfully tested but that they might occur in the process of other tests. Note For example, the NMap tool, used to scan hosts for open ports, has been known to cause DoS attacks inadvertently on OpenBSD 2.7 systems that are running IPSec. When you run nmap with the sO option, you cause the OpenBSD system to crash with the following output: panic: m_copydata: null mbuf Stopped at _Debugger+0x4: leave _panic(.... m_copydata(... _ipsec_common_input(... _esp4_input(.... _ipv4_input(.... _ipintr(... Bad frame pointer: 0xe3b55e98 Port scans have also been known to cause DoS attacks on Efficient Networks Routers, pcAnywhere 9.0, and Windows 95 and 98 with Novell intraNetWare Client installed. If DoS attacks are not allowed in the test, put a disclaimer in your contract of service that states you will not willfully commit a DoS attack. However, make it clear to the client that DoS attacks might be caused inadvertently, as in the examples listed here. Your ethical responsibilities do not stop when the test is done, however. After the test is completed, you should perform due diligence to ensure the confidentiality of the test results. Some penetration testing firms have been known to circulate test results to other companies as samples of their work. These results contain detailed steps on how to break into an e-finance website for a particular financial institution and collect sensitive customer data. You can imagine the shock of the institution when it discovered these contents being distributed to its competitors! Therefore, as a penetration tester, you are under an ethical obligation to keep the details of the report confidential. Shred any hard copies of the report, and delete all soft copies using a wiping utility such as PGP or Axcrypt.
|
< Day Day Up > |