Chapter 6 - Web-based Hacking: Servers and Applications

cross-site scripting (XSS)

the basics of this attack revolve around website design, dynamic content, and invalidated input data. Usually when a web form pops up, the user inputs something, and then some script dynamically changes the appearance or behavior of the website based on what has been entered. XSS occurs when the bad guys take advantage of that scripting (JavaScript, for instance) and have it perform something other than the intended response. For example, suppose instead of entering what you're supposed to enter in a form field, you enter an actual script. The server then does what it's supposed to—it processes the code sent from an authorized user. You'll need to know what XSS is and what you can do with it. Also, be able to recognize that a URL such as the following is an indicator of an XSS attempt: http://IPADDRESS/";!--"<XSS>=&{()}. Instead of the URL passing to an existing page/element internally, it passes to the script behind the forward slash. XSS can be used to perform all kinds of badness on a target server. Can you bring a target down with a good old DoS attack? Why not? Can I send an XSS attack via e-mail? Of course!

Internet Engineering Task Force (IETF)

"The goal of the IETF is to make the Internet work better." IETF creates engineering documents to help make the Internet work better from an engineering point of view. The IETF's official documents are published free of charge as Requests For Comments (RFCs).

shell injection

where the attacker attempts to gain shell access using Java or other functions

file injection

where the attacker injects a pointer in the web form input to an exploit hosted on a remote site

command injection

where the attacker injects commands into the form fields instead of the expected test entry

web cache poisoning

A web cache is a just storage space that sits between a web server and a client (like a web browser or a mobile app). It waits for network requests to come in and saves copies of the responses. Why? Because the entire idea of the cache is to speed up responses to future requests. If you ask the server for something and then later I ask for the same thing, it's faster to pull the cache response for me than to re-create all the processing to answer the same question. In short, caches speed up delivery, make web services appear more responsive, and theoretically at least, help reduce network traffic. But can you see where that could be problematic from a security perspective? Suppose an attacker clears the cache on a target, then replaces it with something he wants in there. The cache response can then wreck all sorts of havoc among visitors to the server. To successfully carry out the attack, a bad guy must first find vulnerable service code (allowing him to fill the HTTP header field with multiple headers). He then forces the cache server to flush its actual cache content and sends a specially crafted request designed to be stored in cache. He then sends a second request, forcing the response to be the previously injected content from earlier.

cookie

A cookie is a small text-based file that is stored on your system for use by the web server the next time you log in. It can contain information such as authentication details, site preferences, shopping cart contents, and session details. Cookies are sent in the header of an HTTP response from a web server and may or may not have an expiration date. The original intent was to provide a continuous, stable web view for customers and to make things easier for return surfers. However, they can be manipulated to use as spyware (cookies can be used to track computer activity), change pricing options, and even authenticate to a server. For example, an entry in a cookie reading "ADMIN=no" can be changed to "ADMIN=yes," thus providing administrative access to site controls.

Cross-Site Request Forgery (CSRF or XSRF)

A cross-site request forgery (CSRF) is a fun attack that forces an end user to execute unwanted actions on a web application in which they're currently authenticated. OWASP has such a cool explanation of this attack from their free documentation, so I thought we'd start there: CSRF tricks the victim into submitting a malicious request. It inherits the identity and privileges of the victim to perform an undesired function on the victim's behalf. For most sites, browser requests automatically include any credentials associated with the site, such as the user's session cookie, IP address, Windows domain credentials, and so forth. Therefore, if the user is currently authenticated to the site, the site will have no way to distinguish between the forged request sent by the victim and a legitimate request sent by the victim. If the victim is a normal user, a successful CSRF attack can force the user to perform state changing requests like transferring funds, changing their email address, and so forth. If the victim is an administrative account, CSRF can compromise the entire web application. Imagine if you added a little social engineering to the mix. Just send a link via e-mail or chat, and—boom!—you can now get the users of a web application into executing whatever actions you choose. If you're a security-minded person and are wondering what you can do about this, relax—the answer is right here. CSRF attacks can be mitigated by configuring a web server to send random challenge tokens. If every user request includes the challenge token, it becomes easy to spot illegitimate requests not initiated by the user.

XML External Entities (XXE) (OWASP Top 10)

A new addition. Attackers can exploit vulnerable XML processors if they can upload XML or include hostile content in an XML document, exploiting vulnerable code, dependencies, or integrations. By default, many older XML processors allow specification of an external entity, a URI that is dereferenced and evaluated during XML processing. These flaws can be used to extract data, execute a remote request from the server, scan internal systems, perform a denial-of-service attack, as well as execute other attacks. (Position on previous/last year's list: N/A, new entry for 2017 list)

Broken Access Control (OWASP Top 10)

A new addition. Exploitation of access control is a core skill of attackers. Static Application Security Testing (SAST) and Dynamic Application Security Testing (DAST) tools can detect the absence of access control but cannot verify if it is functional when it is present. Access control is detectable using manual means, or possibly through automation for the absence of access controls in certain frameworks. Access control weaknesses are common due to the lack of automated detection, and lack of effective functional testing by application developers. Access control detection is not typically amenable to automated static or dynamic testing. Manual testing is the best way to detect missing or ineffective access control, including HTTP method (GET vs. PUT, and so on), controller, direct object references, and so on. (Position on previous/last year's list: N/A, new entry for 2017 list)

Insecure Deserialization (OWASP Top 10)

A new addition. Interestingly, unlike other entries on the list, this was included in the Top 10 based on an industry survey and not on quantifiable data. Exploitation of deserialization is somewhat difficult, as off-the-shelf exploits rarely work without changes or tweaks to the underlying exploit code. Some tools can discover deserialization flaws, but human assistance is frequently needed to validate the problem. It is expected that prevalence data for deserialization flaws will increase as tooling is developed to help identify and address it. The impact of deserialization flaws cannot be understated. These flaws can lead to remote code execution attacks, one of the most serious attacks possible. (Position on previous/last year's list: N/A, new entry for 2017 list)

Insufficient Logging and Monitoring (OWASP Top 10)

A new addition. Like #8, this was also included in the Top 10 based on an industry survey. Exploitation of insufficient logging and monitoring is the bedrock of nearly every major incident. Attackers rely on the lack of monitoring and timely response to achieve their goals without being detected. One strategy for determining if sufficient monitoring is in place is to examine the logs following penetration testing. The testers' actions should be recorded sufficiently to understand what damages they may have inflicted. Most successful attacks start with vulnerability probing, and should be noted and acted upon at that stage. Allowing such probes to continue can raise the likelihood of successful exploit to exponentially. (Position on previous/last year's list: N/A, new entry for 2017 list)

session fixation attack

A session fixation attack is somewhat similar to CSRF. The attacker logs in to a legitimate site and pulls a session ID, and then sends an e-mail with a link containing the fixed session ID. When the user clicks it and logs in to the same legitimate site, the hacker can now log in and run with the user's credentials.

address space layout randomization (ASLR) and data execution prevention (DEP)

All of these are memory management attacks that take advantage of how operating systems store information. While canary words are good for test purposes, address space layout randomization (ASLR) and data execution prevention (DEP) are extremely common mechanisms to fight most of these attacks.

Requests For Comments (RFCs)

An RFC is used to set a variety of standards— everything from the makeup of a UDP header to how routing protocols are supposed to work, and almost anything else you can think of. Per the IETF regarding RFCs: "...this name (used since 1969, before the IETF existed) expresses something important: the Internet is a constantly changing technical system, and any document that we write today may need to be updated tomorrow."

manipulating the hidden field on the source code of the page

Another easy and simple attack vector involves manipulating the hidden field on the source code of the page. See, back in the day, web developers simply trusted users wouldn't bother looking at the source code (assuming they were too stupid or apathetic), and they relied on poor coding practices. The thought was that if the users didn't see it displayed in their browsers, they wouldn't know it was there. To take advantage of this, developers used an HTML code attribute called "hidden." Despite the fact that it's a well-known but unsecured method to transmit data, especially on shopping sites, and it's a generally accepted fact that the web page itself shouldn't be holding this information, the use of the hidden attribute for pricing and other options is still pretty prevalent. To

piggybacking

Another in-band attack is known as "piggybacking." The idea is simple—just add your malicious request on the back of a legitimate one. Also, as an aside, please keep in mind that anything other than basic SQL will have some significant semantic differences, so always Google the database version you're trying.

Broken Authentication and Session Management (OWASP Top 10)

Application functions related to authentication and session management are often not implemented correctly, allowing attackers to compromise passwords, keys, or session tokens, or to exploit other implementation flaws to assume other users' identities. (Position on previous/last year's list: #2)

CSPP (connection string parameter pollution)

CSPP (connection string parameter pollution) is an injection attack that takes advantage of web applications that communicate with databases by using semicolons to separate each parameter. It has been around since 2010, but there's not much written about it or attention paid to it, for whatever reason. If carried out successfully, this attack can be used to steal user identities and hijack web credentials.

Using Components with Known Vulnerabilities (OWASP Top 10)

Components such as libraries, frameworks, and other software modules almost always run with full privileges. If a vulnerable component is exploited, such an attack can facilitate serious data loss or server takeover. Applications using components with known vulnerabilities may undermine application defenses and enable a range of possible attacks and impacts. (Position on previous/last year's list: #9)

Out-of-band SQL injection

Contrary to in-band, this type of SQL injection uses different communication channels for the attack and results. It's also more difficult to pull off.

parameter or URL tampering

ECC sometimes likes asking about parameter or URL tampering. In short, you just manipulate parameters within the URL string in hopes of modifying data such as permissions and elevation of privileges, prices and quantities of goods, and credentials. The trick is to simply look at the URL and find parameters you can adjust and re-send.

password attack and SSH brute-force attack

Exactly what they sound like

Fuzz testing

Fuzz testing involves inputting bunches of random data into a target (a site, an application, anything) to see what will happen. Designers work on code for data inputs they expect a customer to input; however, whether intentionally or not, input data not even close to what's expected may be ingested. While we mention it here in terms of SQL injection, fuzzing is used on tons of different stuff.

Security Misconfiguration (OWASP Top 10)

Good security requires having a secure configuration defined and deployed for the application, frameworks, application server, web server, database server, and platform. Secure settings should be defined, implemented, and maintained, as defaults are often insecure. Additionally, software should be kept up to date. (Position on previous/last year's list: #5)

Identifying entry points

Identifying entry points is a good place to start. After all, if you can figure out where the application is asking you for input, you're already looking at a way in. To accomplish this, be sure to examine cookies, headers, POST data, and encoding or encryption measures. And for goodness sake, don't ignore the obvious—the URL can tell you a lot (input parameters and such are often displayed there). There are several tools that can help in identifying your entry points, including WebScarab, HTTPrint, and Burp Suite. For example, the following URL: https://anybiz.com/agents.aspx? name=ex%50clients&isActive=0&inDate=20%2F11%2F2012&stopDate=20%2F05%2F2013& The platform is shown easily enough (aspx), and we can even see a couple column headers from the back-end database (inDate, stopDate, and name). Error messages and session tokens can also provide valuable information on server-side technology, if you're paying attention. A really good way to get this done is mirroring, which provides you with all the time you need on a local copy to check things out. You won't be able to get actual code, but it will give you time to figure out the best way into the real site for future analysis.

canary words

In buffer overflow and programming parlance, canary words are known values placed between the buffer and control data. If a buffer overflow occurs, the canary word will be altered first, triggering a halt to the system. Tools such as StackGuard make use of this for stack protection.

Directory traversal

In this attack, the hacker attempts to access restricted directories and execute commands outside intended web server directories. Also known as the dot-dot-slash attack, directory climbing, and backtracking, this attack basically sends HTTP requests asking the server to drop back to the root directory and give access to other folders. An example of just such a command might look like this: http://www.example.com/../../../../etc/passwd The dot-dot-slashes are intended to take the shell back to the root and then to pull up the password file. This may take a little trial and error, and it isn't effective on servers that take steps to protect input validation, but it's definitely worth your time. Signature-based IDSs have rules in place to look for dot-dot-slash strings and the like. One method for getting around this is to use Unicode in the string to represent the dots and slashes. In general, the %2e code can represent a dot, whereas %sf can represent a slash, for example: %2e%2e%2f

Injection Flaws (OWASP Top 10)

Injection flaws, such as SQL, OS, and LDAP injection, occur when untrusted data is sent to an interpreter as part of a command or query. The attacker's hostile data can trick the interpreter into executing unintended commands or accessing data without proper authorization. (Position on previous/last year's list: #1)

Web 2.0

It simply refers to a somewhat different method of creating websites and applications: while 1.0 relies on static HTML, 2.0 uses "dynamic" web pages. Because they're dynamic in nature, 2.0 apps allow users to upload and download to a site simultaneously, which provides much better infrastructure for social media and other user participation efforts. Per ECC, because Web 2.0 apps provide for more dynamic user participation, they also offer more attack surface.

Metasploit

It's called a framework for a reason—it's a toolkit that allows for exploit development and research. The framework base accepts inputs from custom plug-ins, interfaces (how you interact with the framework), security tools, web services, and modules (each with its own specific purpose). Under MODULES, for example, EXPLOITS would hold the actual exploit itself (which you can play with, alter, configure, and encapsulate as you see fit), while PAYLOADS combines the arbitrary code executed if the exploit is successful. AUXILIARY is used to run one-off actions (like a scan), while NOPS is used mainly for buffer-overflow-type operations. REX, right there in the middle of the figure, is the library for most tasks, such as handling sockets, protocols, and text transformations.

LDAP injection

LDAP injection is an attack that exploits applications that construct LDAP statements based on user input. To be more specific, it exploits nonvalidated web input that passes LDAP queries. In other words, if a web application takes whatever is entered into the form field and passes it directly as an LDAP query, an attacker can inject code to do all kinds of things. For example, suppose a web application allows managers to pull information about their projects and employees by logging in, setting permissions, and providing answers to queries based on those permissions. Manager Matt logs in every morning to check on his folks by entering his username and password into two boxes on a form, and his login is parsed into an LDAP query (to validate who he is). The LDAP query would look something like (&(USER=Matt) (Password=MyPwd!)) which basically says, "Check to see whether the username Matt matches the password MyPwd! If it's valid, login is successful and off he goes." In an LDAP injection attack, the attacker changes what's entered into the form field by adding the characters)(&) after the username and then providing any password (see Figure 6-5). Because the & symbol ends the query, only the first part—"check to see whether Matt is a valid user"—is processed and, therefore, any password will work. The LDAP query looks like this in the attack: (&(USER=Matt) (&) (PASSWORD=Anything)) login form would look like: username = Matt)(&) This basically says, "Check to see whether you have a user named Matt. If he's there, cool—let's just let him do whatever he wants." While there's a lot of other things you can do with this, I think the point is made: don't discount something even this simple because you never know what you'll be able to find with it.

Sensitive Data Exposure (OWASP Top 10)

Many web applications do not properly protect sensitive data, such as credit cards, tax IDs, and authentication credentials. Attackers may steal or modify such weakly protected data to conduct credit card fraud, identity theft, or other crimes. Sensitive data deserves extra protection, such as encryption at rest or in transit, as well as special precautions when exchanged with the browser. (Position on previous/last year's list: #6)

WFETCH

One web attack tool you'll need to become familiar with is WFETCH (Microsoft.com). It allows you to craft HTTP requests to see raw request and response data, as well as to pull off performance tests and other assessments.

Shellshock (Bashdoor)

Read up on Shellshock (a.k.a. Bashdoor). It's not a web server attack per se, but since many Internet-facing services and some web server deployments use Bash to process certain requests, it's worth mentioning here. Shellshock works by causing Bash to unintentionally execute commands when the commands are concatenated (usually via CGI) to the end of function definitions stored in the values of environment variables.

SOAP injection

SOAP injection is another related attack. Simple Object Access Protocol (SOAP) is designed to exchange structured information in web services in computer networks and uses XML to format information. You can inject malicious query strings (much like SQL injection, as a matter of fact) that may allow you to bypass authentication and access databases behind the scenes. SOAP is compatible with HTTP and SMTP, and messages are typically "one way" in nature.

SQL injection

SQL injection occurs when the attacker injects SQL queries directly into the input form. Properly constructed, the SQL command bypasses the intent of the front end and executes directly on the SQL database.

smashing the stack

Some buffer overflow attacks are also referred to as smashing the stack. The name came from a presentation that has become one of the founding documents of hacking, "Smashing the Stack for Fun and Profit," by Aleph One (for Phrack 49). The original write-up can be found in numerous places with any Internet search engine and is worth a read.

Structured Query Language (SQL)

Structured Query Language (SQL) is a computer language designed for managing data in a relational database system. The relational database is simply a collection of tables (consisting of rows, which hold individual fields containing data) tied together using some common field (key) that you can update and query. Each table has a name given to it that is referenced when you perform queries or updates. SQL comes into play when you are adding, deleting, moving, updating, or viewing the data in those tables and fields.

CONNECT method

The CONNECT method is reserved for use with a proxy that can dynamically switch to being a tunnel (for example, SSL tunneling).

DELETE method

The DELETE method requests that the origin server delete the resource identified by the Request-URI.

GET method

The GET method means retrieve whatever information (in the form of an entity) is identified by the Request-URI. In short, it basically requests data from a resource: "Please send me the HTML for the web page located at _insert-URL-here_." The problem with it is designers—especially early on—used HTTP GET to send data as well, and when sending data, the GET method adds the data to the URL. For example, if a GET was used in answering a bill for a credit card, you might see the URL display like this: http://www.example.com/checkout?7568.asp/credit1234567890123456 (the underlined section showing the ridiculousness of using GET in this way).

HEAD method

The HEAD method is identical to GET except that the server must not return a messagebody in the response. This method is often used for testing hypertext links for validity, accessibility, and recent modification, as well as for requesting headers and metadata.

Open Web Application Security Project (OWASP)

The Open Web Application Security Project is a 501(c)(3) worldwide not-for-profit charitable organization focused on improving the security of software. Their mission is to make software security visible so that individuals and organizations worldwide can make informed decisions about true software security risks. OWASP publishes reports, documents, and training efforts to assist in web security.

POST method

The POST method is used to request that the origin server accept the entity enclosed in the request as a new subordinate of the resource identified by the Request-URI in the Request-Line. The actual function performed by the POST method is determined by the server and is usually dependent on the Request-URI. In short, it's a better method of submitting data to a resource for processing. It can also be used to elicit a response, but its primary purpose is to provide data for the server to work with. POST is generally considered safer than GET because an admin can make it so it's not stored in browser history or in the server logs, and it doesn't display returned data in the URL.

PUT method

The PUT method requests that the enclosed entity be stored under the supplied RequestURI. If the Request-URI refers to an already existing resource, the enclosed entity should be considered as a modified version of the one residing on the origin server. If the Request-URI does not point to an existing resource, and that URI is capable of being defined as a new resource by the requesting user agent, the origin server can create the resource with that URI.

TRACE method

The TRACE method is used to invoke a remote, Application layer loopback of the request message. The final recipient of the request should reflect the message received back to the client as the entity-body of a 200 (OK) response.

XSSed project

The XSSed project (www.xssed.com), created in 2007, and is an excellent resource on all things related to cross-site scripting vulnerabilities. Per the site, it is the largest online archive of XSS vulnerable websites and was started to increase security and privacy on the web. Professional and amateur webmasters and web developers are notified about any cross-site scripting vulnerability affecting their online properties. May definitely be worth checking out!

HTTP response splitting

The attack works by adding header response data to an input field so that the server splits the response in a couple directions. If it works, the attacker controls the content of the second header, which can be used for any number of things—like redirecting the user to a malicious site the attacker runs. OWASP calls HTTP response splitting "a means to an end, not an end in itself," because the attack is designed to allow other attacks (through the second header content) to work.

Status-Code

The first digit of the Status-Code defines the class of response. The last two digits do not have any categorization role, but more thoroughly define the response intent. There are five values for the first digit: • 1xx: Informational Request received, continuing process. • 2xx: Success The action was successfully received, understood, and accepted. • 3xx: Redirection Further action must be taken in order to complete the request. • 4xx: Client Error The request contains bad syntax or cannot be fulfilled. • 5xx: Server Error The server failed to fulfill an apparently valid request.

buffer overflow

The most basic definition of a buffer overflow is an attempt to write more data into an application's prebuilt buffer area in order to overwrite adjacent memory, execute code, or crash a system (application). In short, you input more data than the buffer is allocated to hold. The result can be anything from crashing the application or machine to altering the application's data pointers, allowing you to run different executable code. ECC used to have several categories and memorization terms for you in regard to buffer overflows (like stack, heap, NOP sleds, and so on), but the latest version doesn't seem to care much about it at all.

In-band SQL injection

This is SQL injection where the attacker is using the same communication channel to perform and retrieve the results of the attack. This is the most commonly used type. Examples are Union Query attacks (the UNION command allows you to join together SELECT queries; for example, SELECT fname,lname FROM users WHERE id=$id UNION ALL SELECT socialsecuritynumber,1 FROM secretstuff; combines a relatively harmless query with one that's a little more...useful), error-based (the objective is to purposely enter poorly constructed statements in an effort to get the database to respond with table names and other information in its error messages), tautology (an overly complex term used to describe the behavior of a database system when deciding whether a statement is true; because user IDs and passwords are often compared and the "true" measure allows access, if you trick the database by providing something that is already true [1 does, indeed, equal 1], then you can sneak by), and endof- line/inline comments.

Blind/inferential

This type occurs when the attacker knows the database is susceptible to injection, but the error messages and screen returns don't come back to the attacker (not to mention results are oftentimes Boolean in return). Because there's a lot of guesswork and trial and error, this attack takes a long while to pull off.

World Wide Web Consortium (W3C)

W3C (https://www.w3.org) is an international community where "member organizations, a full-time staff, and the public work together to develop Web standards." Their stated mission is "to lead the World Wide Web to its full potential by developing protocols and guidelines that ensure the long-term growth of the Web." For example, when incompatible versions of HTML are offered by different vendors, causing inconsistency in how web pages are displayed, the consortium tries to get all those vendors to implement a set of core principles and components that are chosen by the consortium. W3C engages in education and outreach, develops software, and serves as an open forum for discussion about the Web.

Web applications

Web applications are most often hacked because of inherent weaknesses built into the program at inception. Developers might overlook known vulnerabilities, forget to patch security flaws, or leave default passwords and accounts open for exploitation. A patient hacker can scratch away at the application looking for these vulnerabilities, eventually finding a way in. It's obviously impossible to cover every single one of these vulnerabilities and the attacks that work on them because each is dependent on the circumstances and the individual application. For now, we'll just concentrate efforts on a few and see where we get.

Web defacement attacks

Web defacement attacks are the unique ones in the "obvious list of web attacks," but only because of what ECC focuses on. A web defacement attack results in the page being...well, defaced: an attacker maliciously alters the visual appearance of the page.

Cross-Site Scripting (XSS) (OWASP Top 10)

XSS flaws occur whenever an application takes untrusted data and sends it to a web browser without proper validation or escaping. XSS allows attackers to execute scripts in the victim's browser, which can hijack user sessions, deface websites, or redirect the user to malicious sites. It's notable that this dropped so precipitously from the last list. It's still a Top 10 issue, however, so don't discount. (Position on previous/last year's list: #3)

stored XSS, a.k.a. persistent or Type-I XSS

having the injected script remain permanently on the target server (like in a database, message forum, visitor log, or comment field)

misconfiguration attack

misconfiguration attack takes advantage of configuration items on the server not being configured correctly.