Kevin Beaver - Hacking For Dummies

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, was@qualys.com for Qualys Web Application Scanner and scanner@probe.ly for Probely — and then block those emails at the server level.

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 6and 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.

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 be attacked by someone inside or outside your network, so cover your bases as much as you can. Combine external (public Internet) tests and internal (private network) tests.

You can perform some tests, such as password cracking and network infrastructure assessments, from your office. For external tests that require network connectivity, you may have to go off-site (a good excuse to work from home), use an external proxy server, or simply use guest Wi-Fi that might have a separate Internet connection. Many security vendors’ vulnerability scanners can be run from the cloud. If you can assign an available public IP address to your computer, plug into the network outside the firewall for a hacker’s-eye view of your systems. Just make sure that system is secure because it will be exposed to the world!

Internal tests are easy because you need only physical access to the building and the network. Just plug right in and have at it. If you dig around from the perspective of a visitor or guest, you might find an open network port that provides full access to your network. This is often a huge vulnerability, especially if the public has full access — such as in a hospital lobby or waiting room area. I’ve seen it!

Determine ahead of time whether you’ll stop or keep going when you find a critical security hole. You don’t need to keep testing forever. Just follow the path you’re on until you’ve met your objectives or reached your goals. When in doubt, have a specific goal in mind and stop when you meet that goal.

If you don’t have goals, how are you going to know when you reach your security testing destination?

If you discover a major hole, such as SQL injection on an external web application or a missing patch that provides full remote access to a critical system, I recommend contacting the necessary people as soon as possible so that they can begin fixing the issue right away. The necessary people may be software developers, product or project managers, or even Chief Information Officers in charge of it all. If you wait a few hours, days, or weeks, someone may exploit the vulnerability and cause damage that could have been prevented, potentially creating bigger legal issues.

You’ve heard what you make of yourself when you assume things. Even so, you make assumptions when you test your systems. Here are some examples of those assumptions:

All the computers, networks, applications, and people are available when you’re testing. (They won’t be.)

You have all the proper testing tools. (When you start your testing — at least early on in your journey — you’ll be lucky to have half of what you actually end up needing.)

The testing tools you use minimize your chances of crashing the systems you test. (Nope, especially if you don’t know how to use them properly.)

You understand the likelihood that you’re going to overlook something. (You will.)

You know the risks of your tests. (The risks can be especially high when you don’t plan properly.)

Document all assumptions and ensure all the right people are onboard. You won’t regret doing that.

Which security assessment tools you need depend on the tests you’re going to run. You can perform some security tests with a pair of sneakers, a telephone, and a basic workstation on the network, but comprehensive testing is easier when you have good, dedicated tools.

The tools I discuss in this book aren’t malware, based on my knowledge of them. The tools and even their websites may be flagged as such by certain antimalware and web filtering software, but they’re not malware. For example, Metasploit is often flagged as malware when it’s a completely legitimate security testing tool. I cover only legitimate tools in this book, many of which I’ve used for years. If you experience trouble downloading, installing, or running the tools I cover in this book, consider configuring your system to allow them through or otherwise trust their execution. Keep in mind that I can’t make any promises. Use checksums where possible by comparing the original MD5 or SHA checksum with the one you get using a tool such as CheckSum Tool ( http://sourceforge.net/projects/checksumtool ). A criminal could always inject malicious code into the actual tools, so there’s no guarantee of security. You knew that anyway, right?