Hacker

Hacker has two meanings:

• Traditionally, hackers like to tinker with software or electronic systems. Hackers enjoy exploring and learning how computer systems operate. They love discovering new ways to work — both mechanically and electronically.

• In recent years, hacker has taken on a new meaning: someone who maliciously breaks into systems for personal gain. Technically, these criminals are crackers (criminal hackers). Crackers break into, or crack, systems with malicious intent. The gain they seek could be fame, intellectual property, profit, or even revenge. They modify, delete, and steal critical information as well as take entire networks offline, often bringing large corporations and government agencies to their knees.

  Don’t even get me started on how pop culture and the media have hijacked the word hack, from life hacking to so-called election meddling. Marketers, politicians, and media strategists know that the average person doesn’t understand the term hacking, so many of them use it however they desire to achieve their goals. Don’t be distracted.

The good-guy (white-hat) hackers don’t like being lumped in the same category as the bad-guy (black-hat) hackers. (In case you’re curious, the white hat and black hat come from old Western TV shows in which the good guys wore white cowboy hats and the bad guys wore black cowboy hats.) Gray-hat hackers are a bit of both. Whatever the case, most people have a negative connotation of the word hacker.

Many malicious hackers claim that they don’t cause damage but help others for the greater good of society. Yeah, whatever. Malicious hackers are electronic miscreants and deserve the consequences of their actions.

Be careful not to confuse criminal hackers with security researchers. Researchers not only hack aboveboard and develop the amazing tools that we get to use in our work, but also (usually) take responsible steps to disclose their findings and publish their code.

Malicious user

A malicious user — meaning a rogue employee, contractor, intern, or other user who abuses his or her trusted privileges — is a common term in security circles and in headlines about information breaches. The issue isn’t necessarily users hacking internal systems, but users who abuse the computer access privileges they’ve been given. Users ferret through critical database systems to glean sensitive information, email confidential client information to the competition or elsewhere to the cloud, or delete sensitive files from servers that they probably didn’t need to have access to in the first place.

Sometimes, an innocent (or ignorant) insider whose intent isn’t malicious still causes security problems by moving, deleting, or corrupting sensitive information. Even an innocent fat finger on the keyboard can have dire consequences in the business world. Think about all the ransomware infections affecting businesses around the world. All it takes is one click by a careless user for your entire network to be affected.

Malicious users are often the worst enemies of IT and information security professionals because they know exactly where to go to get the goods and don’t need to be computer-savvy to compromise sensitive information. These users have the access they need, and management trusts them — often without question.

What about that Edward Snowden guy — the former National Security Agency employee who ratted out his own employer? That subject is a complicated one. (I talk about hacker motivations in Chapter 2.) Regardless of what you think of Snowden, he abused his authority and violated the terms of his nondisclosure agreement. The same can be said of others who, for whatever reason, are placed on a pedestal because of their notoriety.

Vulnerability and penetration testing versus auditing

Many people confuse security testing via vulnerability and penetration testing with security auditing, but big differences exist in the objectives. Security auditing involves comparing a company’s security policies (or compliance requirements) with what’s actually taking place. The intent of security auditing is to validate that security controls exist, typically by using a risk-based approach. Auditing often involves reviewing business processes and in some cases isn’t very technical. Security audits, in fact, can be as basic as security checklists that simply serve to meet a specific compliance requirement.

Not all audits are high-level, but many of the ones I’ve seen — especially those involving compliance with the Payment Card Industry Data Security Standard (PCI DSS) and the Health Insurance Portability and Accountability Act (HIPAA) — are quite simplistic. Often, these audits are performed by people who have no technical computer, network, or application experience — or, worse, work outside IT altogether!

Conversely, security assessments based on ethical hacking focus on vulnerabilities that can be exploited. This testing approach validates that security controls don’t exist or are ineffectual. This formal vulnerability and penetration testing can be both highly technical and nontechnical, and although it involves the use of formal methodology, it tends to be a bit less structured than formal auditing. Where auditing is required (such as for SSAE 16 SOC 1/2/3 audits and the ISO 27001 certification) in your organization, you might consider integrating the vulnerability and penetration testing techniques I outline in this book into your IT/security audit program. Auditing and vulnerability and penetration testing complement one another really well.

Policy considerations

If you choose to make vulnerability and penetration testing an important part of your business’s information risk management program, you really need to have a documented security testing policy. Such a policy outlines who’s doing the testing, the general type of testing that’s performed, and how often the testing takes place. Specific procedures for carrying out your security tests could outline the methodologies I cover in this book. You might also consider creating a security standards document that outlines the specific security testing tools used and the specific people performing the testing. You could establish standard testing dates, such as once per quarter for external systems and biannual tests for internal systems — whatever works for your business.

Compliance and regulatory concerns

Your own internal policies may dictate how management views security testing, but you also need to consider the state, federal, and international laws and regulations that affect your business. In particular, the Digital Millennium Copyright Act (DMCA) sends chills down the spines of legitimate researchers. See www.eff.org/issues/dmca for everything that the DMCA has to offer.

Many federal laws and regulations in the United States — such as HIPAA and the associated Health Information Technology for Economic and Clinical Health (HITECH) Act, Gramm-Leach-Bliley Act (GLBA), North American Electric Reliability Corporation (NERC) Critical Infrastructure Protection (CIP) requirements, and PCI DSS — require strong security controls and consistent security evaluations. Related international laws —such as the Canadian Personal Information Protection and Electronic Documents Act (PIPEDA), the European Union’s General Data Protection Regulation (GDPR), and Japan’s Personal Information Protection Act (JPIPA) — are no different. Incorporating your security tests into these compliance requirements is a great way to meet state and federal regulations and to beef up your overall information security and privacy program.

Nontechnical attacks

Exploits that involve manipulating people — end users and even you — are the greatest vulnerability in any computer or network infrastructure. Humans are trusting by nature, which can lead to social-engineering exploits. Social engineering is exploiting the trusting nature of human beings to gain information (often via email phishing — for malicious purposes. Check out Chapter 6 for more information about social engineering and how to guard your systems against it.

Other common, effective attacks against information systems are physical. Hackers break into buildings, computer rooms, or other areas that contain critical information or property to steal computers, servers, and other valuable equipment. Physical attacks can also include dumpster diving — rummaging through trash cans and bins for intellectual property, passwords, network diagrams, and other information.

Network infrastructure attacks

Attacks on network infrastructures can be easy to accomplish because many networks can be reached from anywhere in the world via the Internet. Examples of network infrastructure attacks include the following:

• Connecting to a network through an unsecured wireless access point attached behind a firewall.
• Exploiting weaknesses in network protocols, such as File Transfer Protocol (FTP) and Secure Sockets Layer (SSL).
• Flooding a network with too many requests, creating denial of service (DoS) for legitimate requests.
• Installing a network analyzer on a network segment and capturing every packet that travels across it, revealing confidential information in clear text.

Operating system attacks

Hacking an OS is a preferred method of the bad guys. OS attacks make up a large 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 Mac OS 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
• 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. For example, the following are examples of application attacks and related exploits that are often present on business networks:

• Web 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, web 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 OneDrive and Google Drive. Database systems also contain numerous vulnerabilities that malicious users can exploit.

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 pay a fine or go to prison because of their poor choices. Keep in mind that you can be ethical but not trustworthy and vice versa, along the lines of Edward Snowden. These complexities are part of the overall challenges in your security program. I don’t envy you for this complexity.

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’ 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 an account or system lockout by using vulnerability scanners or by socially engineering someone into changing a password without realizing the consequences of your actions. Proceed with caution and common sense. Either way, be it you or someone else, these weaknesses still exist, and it’s better that you discover them first!

Many vulnerability scanners can control how many tests are performed on each system at the same time. 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.

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 authorized to perform the tests. Worse, you could be fired or charged with criminal activity.

The authorization can be as simple as an internal memo or an email from your boss when you perform these tests on your own systems. If you’re testing for a client, have a signed contract stating the client’s support and authorization. Get written approval of this sponsorship as soon as possible to ensure that none of your time or effort is wasted. This documentation is your “Get Out of Jail Free” card if anyone — such as your Internet service provider (ISP), cloud service provider, or a related vendor —questions what you’re doing or if the authorities come calling. Don’t laugh — it wouldn’t be the first time it has happened.

One slip can crash your systems, which isn’t necessarily what anyone wants. You need a detailed plan, but you don’t need volumes of testing procedures that make the plan overly complex. A well-defined scope includes the following information:

• Specific systems to be tested: When selecting systems to test, start with the most critical systems and processes or the ones that you suspect are the most vulnerable. You could test server OS passwords, test an Internet-facing web application, or attempt social engineering via email phishing before drilling down into all your systems.

• Risks involved: Have a contingency plan for your security testing process in case something goes awry. Suppose that you’re assessing your firewall or web application, and you take it down. This situation can cause system unavailability, which can reduce system performance or employee productivity. Worse, it might cause loss of data integrity, loss of data itself, and even bad publicity. It’ll most certainly tick off a person or two and make you look bad. All of these can create business risks.

  Handle social engineering and DoS attacks carefully. Determine how they might affect the people and systems you test.

• Dates when the tests will be performed and overall timeline: Determining when the tests are to be performed is something you must think long and hard about. Decide whether to perform tests during normal business hours, or late at night or early in the morning so that production systems aren’t affected. Involve others to make sure that they approve of your timing.

  You may get pushback and suffer DoS-related consequences, but the best approach is an unlimited attack, in which any type of test is possible at any time of day. The bad guys aren’t breaking into your systems within a limited scope, so why should you? Some exceptions to this approach are performing all-out DoS attacks, social engineering, and physical security tests.

• Whether you intend to be detected: One of your goals may be to perform the tests without being detected. You might perform your tests on remote systems or on a remote office and don’t want the users to be aware of what you’re doing. Otherwise, the users or IT staff may catch on to you and be on their best behavior instead of their normal behavior.

• Whether to leave security controls enabled: An important, yet often-overlooked, issue is whether to leave enabled security controls such as firewalls, intrusion prevention systems (IPSes), and web application firewalls (WAFs) so that they block scans and exploit attempts. Leaving these controls enabled provides a real-world picture of where things stand. But I’ve found much more value in disabling these controls (or whitelisting your IP address) so that you can pull back the curtains and find the greatest number of vulnerabilities.

  Many people want to leave their security controls enabled. After all, that approach can make them look better, because many security checks will likely be blocked. To me, however, this defense-in-depth approach is great, but it can create a serious false sense of security and doesn’t paint the entire picture of an organization’s overall security posture.

• Knowledge of the systems before testing: You don’t need extensive knowledge of the systems you’re testing — just basic understanding, which protects both you and the tested systems. Understanding the systems you’re testing 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 deeper. In fact, only one or two clients have asked me for a fully blind assessment.

  Most IT managers and others who are responsible for security are scared of blind assessments, which can take more time, cost more, and be less effective. Base the type of test you perform on the organization’s or client’s needs.

• Actions to take when a major vulnerability is discovered: Don’t stop after you find one or two security holes; keep going to see what else you can discover. I’m not saying that you should keep testing until the end of time or until you crash all your systems; ain’t nobody got time for that! Instead, simply pursue the path you’re going down until you can’t hack it any longer (pun intended). If you haven’t found any vulnerabilities, you haven’t looked hard enough. Vulnerabilities are there. If you uncover something big, you need to share that information with the key players (developers, database administrators, IT managers, and so on) as soon as possible to plug the hole before it’s exploited.
• The specific deliverables: Deliverables include vulnerability scanner reports and your own distilled report outlining important vulnerabilities to address, along with recommendations and countermeasures to implement.

Selecting tools

As in any project, if you don’t have the right tools for your security testing, you’ll have difficulty accomplishing the task effectively. Having said that, just because you use the right tools doesn’t mean that you’ll discover all the right vulnerabilities. Experience counts.

Know the limitations of your tools. Many vulnerability scanners generate false positives and negatives (incorrectly identifying vulnerabilities). Others skip vulnerabilities. In certain situations, such as testing web applications, you have to run multiple vulnerability scanners to find all the vulnerabilities.

Many tools focus on specific tests, and no tool can test for everything. For the same reason that you wouldn’t drive a nail with a screwdriver, don’t use a port scanner to uncover specific network vulnerabilities. You need a set of specific tools for the task. The more (and better) tools you have, the easier your security testing efforts will be.

Make sure that you’re using tools like these for your tasks:

• To crack passwords, you need cracking tools such as Ophcrack and Proactive Password Auditor.
• For an in-depth analysis of a web application, a web vulnerability scanner (such as Netsparker or Acunetix Web Vulnerability Scanner) is more appropriate than a network analyzer (such as Wireshark or Omnipeek).

The capabilities of many security and hacking tools are misunderstood. This misunderstanding has cast a negative light on otherwise excellent and legitimate tools; even government agencies around the world are talking about making them illegal. Part of this misunderstanding is due to the complexity of some security testing tools. Whichever tools you use, familiarize yourself with them before you start using them. That way, you’re prepared to use the tools in the ways that they’re intended to be used. Here are ways to do that:

• Read the readme and/or online help files and FAQs (frequently asked questions).
• Study the user guides.
• Use the tools in a lab or test environment.
• Watch tutorial videos on YouTube (if you can bear the poor production of most of them).
• Consider formal classroom training from the security-tool vendor or another third-party training provider, if available.

Look for these characteristics in tools for security testing:

• Adequate documentation.
• Detailed reports on discovered vulnerabilities, including how they might be exploited and fixed.
• General industry acceptance.
• Availability of updates and responsiveness of technical support.
• High-level reports that can be presented to managers or nontechnical types (especially important in today’s audit- and compliance-driven world).

These features can save you a ton of time and effort when you’re performing your tests and writing your final reports.

Executing the plan

Good security testing takes persistence. Time and patience are important. Also, be careful when you’re performing your tests. A criminal on your network or a seemingly benign employee looking over your shoulder may watch what’s going on and use this information against you or your business.

Making sure that no hackers are on your systems before you start isn’t practical. Just be sure to keep everything as quiet and private as possible, especially when you’re transmitting and storing test results. If possible, encrypt any emails and files that contain sensitive test information or share them via a cloud-based file sharing service.

You’re on a reconnaissance mission. Harness as much information as possible about your organization and systems, much as malicious hackers do. Start with a broad view and narrow your focus. Follow these steps:

1. Search the Internet for your organization’s name, its computer and network system names, and its IP addresses.

   Google is a great place to start.

2. Narrow your scope, targeting the specific systems you’re testing.

   Whether you’re assessing physical security structures or web applications, a casual assessment can turn up a lot of information about your systems.

3. Further narrow your focus by performing scans and other detailed tests to uncover vulnerabilities on your systems.
4. Perform the attacks and exploit any vulnerabilities you find (if that’s what you choose to do).

Check out Chapters 4 and 5 for information and tips on this process.

Evaluating results

Assess your results to see what you’ve uncovered, assuming that the vulnerabilities haven’t been made obvious before now. Knowledge counts. Your skill in evaluating the results and correlating the specific vulnerabilities discovered will get better with practice. You’ll end up knowing your systems much better than anyone else does, which will make the evaluation process much simpler moving forward.

Submit a formal report to management or to your client, outlining your results and any recommendations you need to share. Keep these parties in the loop to show that your efforts and their money are well spent. Chapter 17 describes the security assessment reporting process.

Moving on

When you finish your security tests, you (or your client) still need to implement your recommendations to make sure that the systems are secure. Otherwise, all the time, money, and effort spent on testing goes to waste. Sadly, I see this very scenario fairly often.

New security vulnerabilities continually appear. Information systems change and become more complex. New security vulnerabilities and exploits are uncovered. Vulnerability scanners get better. Security tests provide a snapshot of the security posture of your systems. At any time, everything can change, especially after you upgrade software, add computer systems, or apply patches. This situation underscores the need to update your tools often — before each use, if possible. Plan to test regularly and consistently (such as once a month, once a quarter, or biannually). Chapter 19 covers managing security changes as you move forward.