Password Attacks 272Remote Password Attacks 272Local Password Attacks 277Dictionary Attacks 277
Network Packet Sniffing 284
Social Engineering 290Baiting 291Phishing 291Pretexting 292
Manipulating Log Data 292User Login 293Application Logs 297
Hiding Files 299Hiding Files in Plain Sight 299Hiding Files Using the File System 300Hiding Files in Windows 304
Password Attacks Network Packet Sniffing Social Engineering Manipulating Log Data Hiding Files
CHAPTER 10 Privilege Escalation272
INTRODUCTIONIn this chapter, we are going to discuss those things that allow us to access data on a system above our given privileges. We can perform this a few different ways, including remote or local password attacks and social engineering. We are also going to discuss how we can keep those privileges through manipula-tion of log data and hiding files.
PASSWORD ATTACKSAccessing a user account, other than your own, is a great way to elevate privi-leges. Mostly remote access to systems is limited to single-factor authentica-tion, specifically a password. If we can grab password hashes and identify the corresponding password for the hash, we can simply log into the system with a username/password combination.
We have two different types of password attacks to discussremote and local. In the case of a remote attack, we are attempting to log on to a system across the network. In a local password attack, we are attempting to crack a hash. Lets start with remote attacks.
Remote Password AttacksDuring our information gathering and vulnerability identification, we have been collecting potential usernames along the way. In this phase of our pen-etration test, we want to attempt to access systems as authorized users; one way of doing this is to conduct a remote brute-force attack against systems with applications that permit remote access.
In Chapter 8, we examined how to identify those applications with usernames that have weak passwords. In these cases, we can simply attack the system with little effort, since we only query two to three passwords per username. In this chapter, we will discuss a more involved method of finding out passwords to usernames, through the use of dictionary files. Dictionary attacks are much more time consuming, and conducting a dictionary attack remotely will gener-ate a lot of noise on the network. In fact, they generate so much noise that we should typically relegate a remote dictionary attack to the end of a pentest proj-ect. In fact, sometimes a remote brute-force password attack is used to identify network incident responsewe can find out if our client actually sees the activ-ity and responds accordingly.
The downside of a brute-force attack across the network is that when we have to use this type of attack, we most likely exhausted other options to access a system. We can reduce some of the overall time spent conducting a remote
Password Attacks 273
password attack by trimming our usernames that we want to test; we can restrict login attempts to usernames that we know are on a system (as seen in Figure 14 of Chapter 8 or simply those that we suspect will have the most reaching access across the network such as administrator or root). We have looked at the Medusa tool beforein this chapter, we will look at another tool titled Hydra.
Before we begin, we need to create and gather dictionaries. Over time, as new passwords are cracked (through local attacks on captured hashes discussed later in this chapter), we can add to any set of dictionaries we collect from the Internet. In addition, we can create additional dictionaries according to our current target. As an example, if we were conducting an attack against a medi-cal tool manufacturer, we might visit medical Web sites and grab words related to that industry to include in a password dictionary. The ISSAF has some addi-tional suggestions as to what types of password dictionary files to include in attacks, such as:
Sports names and terminology Public figures Formatted and unformatted dates starting from 60 years ago Small international and medium local dictionaries
We will also want to create different types of dictionaries, such as those spe-cific to the WPA protocol, which require a minimum of eight characters. This will save time, which is something we are always short of during our pentests.
To begin our discussion of remote brute-force password attacks, we will take a look at the De-ICE 1.100 LiveCD. As part of our information gathering phase, we would have navigated to the systems Web page and examined the contents, as seen in Figure 10.1, using the w3m text-based Web browser.
Toward the bottom of the page, we see a list of different e-mail addresses. In our attempt to collect potential usernames, we can use these e-mails to build a list. However, we cannot assume that the usernames on the target system equate directly to those seen in Figure 10.1, so we need to add variations to our list as well. We may be able to avoid adding variations if we already know the pattern used within an organization to assign usernames to employees; how-ever, in this case, we do not know for sure exactly how the login names look. In Figure 10.2, we have a partial list of potential login names.
You will notice that I only selected the names of administrators listed on the Web page listed in Figure 10.1. Under normal circumstances, I would include all the names, including those of the financial and engineering employees. I am using a smaller subset just as an example and to save time.
CHAPTER 10 Privilege Escalation274
In Figure 10.3, we conduct an Nmap scan against the target system (which arguably would have been done before we hit the Web site, but we need to select a service to brute force, so lets take a look now). We see that there are a couple of options for us to attempt to log in remotely; for sake of brevity, we will select Secure Shell (SSH).
In Figure 10.4, we attempt to conduct an attack similar to those seen in Figure 5 of Chapter 8 through the use of the -e option, which checks for empty pass-words (-n) or passwords that are the same as the username itself (-s).
In Figure 10.4, we were successful and see that the password matches the username. If we attempt to log into the system using bbanter/bbanter as cre-dentials, we will be successful. In this particular case, the user bbanter has very limited access to the system, and if we exploit enough, we find nothing useful on the system. To find anything of value, we need to access the system as another userperhaps, the Sr. System Administrator Adam Adams. Now that we know that the pattern for the usernames on the target system is first initial last name, we can fine-tune our attack to target the aadams user.
Up to this point, we havent done anything new; what we do from this point onward is what this section of the chapter is about. With that in mind, we can now begin our discussion of the use of dictionaries in remote password brute-force attacks.
FIGURE 10.1Web page for De-ICE 1.100.
FIGURE 10.2Potential usernames for the De-ICE 1.100 LiveCD.
Password Attacks 275
In Figure 10.5 is a list of downloadable dictionaries collected on www.
SkullSecurity.org Web site (as viewed through the w3m text-based Web browser). These will provide a solid beginning group of dictionaries to use during our brute-force attacks; however, as mentioned before, we will need to develop our own over time.
Although not shown in the list above, we will be using the rockyou.txt file available at SkullSecurity.org. In Figure 10.6, we return to hydra and conduct an attack against the aadams user (-l), using the rockyou.txt dictionary (-P), targeting the SSH service on the 192.168.1.100 system.
FIGURE 10.3Nmap results of De-ICE 1.100.
FIGURE 10.4Weak password for username bbanter.
CHAPTER 10 Privilege Escalation276
To be honest, things rarely go this well using brute-force attacks. The time
it took to complete the test was less than 4 min. Larger username lists and dictionaries will increase that time dramatically. However, if we are lucky and identify a username/password combination, we can then proceed to access the system with elevated privileges!
FIGURE 10.5Some of the dictionaries on SkullSecurity.org.
FIGURE 10.6Successful dictionary attack.
Password Attacks 277
Local Password AttacksA local password attack is dependent on our ability to capture hashes from a compromised system. How we obtain the hashes varies, but in the end, this section of the chapter expects us to have captured a hash beforehand. In Figure 10.7, we see a snippet of the /etc/shadow file on the metasploit system.
We will collect these to conduct a local brute-force attack, and remove those usernames that contain no login hashes as seen in Figure 10.8.
The program we will use for this is John the Ripper (JTR). In Figure 10.9, we launch JTR against the hash file using the rockyou.txt dictionary we down-loaded earlier. We can see that the tool did not identify that the msfadmin username has a password of msfadmin during the scan.
In Figure 10.10, we see that the rockyou.txt file does not contain the word msfadmin in its list, which is the reason JTR was not able to find the pass-word; this highlights an important fact in that our ability to crack passwords using dictionaries is constrained by the values in the dictionary itself. Lets take another look at this shortcoming, using special characters.
Dictionary AttacksIn Figure 10.11, we see two different SHA-1 hashes that were computed for a single word (which should be theoretically impossible, but we will get to that soon). When we run JTR against the two hashes, we see that JTR was able to properly identify one of them correctly, but not the other. If the assertion that both hashes are for the same word is true, and yet they are distinctly different, something must have happened during the encryption process that changed our word before presenting us with the encrypted value.
At this point, we can see that the word we cracked was German in nature; more importantly, it contained non-ASCII characters, specifically a Latin Small Letter U with diaeresis. This translates to Unicode value U+00FC and seems to have been retained in the user2 encryption process since JTR was able to crack the hash. The mystery seems to be as to the changes that occurred with
Account LockoutSomething we need to be careful about is account lockouts. In many situations, we will be deal-ing with an internal network that permits only so many login attempts before locking out the user. When we conduct a brute-force attack using dictionaries, we will certainly lock out users quickly. Before beginning, it is advisable to discuss this type of attack with the client. Another option is to use the same (weak) password against multiple user accounts insteadthis can effectively avoid lockout problems.
TOOLS AND TRAPS
CHAPTER 10 Privilege Escalation278
the user1 password. To make sense of the discrepancy between the two hashes
FIGURE 10.8Hashes from Metasploitable.
FIGURE 10.7List of the /etc/shadow file on Metasploitable.
Password Attacks 279
that had used the same word for their input, let's examine what Unicode is and
The Unicode Consortium has developed a universal character set, which cov-ers all the characters for all the writing systems of the world (Unicode.org). With regards to programming, the UTF-32 protocol requires 4 bytes for each character, which makes it easier to manage storage; however, other versions of UTF use different byte sizes, making storage and transmission of Unicode somewhat problematic (or at least requires some forethought). Because of byte size and the fact Unicode is not byte oriented (excluding UTF-8), pro-grammers have sometimes opted to convert Unicode into something easier to manage; it seems the most common encoding schema used to convert
FIGURE 10.9John the Ripper targeting Metasploitable hashes.
FIGURE 10.10Search for msfadmin in dictionary.
FIGURE 10.11SHA-1 hashes.
CHAPTER 10 Privilege Escalation280
Unicode over the years is base64, which consists of the character set a-z, A-Z, and 0-9 (plus two additional characters). Base64 is used in numerous appli-cations already, and many different routines exist to convert Unicode into base64.
So, what happens to our Unicode German word if converted into base64 and then back into plaintext? The word is transformed into Glckwunschthe has been replaced with . Once we understand that the word has been seriously mangled, we realize that the only way for JTR to convert this value for us would be through brute force, and considering the string length (16 characters), we may never have enough time to dedicate to its even-tual discovery. What is worse is that Glckwunsch is a fairly common word in German, which could easily be defined as low-hanging fruit, assuming that we used a medium-sized German dictionary to use as part of our initial crack attempt. To avoid missing such an easy word, we have two alternativesidentify those applications that convert Unicode into base64 or expand our wordlist to include base64-translated characters.
So, how do we identify applications that convert Unicode into base64? Unfortunately, there are no reliable methods to do so. The only clue we can rely on is if base64 has had to add fillers, which can be distinguished by the equal sign (=). As an example, the word Glckwunsch encoded into base64 is R2wmIzI1Mjtja3d1bnNjaA== (without quotes). The equal signs are used to pad the actual base64 value until the string is a multiple of 4. However, this assumes we can see the base64 value, before it is placed through the encryption algorithm. In the example seen in Figure 10.11, there is no way to tell if either of the hashes had base64 or Unicode characters processed through the SHA-1 algorithm. This leaves us with the unfortunate duty of transposing Unicode characters into base64 equivalents in our wordlists.
In Figure 10.12, we can see a wordlist only containing the German word Glckwunsch with both the Unicode version and the base64->text version. Once we run JTR against our original SHA-1 hashes using the new dictionary, we see that we were able to successfully crack both hashes.
What does this mean in a real-world penetration test? If our target system has users on it that use a language with special characters, then we may be miss-ing passwords that should be easily cracked, unless we modify our local ( language-specific to the users) wordlist. The good news is that we only have to make the additions once, assuming we retain our dictionaries over time. The bad news is we have to break out our scripting skills to make this task easier.
Lets return to our earlier example of using a dictionary attack against a target hash, but this time lets modify our dictionary a bit. One of the cool features of JTR is that we can modif...