The Basics of Web Hacking: Tools and Techniques to Attack the Web (2013)

Chapter 6. Web User Hacking

Chapter Rundown:

■ Attacking other users instead of the server or application

■ Running malicious code with cross-site scripting (XSS)

■ Executing malicious commands with cross-site request forgery (CSRF)

■ Attacks that can’t be stopped: how the Social-Engineer Toolkit (SET) makes you a rock star

Introduction

The target for web hackers has shifted away from the web server and web application and squarely on the web user. Some web user attacks rely on web application vulnerabilities, while other attacks don’t require any existing application vulnerability to be successful, but they all rely on the user unknowingly making a malicious request. Regardless of how the attack is delivered, the payload is executed on the user’s machine as opposed to the web server or web application. This means that the attacker is now directly exploiting web users outside the scope of mitigation strategies for the web server and web application.

There are very few specialized tools for web user hacking; you will continue to use the tools in Burp Suite to create these attacks. You will be introduced to three different attack types that target the web user: cross-site scripting (XSS), cross-site request forgery (CSRF), and technical social engineering.

Technical social engineering is the term we will use for attacks targeting the web user that rely on no standing web server or web application vulnerability. These attacks will always be successful as long as you can coerce the user into some action: clicking a link, opening an image, downloading a PDF file, clicking “OK” (or “Run”) on a browser Java Applet prompt, scanning a QR code with their mobile device, and other related attacks. These technical social engineering attacks are different than what many of us define social engineering as—those actions such as dumpster diving, physical impersonation, phone calls, and other traditional attacks. These new waves of attack simply rely on a web user performing an action when they shouldn’t! And the consequences are dire; technical social engineering attacks provide the same payloads as many of the attacks we’ve already covered.

This chapter will show you how easy it is to gain administrative access on any user’s computer with well-designed and smoothly executed technical social engineering attacks. This type of attack is the ultimate stress test of user awareness training because there is no network firewall or web application that can save unsuspecting users!

Cross-Site Scripting (XSS) Vulnerabilities

Cross-site scripting (XSS) is the more widespread vulnerability in web applications today, but it is often times dismissed as nothing more than a silly JavaScript pop-up window. When you visit a website, your browser develops a trust relationship with that website. Your browser assumes that because you requested the website, it should trust any response from the application. This trust relationship allows images, documents, scripts, and other resources to be accepted from the application by your browser to provide a full-featured web browsing experience. That relationship works without negative consequences 99.9% of the time, but things get dicey when the application is vulnerable to XSS.

If an application is vulnerable to XSS, a hacker can usually create a URL request that includes malicious script and pass that URL to a legitimate user. If the user clicks the link, the request will be sent to the application. The application will return the response to the user that includes the malicious script. This script is generated on the server, sent down to the user’s browser, and is executed in the browser on the client side (user’s browser). This script will execute in the user’s browser because the browser trusts the web application that returned the script. For example, the victim’s browser trusts http://www.auctionsite.com because the user made a request to that URL, but does not trust http://www.l33thacker.net because no user would willingly visit that website. So the script needs to originate from the auction site in order for the user’s browser to trust it. The attacker must find an XSS vulnerability somewhere in the auction site’s web application so when the link is clicked by the user, the script will be sent to the auction site, and then returned in the response (thus the user’s browser will trust it) and it will execute. This allows the hacker to inject malicious script into the application’s response that is sent to the user.

Two of the most well-known exploitation frameworks specific to XSS are the Cross-Site Scripting Framework (XSSF) and the Browser Exploitation Framework (BeEF).

Cross-Site Request Forgery (CSRF) Vulnerabilities

Cross-site request forgery (CSRF) also requires the browser’s trust with the application. It also requires the hacker to craft a malicious request that must be clicked on by an unknowing user, but instead of injecting malicious script like an XSS does, a CSRF attack executes a valid action in the application without the user knowing it. In a nutshell, XSS exploits a user’s trust of the website, while CSRF exploits the website’s trust of the user.

So most functionality that the application supports, such as creating user, changing a password, or deleting website content, can be executed without the user ever realizing it via a CSRF attack. This is why it’s called a request forgery. More good news for hackers is that there is little proof that anything malicious has taken place. The victim user simply made a normal web request to complete an action in the web application. So what if the result was unintentional. From the pure auditing standpoint, it will look like the authenticated user intended to make the request.

XSS Versus CSRF

A lot of people confuse XSS and CSRF because they both require creating a well-formed web application request and interacting with the user to get them to make that request to the application without realizing it. Where they differ is the mechanism in which they use to execute the payload. XSS uses script in the browser, while CSRF uses any request that performs an action (GET or POST) to complete a valid action in the application.

XSS and CSRF can even be used together in chained exploits, such as the world famous Samy worm created by Samy Kamkar that wreaked havoc on MySpace in 2005. It wasn’t actually a worm in the traditional malware sense, but instead a stored XSS and CSRF attack that spread so fast that it was dubbed a worm. The attack carried a payload that would enter “but most of all, Samy is my hero” on a victim’s profile and also make a friend request back to Samy. When other MySpace users viewed any exploited profile, the payload would execute again. Within 1 day, over 1 million MySpace users had been exploited. The text inserted into the profile was done via XSS while the friend request was done via CSRF.

Technical Social Engineering Vulnerabilities

Technical social engineering attacks don’t rely on any existing vulnerability in the web server or web application, but instead prey upon the user directly. This type of attack can’t be stopped by traditional defenses that you have been prescribed for the last decade. Firewalls, intrusion detection, intrusion prevention, web application firewalls, anti-virus software, malware removers, updating operating system patches, and all the other tools are bypassed and rendered completely powerless against technical social engineering attacks. That is some truly scary stuff. If you do everything you’ve been drilled to do to protect yourself, you can still be compromised if you click one link or visit one malicious webpage.

The Social-Engineer Toolkit (SET), created by Dave Kennedy, has a vast array of attack methods and relies on coercing users to perform actions that circumvent all available defense mechanisms. This framework, which will be introduced in greater detail later in the chapter, makes your life as a hacker much easier because it includes hundreds of already developed exploits that you can use against your target users.

Web User Recon

There are three recon efforts that are specific to the web user.

1. There are publically available lists of websites that have had XSS vulnerabilities discovered in them that provide a good starting place for XSS attacks. http://XSSed.org is a running collection of sites that have existing XSS vulnerabilities present and the status of the vulnerability. Sorry to say that some of the websites listed on here acknowledge the vulnerability and choose to not address it at all. XSSed.org is the largest online archive of XSS vulnerable websites and there is a mailing list you can sign up for to receive instant updates of changes to the collection. You can perform a quick search of the archive to see if your target application has already been identified as vulnerable.

2. There is also a component of traditional social engineering involved in web user attacks. You can identify an XSS or CSRF vulnerability and build an epic payload, but you still need a legitimate user to make the malicious request to the web application. This request may be via a link, picture, video, web redirect, or any other way you can con a user into making the request. In order to make this more believable, a good hacker will be well versed in the aspects of social engineering in order to earn the trust of the user. You must decide how to frame your social engineering attack. Is it more believable if you pose as a potential customer? May be as a fellow employee in a large company? May be as a contractor in a government installation? Once you decide your role, you need to make it as believable as possible. This includes identities (name, address, occupation, etc.), email addresses, social network profiles, and all the other components to make you as realistic as possible.

3. There is also benefit to gathering several accounts that you control on the target application. You can use these accounts to interact with employees and other users as part of your social engineering efforts. As you interact with employees, pay special attention to small details such as email format (HTML vs. plain text), email signature details, and how a person structures email messages. What greeting do they use? What verb tense do they use? How do they sign the email? Do they use their first name or just use their signature? These are important details that you can use during impersonation while social engineering. More importantly, you can use these accounts to test your web user attacks. Once you think you have the exact exploit in place, you can send links between two of the accounts you control to see if the payload is delivered as you expect. This setup allows you to play both attacker and victim on the exact application that you are targeting. Interacting with the live application will give you an indication of what filters are in place that you will have to work around. Start easy with the traditional < script></script > attack and progress to more advanced filter evasion techniques until one succeeds. It’s a very stepwise process that you follow until one of the attacks works on your victim account. Once you have it perfected, you can use your social engineering skills to target a real user.

Web User Scanning

When application XSS vulnerabilities are found by scanning the application, you then need to take this information and craft a well-formed exploit against the target. At the heart of any XSS or CSRF attack is a user that is willing to click a link to send a request to the application that includes malicious script. It’s the first time that you’ve dealt with an attack that requires tricking a user. As networks, servers, and applications became more secure through the years, deception played a larger role in a successful exploit. This is a trend that will surely continue in the coming years.

The easy part of an XSS or CSRF vulnerability is identifying it and building a malicious payload. There are entire websites dedicated to forming malicious XSS inputs that circumvent various input filters. Check outhttps://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet.for a really great list of XSS attacks and filter evasion techniques. The hard part of XSS or CSRF is to get a user to click on the malicious link. I will leave it up to you to come up with your best role playing efforts to deceive your target web users, but for more information on social engineering, check out Chris Hadnagy’s work at http://www.social-engineer.org/.

XSS and CSRF vulnerabilities are getting harder to find because of several client-side technologies in the browser that are responsible for key components of the page’s output. JavaScript, ActiveX, Flash, and Silverlight are used more and more to deliver the final rendered page to users. These technologies add layers of complexity to finding XSS and CSRF vulnerabilities because it’s difficult for automated scanners to find these types of vulnerabilities in client-side code. So, in order to have a better chance of identifying these vulnerabilities, you must be able to understand how user input is accepted and processed by the application as well as how it is included in the output of the page. The key is to find pages that accept input and then use that input in some fashion during the output. If you can positively identify such a page, you can then start to probe it for CSRF vulnerabilities. Remember, in order to successfully land a CSRF exploit, you need know all the parameters used by the application, so you can build a malicious request that will execute gracefully. This is the same thinking used when you built malicious SQL statements in code injection attacks.

Web User Exploitation

It’s time to get down and dirty with the tools and techniques necessary to land XSS and CSRF exploits against web users. Web user attack frameworks that were introduced earlier in the chapter will also be investigated in deeper detail.

■ XSS: Both reflected and stored XSS vulnerabilities in DVWA will be completed that lead to compromising of a session identifier by using Burp Suite.

■ Cross-site Request Forgery (CSRF): A CSRF vulnerability in DVWA will be completed to change a user’s password without ever accessing the page with a browser by using Burp Suite.

■ User Attack Frameworks: The Social-Engineer Toolkit (SET) will be introduced to show an attack that requires no standing XSS or CSRF vulnerability.

Cross-Site Scripting (XSS) Attacks

The classic proof-of-concept for XSS is to use a JavaScript alert box that pops up when the code runs in the victim’s browser. This by itself is certainly not malicious, but it does show that inserted JavaScript is returned by the application to the user’s browser. XSS can spell absolute disaster for an application and its users if an attacker formulates a more malicious payload.

XSS attacks are a good training ground for encoding and decoding schemes as they are used heavily in URL parameters and the input validation routines deployed by application defense mechanisms. It’s not critical that you know the exact encoding scheme being used, but it is critical that you know how to encode and decode your malicious input to work around safeguards that have been put in place. There are several encoding schemes that you will come across when dealing with XSS, but some of the most popular are:

■ Base64

■ URL

■ HTML

■ ASCII Hexadecimal

■ UTF-8

■ Long UTF-8

■ Binary

■ UTF-16

■ UTF-7

Most of the hacking suites available today, including Burp Suite, have built-in tools with the functionality to assist with encoding and decoding parameter values.

One factor that you must understand when working with XSS is the same origin policy in a browser, which permits scripts running on pages originating from the trusted site without restriction, but prevents access to different sites. For example, the same origin policy won’t allow a script from www.l33thacker.net to execute if the user didn’t request a www.l33thacker.net page. The same origin policy provides a clear separation between trusted and untrusted sites in the browser to ensure the integrity of the browsing session on the client side. The browser must trust the site that is responding with a script. This is why, as a hacker, you must find an XSS vulnerability in the application that the user trusts in order for malicious script to be executed in the victim’s browser.

XSS Payloads

There are some very damaging payloads that XSS is capable of delivering. Because JavaScript is such a flexible and powerful language, you are only restricted by your imagination when it comes to considering what is possible with XSS. Some of the most popular XSS payloads include:

■ Pop-up alert boxes used mostly for proof-of-concept attacks

■ Hijacking session identifiers

■ Downloading and installing software

■ Redirecting the victim’s browser to a different URL

■ Installing a key logger

■ Invoking a reverse shell back to the attacker

■ Launching client-side attacks (attacks on browsers, for example)

I like to think of XSS as hacker input being allowed to run “all natural” in the victim’s browser because of unworthy safeguards coded into the application. Encoding and decoding values play a large part of XSS attacks, so you must have a basic understanding of how to identify and use encoded values. An intercepting proxy will also be a useful tool during XSS as you work to evade the input filters in place on the web application designed to prevent XSS.

Reflected XSS Attacks

The actual steps involving the hacker, victim, and web application during a reflected XSS attack are introduced in Figure 6.1.

FIGURE 6.1 The steps in a reflected XSS attack.

There are two huge requirements that must be true in order for a reflected XSS attack, as introduced in Figure 6.1, to actually work.

1. The victim must be willing to perform some action, such as clicking a link, performing a search, or some other application-specific functionality.

2. The victim must be logged into the vulnerable application at the time they click the malicious link.

It is pretty unlikely that both of these requirements would actually be true. Most users aren’t going to be logged into the application at the time they receive the malicious link. Furthermore, asking a user to log in first and then come back and click the link is a huge red flag to a user of something malicious. But that is why a hacker will send the malicious link to thousands of potential victims hoping that a handful, or just one, of them actually meets these two requirements.

You will be completing the XSS reflected exercise in DVWA to illustrate how to successfully execute a reflected XSS attack. Once you go to the XSS reflected page, you will see it’s just a textbox that allows you to type your name. If you provide Keith as your name, the page will simply respond with Hello Keith as the rendered output. This is a clear indication that the user’s input is being used directly in the output of the application. Alarm bells should be going off in your head at this realization! The only trick is to figure out what, if any, encoding, input validation, and output encoding the application is providing as a safeguard against XSS attacks that you will need to circumvent. Let’s start by entering the syntax of the classic JavaScript pop-up alert box directly in the name textbox as a proof-of-concept attack.

After you hit the Submit button to send in this malicious request, the application provides a response that proves no XSS safeguards are in place. First, you will notice the Hello that is preappended to the user input; the application is expecting only a name to be entered. The application also sends back the malicious JavaScript that we provided and it is rendered in our browser as shown in Figure 6.2.

FIGURE 6.2 Successful reflected XSS proof-of-concept attack.

The concept of reflected XSS is “whoever clicks it, gets it” as it’s a one-time attack and whoever clicks the malicious link is going to have the script execute in his/her browser. You were the user that submitted the request that included the malicious script, so it’s your browser that the script executes in. Your browser trusts the DVWA page because you requested it, so the script included in the response is allowed to execute. You are playing nicely within the specified bounds of the same origin policy here.

Intercepting The Server Response

If XSS was really that easy in current web applications, we would all be in big trouble. In order to become a more legitimate avenue of attack, you really need to understand how the application is processing user’s input so that you can work to circumvent any safeguards. Some of the preventative measures will take place on the client side before the request is sent onto the application and others will take place before the response is rendered in your browser. You can inspect both the request after it leaves your browser and the response before it returns to your browser by using an intercepting proxy. By default, Burp Proxy does not intercept application responses, but you can enable that feature under the Options tab under the Proxy as shown in Figure 6.3.

FIGURE 6.3 Enabling interception of application responses in Burp Proxy.

Now you can review what the web request looks like before it reaches the application as well as what the response looks like before it renders in your browser. When you intercept the request in a proxy, you see the small formatting changes that have been made to the malicious script entered as the NAME parameter as shown in Figure 6.4.

FIGURE 6.4 Intercepting Reflected XSS request in DVWA.

This shows that the script input has been changed a little for formatting reasons, but we already know that this will result in a successful XSS attack. We can also inspect the application’s response in Burp after forwarding the request onto the application as shown in Figure 6.5.

FIGURE 6.5 Intercepting Reflected XSS response in DVWA.

The application’s response shows that every character that is not plaintext is encoded. For example, the leading bracket in our script tag < is encoded as %3C and the closing bracket > is encoded as %3E. If you’re unfamiliar that this is URL encoding, you can use the Decoder tool in Burp Suite. Once you forward this response onto the browser, you can inspect the raw HTML that is about to rendering in the browser as shown in Figure 6.6.

FIGURE 6.6 Raw HTML that includes XSS attack.

This is the most obvious sign that we have successfully landed this XSS exploit. The actual HTML source code that was sent to the browser from the application includes our XSS attack in the source code! You can see the Hello that is preappended to the entered name and instead of a normal user’s name, our XSS attack has been inserted. The only thing left is to forward this response one more time so it renders in the browser and the JRod was here! alert will pop up again.

Encoding XSS Payloads

Working with encoded values is a great way to figure out what is allowed by the application and what it means to the output of the application’s response. You can use Decoder in Burp Suite to URL encode the entire XSS script as shown in Figure 6.7.

FIGURE 6.7 URL encoding the “JRod” XSS attack string.

The top half of the Decoder screen is the input window where you can type directly or paste input into it. You then use the drop-down menu on the right side of the screen to select what type of encoding you’d like to use. The output is shown in the bottom of the screen. You can switch between different encoding schemes to see the resulting output which can be copied directly from this lower window. If you’d like to know the application’s response to an entirely URL-encoded value for the name parameter, prime the pump with a normal user name. Once you’ve intercepted the outbound request, you can paste this URL-encoded XSS attack into the NAME parameter and forward it onto the application as shown in Figure 6.8.

FIGURE 6.8 Using URL-encoded XSS attack in Burp Proxy.

The resulting pop-up box proves that the application accepts input that is entirely URL encoded. This takes all the guesswork out of our attack; we can simply URL encode every request that we want to make to the application and we know it will be accepted as we intended.

XSS In URL Address Bar

Another attack vector that you need to consider is directly using the URL address bar to send in a XSS attack. When a normal name is used for input (Halverto in this example) and the application successfully displays the name back in the browser, you will notice this URL is built:

127.0.0.1/vulnerabilities/xss_r/?name=Halverto#

You can use this knowledge to try your URL-encoded XSS attack directly in the URL address bar. All you have to do is replace Halverto with your attack string between the equal sign and the pound sign as shown here:

127.0.0.1/vulnerabilities/xss_r/?name=%3c%73%63%72%69%70%74%3e%61%6c%65%72%74%28%22%4a%52%6f

%64%20%77%61%73%20%68%65%72%65%21%22%29%3c%2f%73%63%72%69%70%74%3e#

When the application receives this input, the same JavaScript pop-up alert box is executed and the URL now includes the attack string that was allowed to run as shown in Figure 6.9.

FIGURE 6.9 URL details of reflected XSS attack.

This is to be expected now that we understand how DVWA accepts and processes user input. The one item worth noting in the URL is the %2f immediately before closing the script text. This %2f is the URL-encoded version for a forward slash, which is used for directories in the URL.

XSS Attacks On Session Identifiers

These pop-up alerts are cute and fun, but what can you really do with this vulnerability? The attack that will surely get some attention is the ability to steal a current session from the user. You can use the document.cookie method in a XSS attack to retrieve and display the session identifier of the browser that allows this script to execute.

The example in Figure 6.10 uses the same alert pop-up, but you could instead use JavaScript to open a connection back to a server you control and have the cookie sent there. You could then use that session identifier to masquerade as the victim user and send malicious requests to the application.

FIGURE 6.10 Retrieving a session identifier with a reflected XSS attack.

This type of attack is much more worth your time than trying to crack how session identifiers are generated!

Stored XSS Attacks

The interactions among user, attacker, and application during a stored XSS attack are much different than reflected XSS as shown in Figure 6.11.

FIGURE 6.11 The steps in a stored XSS attack.

The first thing to notice is that the attacker only interacts with the application and never has to social engineer the user in any way for the XSS attack to execute. There are three properties of stored XSS that make it much more devastating than reflected XSS.

1. The hacker does not have to entice the user to click a link because the XSS attack is stored in the application page already.

2. The user is guaranteed to already be authenticated at the time the attack occurs if the vulnerable page is only accessible by authenticated users (such as a private user forum or message board).

3. The XSS attack will execute against every user that visits the vulnerable page. It’s not restricted to a one-time attack, but rather will execute every time the page is requested.

You will use the XSS stored exercise in DVWA to successfully land a stored XSS exploit. This page is a guest book where users can post a name and a message that are available for viewing by all visitors to the page. The name and message for all of the submitted guest book entries are stored in a database that is retrieved every time somebody requests the page. This ensures that the most recent guest book entries are always displayed, but it also provides a nice place to plant a stored XSS attack. The same attacks introduced in the reflected XSS section are also appropriate here, so feel free to use the pop-up alert box and the document.cookie attack on this stored XSS vulnerable page.

Persistence Of Stored XSS

Without proper safeguards in place, you can plant an XSS attack that is stored in the database and retrieved by every visitor to the guest book as shown in Figures 6.12 (input) and 6.13 (output). This means that malicious script will execute in the browser of multiple users.

FIGURE 6.12 Submitting a stored XSS attack in DVWA.

FIGURE 6.13 Output of stored XSS attack in DVWA.

There will be no indication of the stored attacks other than the name provided and the actual JavaScript payload. The attack string won’t show in the message body of the guest book entry as shown in Keith’s entry in Figure 6.14.

Alert

Every time you visit the XSS stored page all of the attacks will execute because the attacks are stored in the database. If that annoys you, you can use the Create / Reset Database button on the DVWA Setup page to cleanse the database of the XSS attacks.

FIGURE 6.14 The guest book entries including a stored XSS attack.

The sky is the limit with stored XSS vulnerabilities. Although they are not as widespread as reflected XSS vulnerabilities, they are absolutely devastating to web application users.

Cross-Site Request Forgery (CSRF) Attacks

In order for a CSRF attack to be successful, all of the parameter of the request must be known and provided with valid values by the attacker in the malicious URL. Look at the DVWA’s CSRF exercise to see how URL parameters can be leveraged in a CSRF attack. This page provides the functionality to change the password of your user as long as both values match each other. The password for the admin user will be changed. When you enter laresFTW as the password, the following URL is built and sent to the application and you receive the Password Changed confirmation once the request is acted on.

http://127.0.0.1/vulnerabilities/csrf/?password_new=laresFTW&password _conf=laresFTW&Change=Change#

The application is using URL parameters to pass values into the application for processing. It’s obvious that the password_new and password_conf parameters are the most interesting here. You can simply go to the URL, change these values, and reload the page. The password will now be changed to the new values! Imagine the fun you can have if you get somebody to click on a link like this one; you have effectively just set a victim’s password to whatever you specify in the URL parameters without him or her even realizing it.

This attack would require that the user be currently logged into the application in order for it to successfully execute. But this requirement is easily met by posting this link (in a shortened version to mask its intention perhaps) on a forum or message board that requires authentication.

Alert

You actually just changed the password for your admin user for DVWA. If you have trouble logging into DVWA, that’s the reason! When in doubt, you can log in with any of the user’s credentials that we discovered in earlier chapters and change the admin password via this CSRF exercise or the Create / Reset Database button on the DVWA Setup page.

User Attack Frameworks

The most popular trend in hacking is the creation of frameworks to allow the masses to make use of already developed exploits. Metasploit is the poster child for this; it is without a doubt the #1 exploitation framework used today. A big shout-out to HD Moore and his entire team for creating Metasploit and, more importantly, continuing to support the free version of the framework. Not only have others created specialty frameworks, but these creators also make it a point to allow interaction with Metasploit in their frameworks as much as possible. There’s no greater sign of respect than other hackers making sure their tools play nicely with yours! There are a few other exploitation frameworks that are specific to web hacking that deserve your attention.

Social-Engineer Toolkit (SET)

The Social-Engineer Toolkit (SET), created by Dave Kennedy, is the world’s premier framework to leverage social engineering attacks to totally compromise systems. The name of the framework actually doesn’t do it justice, as SET is much more than a spoofed email or malicious PDF creator. It includes some very advanced functionality that allows exploiting fully patched computers. It doesn’t matter what operating system, browser, software, or firewall is installed, SET’s attacks bypass all of those safeguards. It’s truly an epic attacking framework that even ties directly into the Metasploit attack framework. SET is very easy to use and is included in the latest version of BackTrack. You can get to the SET directory by executing the cd/pentest/exploits/set command in a terminal window.

You can then run SET by issuing the ./set command. Once the framework loads, you will be prompted to agree to the terms of service (select “y” for “yes”) and to allow automatic updates from the GIT repository (select “1” to allow updates). Once the update is complete, the main SET menu will appear as shown in Figure 6.15.

FIGURE 6.15 Welcome menu for the Social-Engineer Toolkit (SET).

You can download a new version of SET to any Linux distribution by issuing the following terminal command to check out the latest version.

git clone https://github.com/trustedsec/social-engineer-toolkit/ set

When you select option #1 to get into the social engineering attacks, you have several attack vectors available to choose from, but you should focus on #2 website attack vectors for now. There are actually six different attack vectors available specific to websites that you can select from, and this list grows with every new release of SET!

■ The Java Applet Attack method will spoof a Java Certificate and deliver a Metasploit-based payload. Uses a customized java applet created by Thomas Werth to deliver the payload.

■ The Metasploit Browser Exploit method will utilize select Metasploit browser exploits through an iFrame and deliver a Metasploit payload.

■ The Credential Harvester method will utilize web cloning of a web site that has a username and password field and harvest all the information posted to the website.

■ The TabNabbing method will wait for a user to move to a different tab in their browser, and then refresh the page to something different.

■ The Man Left in the Middle Attack method was introduced by Kos and utilizes the HTTP REFERER header in order to intercept fields and harvest data from them. You need to have an already vulnerable site and incorporate < script src="http://YOURIP/">. This could either be from a compromised site or through XSS.

■ The Web-Jacking Attack method was introduced by white_sheep, Emgent, and the Back|Track team. This method utilizes iFrame replacements to make the highlighted URL link to appear legitimate however when clicked a window pops up then is replaced with the malicious link.

■ You can edit the link replacement settings in the set_config if it’s too slow or fast.

There is also the ability to use several of these attack vectors together with the #7 Multi-Attack Web method. This allows you to chain several of these methods together into a single attack. For example, you could use the java applet attack to land a shell on the victim’s machine coupled with the credential harvester to steal the authentication credentials from this same victim when they attempt to login into the spoofed site you’ve created.

In order for SET to work properly, you have to set the IP address where SET will run its web server for the cloned website. This would be the IP address that would be passed to the victim machine. Because we are already running Apache for our DVWA environment, we can’t run SET at the same time without disabling Apache. So stopping the Apache service is one option. You can also just start up another VM and run SET on that (which will be done for this example). This two VM approach will give us a more realistic hacker v. victim feeling to these web user attack exercises. This is exactly the same thinking that you could have executed the web server hacking steps in Chapter 2.

You have already drilled down into the website attack vectors menu in SET by following the steps above, so now it’s time to configure a viable attack. Assume the victim machine is at IP address 172.16.69.135 and the attacker machine is at IP address 172.16.69.134. An outline of setting up a Java Applet attack via SET’s menu commands can be completed with the following steps:

1. Choose 1 for Java Applet Attack Method

2. Choose 2 for Site Cloner

3. Choose “n” for “no” to “Are you suing NAT/Port Forwarding [yes|no]”

4. Provide https://gmail.com for the site to clone

5. Choose 11 for the SE Toolkit Interactive Shell (this is a custom shell similar to Metasploit’s Meterpreter)

6. Provide 443 as the listener port

If you successfully complete these steps, you will receive a confirmation message that says “The Social-Engineer Toolkit (SET) is listening on 0.0.0.0:443”. The work from the attacker perspective is done!

All you need to do now is convince your victim to visit the SET web server running on 172.16.69.134. This is where the pure social engineering that we discussed earlier comes into play such as email link, instant message, forum post, Facebook post, Twitter, and countless other ways to deliver it.

From the attacker’s perspective, when they visit the IP address (which could also be a snazzy URL if you want to host that) they are met with a website that looks just like Gmail and a prompt to allow a Java Applet to be installed and ran. Once the victim has visited the fake Gmail site and accepted the applet to be installed, a session is opened on the victim’s machine and sent back to the attacker. You will see notification in your SET terminal and you can issue the sessions -l command (that’s a lowercase L) to see the listing. You can interact with the first session by issuing the sessions -i 1 command (that’s a lowercase I and the #1). You now have a shell prompt on that victim machine and have effectively bypassed any and all defensive countermeasures that may have been installed on it.

And that’s it! It’s that easy! You should dig into more of SET at the official homepage at http://www.trustedsec.com/downloads/social-engineer-toolkit/. One more tip to remember when using SET or attempting any social engineering attack: It’s pretty much a one-time deal. You don’t get to re-send the email or get a re-do with the potential victim. I attended a SET training with Dave Kennedy and we all got a laugh at this notion when we referenced Eminem’s lyrics from Lose Yourself: “You only get one shot, do not miss your chance to blow. This opportunity comes once in a lifetime, yo…”

Other Notable User Attack Frameworks

While SET is the king of the hill when it comes to web user attack frameworks, it’s not completely alone when it comes to exploiting these types of vulnerabilities. There are three other frameworks that you should look into as you become more comfortable with these types of attacks and social engineering in general.

■ The Spear Phishing Toolkit (SPT) is an easy to use phishing email framework that can be downloaded, configured, and completely running in about 15 min. SPT has modules that you use to launch phishing campaigns against target victims and provides an administrative dashboard to track progress. It includes tons of templates to use during your campaigns so you don’t have to create everything from scratch—unless you want to! Once SPT is up and running, it’s very easy to manage and track your campaigns to see what percentage of target users actually fell victim to your phishing campaign. More information on SPT can be found at http://www.sptoolkit.com/project/.

■ The Browser Exploitation Project (BeEFr) relies on vulnerabilities that are outside the scope of this book, specifically the browser. As the hacker, you set up a BeEF server that includes a command console that you can monitor for incoming connections and dictate attacks to against your hooked victims. Once a vulnerable browser makes contact with the BeEF server, by way of a social engineering-based attack such as a malicious link, the browser becomes hooked. BeEF hooks allow you to probe this browser for any valid exploitation possibilities and use the browser as a toehold into the victim’s machine. Some of the payloads available in BeEF include keystroke logging, clipboard theft, and integration with Metasploit modules. More information on BeEF can be found athttp://beefproject.com/.

■ The Cross-site Scripting Framework (XSSF) also targets browsers, but uses XSS vulnerabilities to wage war on the victim. XSSF creates a communication channel with the targeted browser from an XSS vulnerability in order to perform further attacks. It has the same hooking feel that BeEF uses and is designed to natively use existing Metasploit exploits and was actually built on top of the Metasploit framework. XSSF can be loaded with Metasploit by issuing the load xssf command from the msf> prompt. This is a huge plus in its favor. Users are free to select existing modules to fire at the victim browsers. More information on XSSF can be found at https://code.google.com/p/xssf/.