Hacking For Dummies. Kevin Beaver

security tests. Make sure to perform tests that minimize disruption to business processes, information systems, and people. You want to avoid harmful situations such as miscommunicating the timing of tests and causing a denial of service (DoS) attack against a high-traffic e-commerce site in the middle of the day or performing password-cracking tests in the middle of the night that end up locking accounts and keeping people from logging in the next morning. It’s amazing what a 12-hour time difference (2 p.m. during major production versus 2 a.m. during a slower period) can make when testing your systems. Even having people in different time zones can create issues. Everyone on the project needs to agree on a detailed timeline before you begin. Having team members’ agreement puts everyone on the same page and sets correct expectations.

      

If required, notify your cloud service providers and hosting co-location providers of your testing. Many companies require such notification — and often approval— in advance before they allow testing. These companies have firewalls or intrusion prevention systems (IPSes) in place to detect malicious behavior. If your provider knows that you’re conducting tests, it may be less likely that they block your traffic, and you’ll get better results. They might even preapprove your source IP addresses, which is recommended.

Your testing timeline should include specific short-term dates and any specific milestones. You can enter your timeline in a simple spreadsheet program, a project-focused Gantt chart, or in a larger project plan. Often, when testing client networks, I will list these dates and time frames in my statement of work or in a simple email. That’s often all that’s needed.

      A timeline such as the following keeps things simple and provides a reference during testing:

Test Performed	Start Time	Projected End Time
Web application vulnerability scanning	June 1, 21:00 EST	June 2, 07:00
Network host vulnerability scanning	June 2, 10:00 EST	June 3, 02:00
Network host vulnerability analysis/exploitation	June 3, 08:00 EST	June 6, 17:00

      Running specific tests

      You may have been charged with performing some general vulnerability scans, or you may want to perform specific tests such as cracking passwords or trying to gain access to a web application. You may even be performing a social engineering test or assessing Windows systems on the network. However you test, you don’t necessarily need to reveal the specifics of the testing. Just high-level information should suffice. Even when your manager or client doesn’t require detailed records of your tests, document what you’re doing at a high level. Documenting your testing can eliminate potential miscommunication and keep you out of hot water. Also, you may need documentation as evidence if you uncover malfeasance.

      

Enabling logging on the systems you test along with the tools you use can provide evidence of what and when you test. Such logging may be overkill, but you could even record screen actions by using a tool such as TechSmith’s Camtasia Studio (www.techsmith.com/video-editor.html).

      Sometimes, you know the general tests that you perform, but if you use automated tools, it may be impossible to understand every test completely. This situation is especially true when the software you’re using receives real-time vulnerability updates and patches from the vendor each time you run it. The potential for frequent updates underscores the importance of reading the documentation and readme files that come with the tools you use.

      A CASE STUDY IN SELF-INFLICTED DENIAL OF SERVICE

      An updated program once bit me. I was performing a vulnerability scan on a client’s website — the same test that I’d performed the previous week. The client and I had scheduled the test date and time in advance. But I didn’t know that the software vendor had made some changes in its web form submission tests, and I accidentally flooded the client’s website, creating a DoS condition.

      Luckily, this condition occurred after business hours and didn’t affect the client’s operations. The client’s web application was coded to generate an email for every form submission, however, and there was no CAPTCHA on the form to limit successive submissions. The application developer and company’s president received 4,000 emails in their inboxes within about 10 minutes. Ouch!

      My experience is a perfect example of not knowing how my tool was configured by default and what it would do in that situation. I was lucky that the president of the company was tech-savvy and understood the situation. Be sure to have a contingency plan in case a situation like that occurs. Just as important, set people’s expectations that trouble can occur, even when you’ve taken all the right steps to ensure that everything’s in check.

One way to prevent this specific problem is to know, in advance, the email address such messages will originate from — for example, [email protected] for Qualys Web Application Scanner and [email protected] for Probely — and then block those emails at the server level.

      Conducting blind versus knowledge assessments

      Having some knowledge of the systems you’re testing is generally the best approach, but it’s not required. Having a basic understanding of the systems you hack can protect you and others. Obtaining this knowledge shouldn’t be difficult if you’re testing your own in-house systems. If you’re testing a client’s systems, you may have to dig a little deeper into how the systems work so that you’re familiar with them. Doing so has always been my practice, and I’ve had only a small number of clients ask for a full blind assessment because most people are scared of them. I’m not saying that blind assessments aren’t valuable, but the type of assessment you carry out depends on your needs.

The best approach is to plan on unlimited attacks, wherein any test is fair game, possibly even including DoS testing. (Just confirm that in advance!) The bad guys aren’t poking around on your systems within a limited scope, so why should you?

      Consider whether the tests should be performed so that they’re undetected by network administrators and any managed security service providers or related vendors. Though not required, this practice should be considered, especially for social engineering and physical security tests. I outline specific tests for those purposes in chapters 6 and 7.

      

If too many insiders know about your testing, they might improve their habits enough to create a false sense of vigilance, which can negate the hard work you put into the testing. This is especially true for phishing testing. Still, it’s almost always a good idea to inform the owner of the system, who may not be your sponsor. If you’re doing this testing for clients, always have a main point of contact — preferably someone who has decision-making authority.

      Picking your location

      The tests you perform dictate where you run them from. Your goal is to test your systems from locations that malicious hackers or insiders can access. You can’t predict whether you’ll