Hacking For Dummies. Kevin Beaver

portion of attacks simply because every computer has an operating system. They are susceptible to many well-known exploits, including vulnerabilities that remain unpatched years later.

      Occasionally, some OSes that tend to be more secure out of the box — such as the old-but-still-out-there Novell NetWare, OpenBSD, and IBM Series i — are attacked, and vulnerabilities turn up. But hackers tend to prefer attacking Windows, Linux, and macOS because they’re more widely used.

      Here are some examples of attacks on operating systems:

       Exploiting missing patches

       Attacking built-in authentication systems

       Breaking file system security

       Installing ransomware to lock down the system to extort money or other assets

       Cracking passwords and weak encryption implementations

      Application and other specialized attacks

Applications take a lot of hits by hackers. Web applications and mobile apps, which are probably the most popular means of attack, are often beaten down. The following are examples of application attacks and related exploits that are often present on business networks:

       Websites and applications are everywhere. Thanks to what’s called shadow IT, in which people in various areas of the business run and manage their own technology, website applications are in every corner of the internal network and out in the cloud. Unfortunately, many IT and security professionals are unaware of the presence of shadow IT and the risks it creates.

       Mobile apps face increasing attacks, given their popularity in business settings. There are also rogue apps discovered on the app stores that can create challenges in your environment.

       Unsecured files containing sensitive information are scattered across workstation and server shares as well as out into the cloud in places like Microsoft OneDrive and Google Drive. Database systems also contain numerous vulnerabilities that malicious users can exploit.

Following the Security Assessment Principles

      Security professionals must carry out the same attacks against computer systems, physical controls, and people that malicious hackers do. (I introduce those attacks in the preceding section.) A security professional’s intent, however, is to highlight any associated weaknesses. Parts 2 through 5 of this book cover how you might proceed with these attacks in detail, along with specific countermeasures you can implement against attacks on your business.

      To ensure that security testing is performed adequately and professionally, every security professional needs to follow a few basic tenets. The following sections introduce the important principles.

      

If you don’t heed these principles, bad things could happen. I’ve seen them ignored or forgotten by IT departments while planning and executing security tests. The results weren’t positive; trust me.

      Working ethically

The word ethical in this context means working with high professional morals and values. Whether you’re performing security tests against your own systems or for someone who has hired you, everything you do must be aboveboard in support of the company’s goals, with no hidden agenda — just professionalism. Being ethical also means reporting all your findings, whether or not they may create political backlash. Don’t laugh; on numerous occasions, I’ve witnessed people brushing off security vulnerability findings because they didn’t want to rock the boat or to deal with difficult executives or vendors.

      Trustworthiness is the ultimate tenet. It’s also the best way to get (and keep) people on your side in support of your security program. Misusing information and power is forbidden; that’s what the bad guys do, so let them be the ones who pay a fine or go to prison because of their poor choices.

      Respecting privacy

      Treat the information you gather with respect. All information you obtain during your testing — from web application flaws to clear text email passwords to personally identifiable information (PII) and beyond — must be kept private. Nothing good can come of snooping into confidential corporate information or employees’ or customers’ private lives.

      

Involve others in your process. Employ a peer review or similar oversight system that can help build trust and support for your security assessment projects.

      Not crashing your systems

      One of the biggest mistakes I’ve seen people make when trying to test their own systems is inadvertently crashing the systems they’re trying to keep running. Crashing systems doesn’t happen as often as it used to given the resiliency of today’s systems, but poor planning and timing can have negative consequences.

      Although you’re not likely to do so, you can create DoS conditions on your systems when testing. Running too many tests too quickly can cause system lockups, data corruption, reboots, and similar problems, especially when you’re testing older servers and web applications. (I should know; I’ve done it!) Don’t assume that a network or specific host can handle the beating that network tools and vulnerability scanners can dish out.

      You can even accidentally create accounts or lock users out of the network without realizing the consequences. Proceed with caution and common sense. Either way, be it you or someone else, these weaknesses likely exist on your network, and it’s better that you discover them first!

Most vulnerability scanners can control how many requests are sent to each system simultaneously. These settings are especially handy when you need to run the tests on production systems during regular business hours. Don’t be afraid to throttle back your scans. Completing your testing will take longer, but throttling back may save you a lot of grief if an unstable system is present.

Using the Vulnerability and Penetration Testing Process

      As with practically any IT or security project, you need to plan security testing. It’s been said that action without planning is the root of every failure. Strategic and tactical issues in vulnerability and penetration testing need to be determined and agreed on in advance. To ensure the success of your efforts, spend time planning for any amount of testing, from a simple OS password-cracking test against a few servers to a penetration test of a complex web environment.

      

If you choose to hire a “reformed” hacker to work with you during your testing or to obtain an independent perspective, be careful. I cover the pros and cons and the do’s and don’ts associated with hiring security resources in Chapter 19.

      Formulating your plan

      Getting approval for security testing is essential. Make sure that what you’re doing is known and visible — at least to the decision-makers. Obtaining sponsorship of the project is the first step. This is how your testing objectives are defined. Sponsorship could come from your manager, an executive, your client, or even yourself if you’re the boss. You need someone to back you up and sign off on your plan. Otherwise, your testing may be called off unexpectedly if someone (including third parties such as cloud service and hosting providers) claims that you were never