Inside, you'll find concise technical overviews, the latest attack methods, and ready-to-deploy countermeasures. Find out how to leverage wireless eavesdropping, break encryption systems, deliver remote exploits, and manipulate Through his experiences as a penetration tester, Josh has worked with hundreds of organizations on attacking and defending mobile devices and wireless systems, disclosing significant product and protocol security weaknesses to well-known organizations.
Search Engine. The latest wireless security solutionsProtect your wireless systems from crippling attacks using the detailed security information in this comprehensive volume.
Thoroughly updated to cover today's established and emerging wireless technologies, Hacking Exposed Wireless, second edition reveals how attackers use readily available and custom tools to target, infiltrate, and hijack vulnerable systems. Cutting-edge techniques for exploiting Wi-Fi clients, WPA2, cordless phones, Bluetooth pairing, and ZigBee encryption are also covered in this fully revised guide. Secure Your Wireless Networks the Hacking Exposed WayDefend against the latest pervasive and devastating wireless attacks using the tactical security information contained in this comprehensive volume.
Hacking Exposed Wireless reveals how hackers zero in on susceptible networks and peripherals, gain access, and execute debilitating attacks. On the freeware side, Nessus www. Needless to say, these attackers were inexpert and unsuccessful. Remote access is defined as gaining access via the network for example, a listening service or other communication channel. Local access attacks are also referred to as privilege escalation attacks. It is important to understand the relationship between remote and local access.
There is a logical progression where attackers remotely exploit a vulnerability in a listening service and then gain local shell access. Once shell access is obtained, the attack- ers are considered to be local on the system. We try to logically break out the types of at- tacks that are used to gain remote access and provide relevant examples. Once remote access is obtained, we explain common ways attackers escalate their local privileges to root. Finally, we explain information-gathering techniques that allow attackers to garner information about the local system so that it can be used as a staging point for additional attacks.
Rather, we aim to cate- gorize these attacks and to explain the theory behind them. Thus, when a new attack is discovered, it will be easy to understand how it works, though it was not specifically cov- ered.
The media would like everyone to believe that there is some sort of magic involved with compromising the security of a UNIX system. In reality, there are three primary methods to remotely circumventing the security of a UNIX system: 1. Routing through a UNIX system that is providing security between two or more networks 3. How can you log in to the system if it is not running a service that allows interactive logins telnet, ftp, rlogin, or ssh? Are your systems vulnerable?
Potentially, but attackers would have to exploit a listening service, wuftp, to gain access. It is imperative to remember that a service must be listening to gain access. If a service is not listening, it cannot be broken into remotely. How is this possible? In many instances attackers circumvent UNIX firewalls by source routing packets through the firewall to internal systems. This feat is possible because the UNIX kernel had IP forwarding enabled when the firewall application should have been performing this function.
In most of these cases, the attackers never actually broke into the firewall per se; they simply used it as a router. Maybe not. What if you surf to www. This may allow evilhacker. Think of the implications of this if you were logged in with root privileges while web surfing. Throughout this section, we will address specific remote attacks that fall under one of the preceding three categories.
If you have any doubt about how a remote attack is possi- ble, just ask yourself three questions: 1. Is there a listening service involved? Does the system perform routing? You are likely to answer yes to at least one question. A brute force attack may not appear sexy, but it is one of the most effective ways for attackers to gain access to a UNIX system.
Services like finger, rusers, and sendmail were used to identify user accounts on a target system. Once attackers have a list of user accounts, they can begin trying to gain shell access to the target system by guessing the password associated with one of the IDs.
Unfortunately, many user accounts have either a weak password or no password at all. Given enough users, most systems will have at least one Joe account. To our amazement, we have seen thousands of Joe ac- counts over the course of performing our security reviews. Why are poorly chosen pass- words so common? While it is entirely possible to guess passwords by hand, most passwords are guessed via an automated brute force utility. A one-time password mechanism would be most desirable. Some freeware utili- ties that will help make brute forcing harder are listed in Table In addition to these tools, it is important to implement good password management procedures and to use common sense.
A data driven attack is executed by sending data to an active service that causes unintended or undesirable results. Data driven attacks are categorized as either buffer overflow attacks or input validation attacks. Each attack is described in detail next. Buffer overflow attacks date as far back as and the infamous Robert Morris Worm incident; however, useful infor- mation about specific details of this attack was scant until This type of behavior is associ- ated with specific C functions like strcpy , strcat , and sprintf , among oth- ers.
A buffer overflow condition would normally cause a segmentation violation to occur. However, this type of behavior can be exploited to gain access to the target system. Al- though we are discussing remote buffer overflow attacks, buffer overflow conditions oc- cur via local programs as well and will be discussed in more detail later.
We have a fixed-length buffer of bytes. Recall from Chapter 3 that we used VRFY to help us identify potential users on the target system by trying to verify their email address.
Let us also assume that sendmail is set user ID SUID to root and running with root privileges, which may or may not be true for every system. Stuffing 1, bytes into the VRFY buffer could cause a denial of service and crash the sendmail dae- mon; however, it is even more dangerous to have the target system execute code of your choosing.
This is exactly how a successful buffer overflow attack works. When the attack is executed, special assembly code known as the egg is sent to the VFRY command as part of the actual string used to overflow the buffer. When the VFRY buffer is overrun, attackers can set the return ad- dress of the offending function, allowing the attackers to alter the flow of the program.
Game over. It is imperative to remember that the assembly code is architecture and operating sys- tem dependent. Our example is very simplistic—it is extremely difficult to create a working egg.
In addition, the friendly Teso folks have created some tools that will automatically generate shellcode. Although it is impossible to design and code a program that is completely free of bugs, there are steps that help minimize buffer overflow conditions. Security is the last item to be addressed and falls by the wayside. Vendors border on being negligent with some of the code that has been released recently.
Many vendors are well aware of such slipshod security coding practices, but do not take the time to address such issues. Their approach is to immunize the programs at compile time to help minimize the impact of buffer overflow. Keep in mind that these mechanisms are not a silver bullet, and users should not be lulled into a false sense of security. This may slow down some programs, but tends to increase the security of each application.
This includes bounds checking each variable, especially environment variables. This includes minimizing the use of SUID root programs where possible.
Even if a buffer overflow attack were executed, users would still have to escalate their privileges to root. Many times programmers are unaware of a potential buffer overflow condition; however, a third party can easily detect such defects.
The OpenBSD camp continually audits their source code and has fixed hundreds of buffer overflow conditions, not to mention many other types of security-related problems. Disable Unused or Dangerous Services We will continue to address this point throughout the chapter. Disable unused or dangerous services if they are not essential to the opera- tion of the UNIX system. Not every service is capable of being wrapped. However, those that are will greatly enhance your security posture.
In addition to wrap- ping each service, consider using kernel-level packet filtering that comes standard with most free UNIX operating systems for example, ipchains or netfilter for Linux and ipf for BSD. Disable Stack Execution Some purists may frown on disabling stack execution in favor of ensuring each program is buffer-overflow free. It has few side effects, however, and pro- tects many systems from some canned exploits.
In Linux there is a no-stack execution patch available for the 2. For Solaris 2. This will prevent many Solaris-related buffer overflows from working. Although the SPARC and Intel application binary interface ABI mandate that the stack has exe- cute permission, most programs can function correctly with stack execution disabled.
By default, stack execution is enabled in Solaris 2. Disabling stack execu- tion will normally log any program that tries to execute code on the stack and tends to thwart most script kiddies. However, experienced attackers are quite capable of writing and distributing code that exploits a buffer overflow condition on a system with stack execution disabled. While people go out of their way to prevent stack-based buffer overflows by dis- abling stack execution, other dangers lie in poorly written code.
Heap-based overflows are based on overrunning memory that has been dynamically allocated by an application. This dif- fers from stack-based overflows, which depend on overflowing a fixed-length buffer. Thus, you should not become lulled into a false sense of security by just disabling stack execution.
Al- though this attack is rather dated, it provides an excellent example of an input validation attack. To reiterate, if you understand how this attack works, your understanding can be applied to many other attacks of the same genre even thought it is an older attack. We will not spend an inordinate amount of time on this subject, as it is covered in additional detail in Chapter Our purpose is to explain what an input validation attack is, and how it may allow attackers to gain access to a UNIX system.
Unfortunately, this program did not properly parse and validate the input it received. In most cases, an unskilled attacker would try to crack the password file and log in to the vulnerable system. Keep in mind that this vulnerability allowed attackers to execute any com- mands with the privileges of the user ID running the web server. PHF was a very popular attack in and , and many sites were compromised as a result of this simple but effective exploit. It is important to understand how the vulnera- bility was exploited so that this concept can be applied to other input validation attacks, as there are dozens of these attacks in the wild.
In UNIX, there are metacharacters that are re- served for special purposes. This is a very common attack and by no means is limited to just PHF. There are many examples of insecure CGI programs that were sup- plied as part of a default web server installation.
Worse, many vulnerable programs are written by web site developers who have little experience in writing secure programs. Unfortunately, these attacks will only continue to proliferate as e-commerce-enabled ap- plications provide additional functionality and increase their complexity. U Input Validation Countermeasure As mentioned earlier, secure coding practices are one of the best preventative security measures, and this concept holds true for input validation attacks.
It is absolutely critical to ensure that programs and scripts accept only data they are supposed to receive and that they disregard everything else. In addition, audit and test all code after completion. I Want My Shell Now that we have discussed the two primary ways remote attackers gain access to a UNIX system, we need to describe several techniques used to obtain shell access. It is im- portant to keep in mind that a primary goal of any attacker is to gain command-line or shell access to the target system.
Traditionally, interactive shell access is achieved by re- motely logging in to a UNIX server via telnet, rlogin, or ssh. Additionally, you can execute commands via rsh, ssh, or rexec without having an interactive login. At this point, you may be wondering what happens if remote login services are turned off or blocked by a firewall.
How can attackers gain shell access to the target system? Good question. Figure illustrates these methods. A simplistic DMZ architecture Suppose that attackers are trying to gain access to a UNIX-based web server that resides behind an industrial-based packet inspection firewall or router. The brand is not impor- tant—what is important is understanding that the firewall is a routing-based firewall and is not proxying any services.
Now assume that the web server is vulnera- ble to an input validation attack such as the PHF attack mentioned earlier. If attackers can successfully exploit the PHF input validation condition, they can execute code on the web server as the user nobody. Executing commands on the target web server is critical, but it is only the first step in gaining interactive shell access.
X is the windowing facility that allows many different programs to share a graphical display. X is extremely robust and allows X-based client programs to display their output to the local X server or to a remote X server running on ports — One of the most useful X clients to attackers is xterm. Xterm is used to start a local command shell when running X. Presto, instant shell access. The attacker now has to- tal control of the system. Since the —ut option was enabled, this activity will not be logged by the system.
Thus, the attackers were able to gain interactive shell access without logging in to any service on the web server. You will also notice the full path of the xterm binary was used. The full path is usually included because the PATH environment variable may not be properly set when the exploit is executed.
Using a fully qualified execution path ensures the web server will find the xterm binary. However, there are always additional methods of gaining access to the tar- get server, such as creating a back channel. We define back channel as a mechanism where the communication channel originates from the target system rather than from the attack- ing system.
There are a few methods that can be used to accomplish this task. A telnet client is typically installed on most UNIX servers, and its use is seldom restricted. Telnet is the perfect choice for a back channel client if xterm is unavailable.
To execute a reverse telnet, we need to enlist the all-power- ful netcat or nc utility. Because we are telneting from the target system, we must enable nc listeners on our own system that will accept our reverse telnet connections.
We must execute the following commands on our system in two separate windows to successfully receive the reverse telnet connections: [tsunami] nc -l -n -v -p 80 listening on [any] 80 [tsunami] nc —l —n —v —p 25 listening on [any] 25 Ensure that no listing services such as HTTPD or sendmail are bound to ports 80 or If a service is already listening, it must be killed via the kill command so that nc can bind to each respective port.
The two nc commands listen on ports 25 and 80 via the —l and —p switches in verbose mode —v , and do not resolve IP addresses into hostnames —n. In line with our example, to initiate a reverse telnet, we must execute the following com- mands on the target server via the PHF exploit. This is where we actually type our commands. The result is a reverse telnet that takes place in two separate windows. Ports 80 and 25 were chosen because they are common services that are typically allowed outbound by most firewalls.
However, any two ports could have been selected, as long as they were allowed outbound by the firewall. As we have said many times, nc is one of the best utilities available, so it is no surprise that it is now part of many default freeware UNIX installs.
Thus, the odds of finding nc on a target server are increasing. For our example, we will assume that a version of nc exists on the target server and has the aforementioned options enabled. Similar to the reverse telnet method outlined earlier, creating a back channel with nc is a two-step process. We must execute the following command to successfully receive the reverse nc back channel. Instant shell access—all with a connection that was originated via the target server. U Back Channel Countermeasure It is very difficult to protect against back channel attacks.
The best prevention is to keep your systems secure so that a back channel attack cannot be executed. This includes dis- abling unnecessary services and applying vendor patches and related work-arounds as soon as possible. Not only will this prevent attackers from firing back an xterm, but it will also aid in preventing local users in escalating their privileges to root via vulnerabilities in the X binaries.
This will allow legitimate users to execute telnet, but will prohibit user IDs that should never need to execute telnet from doing so.
This is particularly true if the firewall is proxy based. It would be difficult, but not impossible, to launch a back channel through a proxy-based firewall that requires some sort of authentication. Additionally, we want to cover some major services that are frequently attacked, and to provide countermeasures to help re- duce the risk of exploitation if these servers are enabled. The attackers now have a list of usernames that can be brute forced.
In many cases, the intruder would gain access to the router passwords and SNMP community strings. The configuration files were used to recover router passwords and SNMP com- munity strings that happened to be identical for every device on the network.
This will prevent attackers from trying to pull back sensitive system-config- uration files. Additionally, consider implementing network- and host-based access-con- trol mechanisms to prevent unauthorized systems from accessing the TFTP server. It al- lows you to upload and download files from remote systems. FTP is often abused to gain access to remote systems or to store illegal files.
Typically the file system is restricted to a particular branch in the directory tree. On occasion, however, an anonymous FTP server will allow the user to traverse the entire directory structure. To compound this situation, many FTP servers have world-writable di- rectories. A world-writable directory combined with anonymous access is a security inci- dent waiting to happen.
Attackers may be able to place an. Many FTP servers are abused by software pirates who store illegal booty in hidden directories. One of the latest FTP vulnerabilities has been discovered in systems running wu-ftpd 2. USER ftp Guest login ok, send your complete e-mail address as password. These vulnerabilities are not discussed in detail here, but are just as deadly. Many sites must allow anonymous access via FTP; however, give special consideration to ensuring the security of the server.
It is critical that you make sure the latest vendor patches are applied to the server, and you eliminate or reduce the number of world-writable directories in use. Sendmail is one of the most maligned programs in use.
It is extensible, highly configurable, and definitely complex. Thus, the odds of finding additional security vulnerabilities are still good.
Recall from Chapter 3, sendmail can be used to identify user accounts via the vrfy and expn commands. There have been scores of sendmail security vulnerabilities discovered over the last ten years, and there are more to come. Many vulnerabilities related to remote buffer overflow conditions and input validation attacks have been identified.
One of the most popular sendmail attacks was the sendmail pipe vulnerability that was present in sendmail 4. Any command after the data would be executed by sendmail with the privileges of bin: helo mail from: rcpt to: bounce data. U Sendmail Countermeasure The best defense for sendmail attacks is to disable sendmail if you are not using it to receive mail over a network.
If you must run sendmail, ensure that you are using the lat- est version with all relevant security patches see www. Other measures include removing the decode aliases from the alias file, as this has proven to be a security hole. Investigate every alias that points to a program rather than to a user account, and ensure that the file permissions of the aliases and other related files do not allow users to make changes.
There are additional utilities that can be used to augment the security of sendmail. Smap is used to accept messages over the net- work in a secure fashion and queues them in a special directory.
Smapd periodically scans this directory and delivers the mail to the respective user by using sendmail or some other program. This effectively breaks the connection between sendmail and untrusted users, as all mail connections are received via smap, rather than directly by sendmail.
Finally, consider using a more secure MTA such as qmail. Qmail is a mod- ern replacement for sendmail, written by Dan Bernstein. One of its main goals is secu- rity, and it has had a solid reputation thus far see www. In addition to the aforementioned issues, sendmail is often misconfigured, allowing spammers to relay junk mail through your sendmail.
As of sendmail version 8. Adoption of an RPC standard is a good thing from an interoperability standpoint.
How- ever, when RPC services were first introduced, there was very little security built in. Thus, Sun and other vendors have tried to patch the existing legacy framework to make it more secure, but it still suffers from a myriad of security-related problems. As discussed in Chapter 3, RPC services register with the portmapper when started. To contact an RPC service, you must query the portmapper to determine which port the required RPC service is listening on. We also discussed how to obtain a listing of running RPC services by using rpcinfo or by using the —n option if the portmapper services were firewalled.
To exacerbate matters, many of the RPC services are ex- tremely complex and run with root privileges. Thus, a successful buffer overflow or input validation attack will lead to direct root access. The current rage in remote RPC buffer overflow attacks relates to rpc. Other dangerous RPC services include rpc. Even if the portmapper is blocked, the attacker may be able to manually scan for the RPC services via the —sR option of nmap , which typically run at a high-numbered port. The aforementioned services are only a few examples of problematic RPC services.
It is necessary to know the system name; in our example the system is named quake. We provide the target IP address of quake, which is We provide the system type 2 , which equates to Solaris 2.
This is critical, as the exploit is tailored to each oper- ating system. If an RPC service is critical to the operation of the server, consider implementing an access control device that only allows authorized systems to contact those RPC ports, which may be very difficult depending on your environment.
Con- sider enabling a non-executable stack if it is supported by your operating system. Secure RPC at- tempts to provide an additional level of authentication based upon public key cryptog- raphy. This xterm is a result of exploiting rpc. The same results would happen if an attacker were to exploit rpc. Thus, interoperability is a big issue. Finally, ensure that all the latest vendor patches have been applied. NFS allows transparent access to files and directories of remote systems as if they were stored locally.
At this point, the red flags should be going up for any system that allows remote access of an exported file system. Many buffer overflow conditions related to mountd, the NFS server, have been discovered. Additionally, NFS relies on RPC services and can be easily fooled into allowing attackers to mount a remote file system.
Most of the security provided by NFS relates to a data object known as a file handle. The file handle is a token that is used to uniquely identify each file and directory on the remote server. If a file handle can be sniffed or guessed, remote attackers could easily access those files on the remote system. The most common type of NFS vulnerability relates to a misconfiguration that ex- ports the file system to everyone.
That is, any remote user can mount the file system with- out authentication. This type of vulnerability is generally a result of laziness or ignorance on the part of the administrator and is extremely common.
Mount is available in most flavors of UNIX, but it is not as flexible as some other tools. The nfsshell package provides a robust client called nfs. Nfs operates like an FTP client and allows easy ma- nipulation of a remote file system. Nfs has many options worth exploring. For security reasons, if you mount a remote file system as root, your UID and GID will map to some- thing other than 0. However, the password file is shadowed so it cannot be used to crack passwords.
Daemon has potential, but bin or UID 2 is a good bet because on many systems the user bin owns the binaries. At this point, all that is necessary is to fire off an xterm or to create a back channel to our system to gain access to the target system.
We create the following script on our system and name it in. The results, a root-owned xterm like the one represented next, will be displayed on our system. Because in. Implement client and user access controls to allow only au- thorized users to access required files. Some options include specifying machine names or netgroups, read-only options, and the ability to disallow the SUID bit. Each NFS imple- mentation is slightly different, so consult the user documentation or related man pages.
Older versions of the portmapper would allow attackers to proxy connections on behalf of the attackers. This would make the request ap- pear as if it were coming from a trusted host and bypass any related access control rules. Finally, apply all vendor-related patches. The major problem with X is that its security model is an all or nothing approach. Once a client is granted access to an X server, pandemonium is allowed. X clients can capture the keystrokes of the console user, kill windows, capture windows for display elsewhere, and even remap the keyboard to issue nefarious com- mands no matter what the user types.
Most problems stem from a weak access control paradigm or pure indolence on the part of the system administrator. The simplest and most popular form of X access control is xhost authentication. This mechanism provides access control by IP address and is the weakest form of X authentication. Attackers can use this seemingly benign weakness to compromise the security of the target server. Xscan will scan an entire subnet looking for an open X server and log all keystrokes to a log file.
Connecting to quake Host quake is running X. Starting keyboard logging of host quake A quick tail of the log file reveals what the user is typing in real time. It is also easy for attackers to view specific windows running on the target systems. Luckily for us, it was. However, you can just comb through the re- sults of xlswins to identify an interesting window.
To actually display the Netscape window on our system, we use the XWatchWin program, as shown in Figure Thus, attackers can send keyboard events to an xterm on the tar- get system as if they were typed locally. If you are in doubt, issue the xhost — command.
Xhost — will not terminate any existing connections; it will only prohibit future connections. If you must allow remote access to your X server, specify each server by IP address.
Keep in mind that any user on that server can connect to your X server and snoop away. These mechanisms provided an additional level of security when connecting to the X server.
If you use xterm or a similar terminal, enable the secure key- board option. This will prohibit any other process from intercepting your keystrokes. Also consider firewalling ports — to prohibit unauthorized users from connecting to your X server ports. Finally, consider using ssh and its tunneling functionality for en- hanced security during your X sessions. As you might imagine, the ubiquity of DNS also lends itself to attack. Thus, a flaw in bind will almost surely result in a remote compromise most times with root privileges.
To put the risk into perspective, a se- curity survey reported that over 50 percent of all DNS servers connected to the Internet are vulnerable to attack.
The risk is real—beware! This buffer overflow al- lows remote attackers to execute any command they wish with root provided on the af- fected server. Most attackers will set up automated tools to try to identify a vulnerable server run- ning named.
To determine if your DNS has this potential vulnerability, you would per- form the following enumeration technique: [tsunami] dig Again, this underscores how important accurately footprinting your environment is.
Other vulnerable versions of named include 8. For this attack to work, the attackers must control a DNS server associated with a valid domain. It is necessary for the attackers to set up a subdomain associated with their do- main on this DNS server. Again, quake is a DNS server that the attackers already control. Since named runs on many UNIX variants, the following architectures are supported by this exploit. You must not run a real DNS server on this system, or the exploit will not be able to bind to port Keep in mind, the whole exploit is predi- cated on having the target name server connect to or query our fake DNS server, which is really the exploit listening on port UDP port So how does an attacker accomplish this?
The attacker simply asks the target DNS server to look up some basic infor- mation via the nslookup command: [quake] nslookup Default Server: localhost. This causes the dns.
Once the target name server connects to tsu- nami, the buffer overflow exploit will be sent to the dns. On many stock installs of UNIX particularly Linux named is fired up dur- ing boot and never used by the system. Second, you should ensure that the version of BIND you are using is current and patched for related security flaws see www.
Third, run named as an unprivileged user. That is, named should fire up with root privi- leges only to bind to port 53 and then drop its privileges during normal operation with the -u option named -u dns -g dns. While these security measures will serve you well, they are not foolproof; thus, it is im- perative to be paranoid about your DNS server security. As mentioned previously, most attackers strive to gain local access via some remote vulnerability.
At the point where attackers have an interactive command shell, they are considered to be local on the system. While it is possible to gain direct root access via a remote vulnerability, often attackers will gain user access first. The degree of difficulty in privilege escalation varies greatly by operating system and depends on the specific configuration of the target system.
Some operating systems do a superlative job of preventing users without root privileges from escalating their access to root, while others do it poorly. A default install of OpenBSD is going to be much more difficult for users to escalate their privileges than a default install of Irix. Of course, the individual configuration has a significant impact on the overall security of the system. The next section of this chapter will focus on escalating user access to privileged or root access. We should note that in most cases attackers will attempt to gain root privileges; however, oftentimes it might not be necessary.
For exam- ple, if attackers are solely interested in gaining access to an Oracle database, the attackers may only need to gain access to the Oracle ID, rather than root. Password cracking is commonly known as an automated dictionary attack. While brute force guessing is considered an active attack, password cracking can be done offline and is passive in nature. However, we felt password cracking is best covered as a local attack.
It differs from brute force guessing as the attackers are not trying to access a service or su to root in order to guess a password. If the encrypted hash matches the hash generated by the password-cracking pro- gram, the password has been successfully cracked.
The process is simple algebra. If you know two out of three items, you can deduce the third. Therefore, if we hash the input by applying the applicable algorithm and the resultant output matches the hash of the target user ID, we know what the original password is. This process is illustrated in Figure How password cracking is accomplished Two of the best programs available to crack passwords are Crack 5. Crack 5. Crack comes with a very comprehensive wordlist that runs the gamut from the un- abridged dictionary to Star Trek terms.
Crack even provides a mechanism that allows a crack session to be distributed across multiple systems. In addition, John handles more types of password hashing algorithms than Crack. Both Crack and John provide a facility to create permutations of each word in their wordlist. By default, each tool has over 2, rules that can be applied to a dictionary list to guess passwords that would seem impossible to crack.
0コメント