Part II: Tools for Auditing and Defending the Hosts - USA Order Công cụ & ứng dụng ủy quyền trang web

Hot

Với thương hiệu USAOrder.VN & Hà Nội Lab Ra đời vào năm 2004 chuyên về laptop nhập chính hãng từ Mỹ và hiện tại là nơi kết nối các sản phẩm chính hãng từ Mỹ và thế giới USAOrder.VN hiện hỗ trợ các mặt hàng hóa khó số lượng lớn trong nước và quốc tế hỗ trợ đưa ra giải pháp tối ưu quy trình vận chuyển tự động hóa tiết kiệm, hiệu quả thông quan bảo đảm an toàn.

Post Top Ad

Thứ Bảy, 9 tháng 6, 2018

Part II: Tools for Auditing and Defending the Hosts

Part II: Tools for Auditing and Defending the Hosts

Chapter List

Chapter 4: Port Scanners

Chapter 4: Port Scanners

Overview

Back in Chapter 1, you learned that one of Netcat’s many uses is as a Transmission Control Protocol (TCP) or User Datagram Protocol (UDP) port scanner. However, Netcat’s port scanning features are rather limited in that the tool always makes a genuine TCP connection (no specialized stealth methods), it can handle only one host at a time, and the scan output format is rather crude. Chances are, if you want to do port scanning the right way, you’re going to need a tool specifically focused on scanning ports and returning valuable information about a group of hosts. This chapter covers several such tools. Each tool will enumerate a specified range of TCP or UDP ports and attempt to send specially crafted packets to each port to gather information. However, the methods and capabilities by which each tool performs its tasks can vary.
Port scanners are useful in the early stages of hacking or hacking prevention because they help identify potential targets. Nearly every host—regardless of hardware, software, or function—has some kind of identifying feature. A casual observer with the right tools might be able to discover the services a machine is running (web server, FTP server, mail server, and so on), the version level, and even the operating system of the host by sending it a few packets of data and scrutinizing how it responds.
In today’s world, despite the nearly daily accounts of hacking incidents, many people place their computers on the Internet unprepared. Even within the IT industry, system administrators will install the latest version of Linux on a brand-new server, perhaps install some extra software, and let it do its thing. As soon as that box is discovered, though, someone will be able to determine not only that it’s running Linux, but also what distribution of Linux it’s running as well as the version number.
In the Case Study “Ports Painting a Picture,” you’ll learn how the number and types of ports found on a host can help to identify the operating system and software versions running on that host.
In the Case Study, “Banner Identification,” you’ll learn how the technique of banner grabbing can still be used to obtain OS, version, and geographical information about a host.
In the Case Study, “OS Fingerprinting,” you’ll learn how a host’s operating system might be identified just by watching how it interacts on a network.


Previous Section
 < Day Day Up > 
Next Section

Chapter 5: Unix Enumeration Tools

Chapter 5: Unix Enumeration Tools

Many of the most useful tools you’ll ever encounter are either included with your Unix distribution as system utilities or are open source and freely downloadable. We’ll cover some of the basic tools in this chapter.

Samba: Server Message Block Implementation for Unix

When people think of Windows and networks, they ultimately think of the Network Neighborhood, which has recently been expanded to My Network Places in Windows 200x, Me, and XP. When you browse through networks and access files in this manner, you are using a protocol called Server Message Block Protocol (SMB). Most people who share public folders and files on their computers believe that only their peers on their Local Area Network (LAN) have access to the network shares in Network Neighborhood. In reality, however, unless your computer is protected by network address translation (NAT) or a firewall, anyone in the world can find those public shares and connect to them. Anyone.
In addition to Network Neighborhood, Windows has command-line tools to access shares via SMB (discussed in Chapter 6). Unix systems also have SMB-based file-sharing capabilities. Samba contains both client and server abilities that allow you to set up file sharing on a Unix box so that a Windows user in Network Neighborhood can access your Unix share. Additionally, the Samba client can be used to access Windows shares. In this section, we’ll focus only on the Samba client tools that you can use on the Unix side to gain access to SMB shares.

Smbclient

You can think of smbclient as an FTP client front end to an SMB file share. Smbclient is similar to net use on the Windows side. Let’s take a look at some of the commands we can try.

Implementation

First we need to see what shares are available. We can use the –L hostname option to view the shares on a host, but if our smbclient isn’t able to resolve the NetBIOS name to an IP address, we’ll have to specify that separately with the –I flag. We also use the –N option to skip prompting for any passwords (since we should be able to access this information without one).
[jdoe@originix ~]$ smbclient –N -L badman -I 192.168.1.101
Added interface ip=192.168.1.100 bcast=192.168.1.255 nmask=255.255.255.0
   
        Sharename      Type      Comment
        ---------      ----      -------
        MP3S           Disk
        HALF-LIFE      Disk
        CDRW           Disk
        INSTALL        Disk
        D              Disk
        IPC$           IPC       Remote Inter Process Communication
   
        Server               Comment
        ---------            -------
        BADMAN               The bad machine
   
        Workgroup            Master
        ---------            -------
        MYWORKGROUP          BADMAN
The output of this command looks similar to that of the net view command seen in Chapter 6—except smbclient was nice enough to tell us about the hidden IPC$ share! The IPC$ share, which will be discussed further in Chapter 6, is a special shared "pipe" that can allow you to execute commands remotely. Notice that in the command line, we actually needed to specify the NetBIOS name of the box (badman). Without it, we wouldn’t have gotten any of this information. We’ll talk about how we obtain this important piece of information in the "Nmblookup" section later in this chapter.
Now let’s see what happens when we try to connect to a share:
[jdoe@originix ~]$ smbclient //badman/mp3s -I 192.168.1.101
Added interface ip=192.168.1.100 bcast=192.168.1.255 nmask=255.255.255.0
Password:
smb: \> ls
  Innocent.mp3                 A  5269507  Sat Feb  3 02:04:14 2001
  Awake.mp3      A  7302760  Mon Feb 12 18:16:44 2001
  River.mp3      A  5324800  Wed Jan  3 19:04:12 2001
            39060 blocks of size 524288. 18784 blocks available
We try an empty password and get in. Now we can use standard FTP commands (get, put, ls) to determine whether we can read and write files to this share. When we need to log in to a share as a specific user, we use the –U <username> option.
Tip 
If you need a password to access a share, you can specify the password on the command line instead of waiting to be prompted for it. However, that’s probably not a good idea since it will get recorded as plain text in your shell’s history file!
In Windows, you can map a shared resource to a network drive on your computer. Samba allows you to do the same thing using the smbmount command. If you wanted to map the MP3s resource above to a directory called /mnt/mp3s on your Unix file system, you would type this:
[jdoe@originix ~]$ smbmount //badman/mp3s /mnt/mp3s -I 192.168.1.101
Added interface ip=192.168.1.100 bcast=192.168.1.255 nmask=255.255.255.0
Password:
[jdoe@originix ~]$
You can now manipulate the files in that share using Unix system commands. When you’re finished, you can unmount the share just as you would any Unix file system.
Can we also use Samba to establish a null session with the IPC$ share? Well, not really. We can connect to the IPC$ share with smbclient using null user credentials, but this doesn’t accomplish much. Because the IPC$ share is a pipe and not a file share, smbclient can’t do much with it once we’re connected. You can use rpcclient, included with the Samba distribution, to make use of the IPC$ share—but you’ll need user credentials on the Windows box to use it.

Rpcclient

Rpcclient can be used to execute Windows remote procedure calls (RPCs) from a Unix box. To connect to the IPC$ share on our Windows 2000 box (192.168.1.150), we use this command:
[jdoe@originix ~]$ rpcclient –U administrator 192.168.1.150
Password:
rpcclient $>
Once you supply the Administrator password, you’ll be able to perform any number of remote administration commands. Type a ? and press ENTER at this prompt to obtain a list. You cannot establish a NULL IPC$ session with rpcclient.

Nmblookup

We talked about the problem of needing to know NetBIOS names. This Unix-based tool helps us find out that information.

Implementation

Let’s see what happens when we run nmblookup against 192.168.1.101:
[jdoe@originix ~]$ nmblookup -A 192.168.1.101
Sending queries to 192.168.1.255
Looking up status of 192.168.1.101
received 8 names
        BADMAN          <00> -         B <ACTIVE>
        MYWORKGROUP     <00> - <GROUP> B <ACTIVE>
        BADMAN          <03> -         B <ACTIVE>
        BADMAN          <20> -         B <ACTIVE>
        MYWORKGROUP     <1e> - <GROUP> B <ACTIVE>
        JOEUSER         <03> -         B <ACTIVE>
        MYWORKGROUP     <1d> -         B <ACTIVE>
        ..__MSBROWSE__. <01> - <GROUP> B <ACTIVE>
num_good_sends=0 num_good_receives=0
Not exactly what we were hoping for. We got some names, but how do we know what’s what? In this particular example, it’s pretty easy to guess that the hostname we’re looking for is BADMAN. The output of this command is nearly identical to the output of the nbtstat –A command discussed in Chapter 6. The “NBTSTAT” section in Chapter 6 will help you to interpret the NetBIOS codes in this output.
If we need to go the other way and find the IP of a NetBIOS name, we can do that, too:
[bjohnson@originix ~]$ nmblookup badman
Sending queries to 192.168.1.255
192.168.1.101 badman<00>
If we add a –S flag, nmblookup includes the same information included from the –A command earlier.
Nmblookup goes through several different methods to attempt to resolve the name (configurable in the smb.conf file). Available methods are WINS or lmhosts, DNS or hosts, or broadcast (which requires that the target be on the same subnet).

Automating the Process

Clearly, you can do a lot of things with SMB file shares once you find them. Several “smbscan” programs are available, both for Windows and Unix, that can scan ranges of IP addresses looking for open shares and attempting to access each one. These tools simply use these underlying methods on a larger scale. For example, the Nessus tool discussed in Chapter 12 scans for open SMB shares as part of its vulnerability assessment.


Previous Section
 < Day Day Up > 
Next Section
Chapter 6: Windows Enumeration Tools

Chapter 6: Windows Enumeration Tools

Overview

In Arthur Conan Doyle’s The Valley of Fear, Sherlock Holmes berates a police inspector: “Breadth of view is one of the essentials of our profession. The interplay of ideas and the oblique uses of knowledge are often of extraordinary interest.” In this chapter, we hope to demonstrate how to collect knowledge about remote computers for your own, oblique uses. At the very least, you might like to generate a list of users who have interactive access to the target system; but many other bits of information can be collected as well. What software is installed? What patches have (or have not) been applied? Password guessing is one of the oldest, most basic ways to attack a system, but does the target system lock accounts after a certain number of incorrect passwords?
Knowledge about a remote system helps you form an idea of the vulnerabilities that may be present. In other cases, file shares with sensitive data may be left open—misconfigured to allow anonymous access. You need to look for comprehensive, detailed information well beyond a port scan.
The Windows Network Neighborhood, which has evolved into My Network Places in Windows 2000, Me, and XP, uses a protocol called Server Message Block Protocol (SMB). Most people who share public folders and files from their computers believe that only their peers on the local area network (LAN) have access to the network shares in Network Neighborhood. In reality, it’s quite possible that anyone on the Internet could connect to the file share. The only inherent restriction is that the share may require a username and password.
The majority of information about a Windows system is culled from the IPC$ (InterProcess Communications) share, a default share on the Windows NT, 2000, and XP family of systems. It handles communication between applications on a single system or among remote systems. To support distributed login and a domain environment, the IPC$ share provides an enormous amount of system and user information to servers that request it.
The most basic connection is a NULL, or anonymous, connection, which is set up manually with the net command:
C:\>net use \\target\ipc$ "" /u:""
The smbclient command (from the Samba suite, which is described in Chapter 5) can also establish a NULL session, but only the original net use sets up a connection over which other tools can be run.
$ smbclient \\\\target\\ipc\$ ""  –U ""
The significance of this simple, anonymous connection will become evident as you use tools to enumerate information about the target system.
Note 
With the advent of Windows 2003, system administrators are no longer plagued by insecure default settings. A default installation of Windows 2003 will not reveal the sensitive information normally gathered from the chatty IPC$ share; however, a Windows 2003 PDC may still divulge this information— including lists of users and domains.


Previous Section
 < Day Day Up > 
Next Section
Chapter 7: Web Hacking Tools

Chapter 7: Web Hacking Tools

Overview

Web server security can be divided into two broad categories: testing the server for common vulnerabilities and testing the web application. A web server should be configured according to this checklist before it is deployed on the Internet:
  • Secure network configuration   A firewall or other device limits incoming traffic to necessary ports (probably just 80 and 443).
  • Secure host configuration   The operating system has up-to-date security patches, auditing has been enabled, and only administrators may access the system.
  • Secure web server configuration   The web server’s default settings have been reviewed, sample files have been removed, and the server runs in a restricted user account.
Of course, such a short list doesn’t cover the specifics of an Apache/PHP combination or the details of every recommended Internet Information Server (IIS) installation setting, but it should serve as the basis for a strong web server build policy. A vulnerability scanner should also be used to verify the build policy.
The security of the web application should be of concern as well. This chapter focuses on tools used to check a web server for common vulnerabilities, but the handful of tools mentioned here address the concept of testing the actual web application for security problems rather than just the server upon which the application is installed.


Previous Section
 < Day Day Up > 
Next Section
Chapter 8: Password Cracking / Brute-Force Tools

Chapter 8: Password Cracking / Brute-Force Tools

Overview

A smile, a house key, a password. Whether you’re trying to get into a nightclub, your house, or your computer, you will need something that only you possess. On a computer network, users’ passwords have to be strong enough so that Dwayne can’t guess Norm’s password and Norm can’t steal Dwayne’s password (since Dwayne might have written it on the bottom of his keyboard). Bottom line—one weak password can circumvent secure host configurations, up-to-date patches, and stringent firewall rules.
In general, an attacker has two choices when trying to ascertain a password. He can obtain a copy of the password or hash if encrypted and then use brute-force tools to crack the encrypted hash. Or he can try to guess a password. Password cracking is an old technique that is most successful because humans are not very good random sequence generators.
It’s important that you understand how (and where) most passwords are stored so you know what these tools are doing and the method behind their madness. Passwords on Unix and Windows systems are stored with “one-way” hashes, and these passwords cannot be decrypted. Instead, a user login goes through a simple process. For example, Neil’s password abc123 is stored on a Unix system as the hash kUge2g0BqUb7k (remember, we can’t decrypt this hash). When Neil tries to log into the system, imagine he mistypes the passwords as abc124. The Unix system calls its crypt() function on the password abc124 to generate a temporary hash. The hash for abc124 will not match the stored hash for abc123, so the system tells Neil he has entered an incorrect password. Notice what has happened here. The candidate password (abc124) is hashed and matched to the stored hash (kUge2g0BqUb7k). The stored hash is not decrypted. Taking the hash of a known word and comparing it to the target hash of the password is the basis for password-cracking attacks.


Previous Section
 < Day Day Up >
Chapter 9: Host Hardening

Chapter 9: Host Hardening

Overview

The concept of hardening a system is well known for its benefit of preventing, or at least mitigating, exploits for which the system has not been patched. System hardening is also well documented in numerous checklists, e-mail threads, sticky notes, pricey consultant recommendations, and vendor web sites. One would think that all of this information would lead to more secure systems. Unfortunately, it is quite obvious that the simple identification of a solution set does not solve a problem. The blatant application of a detailed checklist’s recommendations leads to the unnecessary impression that security is designed to reduce functionality. Conversely, a vague checklist of security platitudes raises awareness for a problem that has already been identified.
One of the important pieces missing in host-based security deployment plans is a tool or set of tools to secure the system and faithfully repeat that configuration for many systems, preferably without your having to be physically present at the system console. This chapter focuses on simple tools that create a hardened system from a network perspective. Our goal for this chapter is not to discuss the differences in hardening a system that focuses on a single network service (such as a web server), serves as a workstation, or is designed to be a shared user environment (such as a providing Unix shell accounts); yet, more importantly, the chapter informs you of some of the more powerful tools.
Tip 
If you still wish to review checklists and examine the most common security recommendations, check out the guidelines published by the NSA at http://nsa1.www.conxion.com/. While these guidelines are comprehensive, blindly applying every recommendation may create a system that does not function well in a networked environment.


Previous Section
 < Day Day Up > 
Next Section
Chapter 10: Backdoors and Remote Access Tools

Chapter 10: Backdoors and Remote Access Tools

Overview

Backdoors and remote access tools are important for any security professional to understand. For the security auditor who performs attack and penetration assessments, such tools are important because hackers can use them to obtain an initial foothold into an otherwise secure network. For the security administrator, understanding the tools’ fingerprints and potential entry points into the network is an ongoing task. For the security incident investigator, the fingerprint and remediation process must be clearly understood to keep the network running and to build legal cases against offenders. This chapter will address issues and tools important for security auditors, administrators, and incident investigators.
Possibly the best use for this category of tools during security assessments is to aid in determining whether the system users are the weakest links in an organization’s security architecture. Some of the tools discussed in this chapter, as you will see, can be detected by intrusion-detection systems (IDS) and anti-virus countermeasures. Because backdoors and remote access tools can be distributed inadvertently by users for entry into the network, the tools discussed in this chapter would be a good check to determine whether your IDS and anti-virus sentries are doing their job as advertised.
Because some remote access software packages are typically used with good intentions, they are not usually considered “hacking tools.” Therefore, most virus detectors and IDSs will not be on the lookout for these tools unless they are tuned to do so. It may be a smart move for an intruder to use a tool designed with good intentions with the ultimate intent of evading detection. One tool that is a “good intention” remote control/backdoor tool in this chapter is Virtual Network Computing (VNC).
Other tools have been designed specifically for nefarious purposes. These are tools written and modified by those considered in the “underground.” These types of tools are typically detected by virus checkers and host- or network-based IDSs and therefore often employ better techniques—such as mutation engines, encryption techniques, and changing parameters—to foil the dominant signature-based recognition systems of countermeasure tools.
Typically, up-to-date virus checkers quickly spot the installation files and a good IDS will generate an alert when it sees the related traffic. While these tools may not pop up very often on networks with savvy administrators, they are often used to target less sophisticated networks and less aware users. This chapter covers the nefarious tools Back Orifice, Netbus, and SubSeven.
Yet another breed of backdoor tools dwarfs the other two categories: Kernel Rootkits and covert channels. These types of tools are difficult to detect, and sometimes remediation may seem impossible. Thorough understanding of how these tools operate should bring some enlightenment to how the tools’ programmers attack systems at their most fundamental level. These tools would be used by an auditor with a high level of comfort in the security field, but it is unlikely they would be used in any scenario other than a narrowly targeted test.
Virus scanners typically do not detect these files (the majority are Unix-based), but their activity could be detected by a well-configured IDS. However, if proper attention is given to their use, even detection will not supply the victim with much information. The tools discussed in this chapter that belong to this category are Loki, stcpshell, and Knark.


Previous Section
 < Day Day Up > 
Next Section
Chapter 11: Simple Source Auditing Tools

Chapter 11: Simple Source Auditing Tools

Overview

Aquick perusal of security web sites and mailing lists that catalog software vulnerabilities reveals a noticeable trend: Buffer overflows are responsible for remote vulnerabilities in software—regardless of the vendor, hardware, or operating system. It would be nice to have an extra compile option that would totally “securify” code as it is built. Some blame buffer overflows on the capability of C and C++ to handle raw memory and set pointers; they see these capabilities as inherent insecurities in the language.
Active Server Pages (ASP), Perl, Python, and PHP have their own insecurities—the world of hacking web applications based on these languages is alive and well. But well- written code, written in any language, tends to be secure code. The OpenBSD project lives by the tenet that security derives from diligent bug fixing. If, for example, someone discovers that one program uses the snprintf function incorrectly, a bug hunt is called in every other program that uses the snprintf function. Not every bug leads to a security vulnerability in the sense of a remote exploit, but stability, maintainability, and proactive defenses are all part of an excellent application.


Previous Section
 < Day Day Up > 
Next Section
Chapter 12: Combination System Auditing Tools

Chapter 12: Combination System Auditing Tools

Overview

If every software application worked the way it was supposed to, we wouldn’t have to write this chapter. But because we live in an imperfect world, we can be sure that applications and services running on our systems will inevitably have bugs. What’s worse, even the best-written applications could be running in a misconfigured state on our systems. Both bugs and misconfigurations can give a hacker a potentially easier, more surreptitious way into your network and systems. These problems can also let hackers ruin your day by crashing critical systems and services.
Bugs and misconfigurations are called vulnerabilities. Nearly every system on your network probably has varying degrees of vulnerabilities. Some vulnerabilities are known to be exploitable, and the motivated hacker can scour Internet resources for code that will exploit the vulnerability. Other vulnerabilities don’t yet have an available exploit, but more than likely people are hard at work on a “proof-of-concept” exploit that may or may not fall into the wrong hands. Even more vulnerabilities exist undiscovered, just waiting to be found.
Attacks on vulnerabilities usually cause a service or application to crash or malfunction in some manner. Some of these attacks bring down the application to a level where it’s no longer running; others eat up so many system resources that the system can no longer function properly. These kinds of vulnerability attacks are called Denial-of-Service (DoS) attacks.
Other vulnerabilities let the hacker tell the application to perform tasks that it normally shouldn’t be able to do. And because many services are run by the root or Administrator user (even though they might not always need to be), a hacker can often gain super user privileges on the system, bypassing the usual valid login process. In this scenario, two different kinds of vulnerabilities are actually being exploited: the bug that lets you manipulate the service in an unintended manner, which is an application vulnerability, and the misconfiguration of the service (running as the root or Administrator user), which is a misconfiguration vulnerability. If the service is run by an unprivileged user with proper access rights, a hacker who exploits the application vulnerability doesn’t gain as much access. If a hacker attacks a web service that is running as Administrator and the exploit allows him to run system commands as that web service user, the hacker has full run of the system. However, if a hacker exploits a similar web service that is running as an unprivileged user (say “IUSR”), the hacker has access only to the part of the system that the IUSR user can access. By eliminating the misconfiguration vulnerability, the application vulnerability becomes less severe.
For network managers and administrators, the race is on to find the vulnerabilities on their systems before someone else does.




Previous Section
 < Day Day Up > 
Next Section


Previous Section
 < Day Day Up > 
Next Section

Không có nhận xét nào:

Đăng nhận xét

Post Top Ad