Lesson 15: Summarizing Secure Application Development Concepts Flashcards
Software exploitation
means an attack that targets a vulnerability in OS or application software. Applications such as web servers, web browsers, email clients, and databases are often targeted. An application vulnerability is a design flaw that can cause the application security system to be circumvented or that will cause the application to crash. Typically, vulnerabilities can only be exploited in quite specific circumstances but because of the complexity of modern software and the speed with which new versions must be released to market, almost no software is free from vulnerabilities.
zero-day exploit
Most vulnerabilities are discovered by software and security researchers, who notify the vendor to give them time to patch the vulnerability before releasing details to the wider public. A vulnerability that is exploited before the developer knows about it or can release a patch is called a zero-day exploit. These can be extremely destructive, as it can take the vendor a lot of time to develop a patch, leaving systems vulnerable for days, weeks, or even years.
input validation
Most software accepts user input of some kind, whether the input is typed manually or passed to the program by another program (such as a browser passing a URL to a web server). Good programming practice dictates that input should be tested to ensure that it is valid (that is, the sort of data expected by the program). An input validation attack passes invalid data to the application, and because the input handling on the routine is inadequate, it causes the application or even the OS to behave in an unexpected way.
As discussed earlier, the primary vector for attacking applications is to exploit faulty input validation. Input could include user data entered into a form or URL passed by another application or link. Malicious input could be crafted to perform an overflow attack or some type of injection attack. To mitigate this risk, all input methods should be documented with a view to reducing the potential attack surface exposed by the application. There must be routines to check user input, and anything that does not conform to what is required must be rejected.
There are many ways of exploiting improper input handling, but many attacks can be described as either overflow-type attacks or injection-type attacks:
- Overflow—the attacker submits input that is larger than the variables assigned by the application to store it can cope with.
- Injection—the attacker embeds code within the input or appends code to it that executes when the server processes the submission.
When an attacker tries to exploit improper input handling, the result might simply be to crash the process hosting the code or even the OS (performing Denial of Service). The attacker may be able to use the exploit to obtain sufficient privileges to run whatever malware (or arbitrary code) he or she chooses. A successful exploit can also facilitate data exfiltration from applications, databases, and operating systems if it allows the adversary to obtain privileges over the data that they would not normally have.
buffer overflow
To exploit a buffer overflow vulnerability, the attacker passes data that deliberately overfills the buffer (an area of memory) that the application reserves to store the expected data
There are three principal exploits of buffer overflow:
- Stack overflow—the stack is an area of memory used by a program subroutine. It includes a return address, which is the location of the program that called the subroutine. An attacker could use a buffer overflow to change the return address, allowing the attacker to run arbitrary code on the system. Two examples of this are the Code Red worm, which targeted Microsoft’s IIS web server (version 5) and the SQLSlammer worm, which targeted Microsoft SQL Server® 2000.
- Heap overflow—a heap is an area of memory allocated by the application during execution to store a variable of some sort. A heap overflow can overwrite those variables, with unexpected effects. An example is a known vulnerability in Microsoft’s GDI+ processing of JPEG images.
- Array index overflow—an array is a type of variable designed to store multiple values. It is possible to exploit unsecure code to load the array with more values than it expects, creating an exception that could be exploited.
integer overflow
An integer is a positive or negative number with no fractional component (a whole number). Integers are widely used as a data type, where they are commonly defined with fixed lower and upper bounds. An integer overflow attack causes the target software to calculate a value that exceeds these bounds. This may cause a positive number to become negative (changing a bank debit to a credit, for instance). It could also be used where the software is calculating a buffer size; if the attacker is able to make the buffer smaller than it should be, he or she may then be able to launch a buffer overflow attack.
Race conditions
occur when the outcome from execution processes is directly dependent on the order and timing of certain events, and those events fail to execute in the order and timing intended by the developer. A race condition vulnerability is typically found where multiple threads are attempting to write a variable or object at the same memory location. Race conditions have been used as an anti-virus evasion technique. In 2016, the Linux® kernel was discovered to have an exploitable race condition vulnerability, known as Dirty COW (https://www.theregister.co.uk/2016/10/21/linux_privilege_escalation_hole).
This type of vulnerability is mitigated by ensuring that a memory object is locked when one thread is manipulating it.
pointer
reference to an object at a particular memory location. Attempting to access that memory address is called dereferencing. If the pointer has been set to a null value (perhaps by some malicious process altering the execution environment), this creates a null pointer type of exception and the process will crash. Programmers can use logic statements to test that a pointer is not null before trying to use it.
Memory leaks
If a process is operating correctly, when it no longer requires a block of memory, it should release it. If the program code does not do this, it could create a situation where the system continually leaks memory to the faulty process. This means less memory is available to other processes and the system could crash. Memory leaks are particularly serious in service/background applications, as they will continue to consume memory over an extended period. Memory leaks in the OS kernel are also extremely serious. A memory leak may itself be a sign of a malicious or corrupted process.
Dynamic Link Library (DLL)
A Dynamic Link Library (DLL) is a binary package that implements some sort of standard functionality, such as establishing a network connection or performing cryptography. The main process of a software application is likely to load (or call) several DLLs during the normal course of operations.
DLL injection
not a vulnerability of an application but of the way the operating system allows one process to attach to another. This functionality can be abused by malware to force a legitimate process to load a malicious link library. The link library will contain whatever functions the malware author wants to be able to run. Malware uses this technique to move from one host process to another to avoid detection.
To perform DLL injection, the malware must already be operating with sufficient privileges (typically, local administrator or system privileges). It must also evade detection by anti-virus software. One means of doing this is code refactoring. Refactoring means that the code performs the same function by using different methods (control blocks, variable types, and so on). This might be done legitimately to improve the code in some way, such as making it run more efficiently or making it easier to maintain and update. Refactoring can also be used by malware authors to evade detection by A-V scanners because the different code syntax means that the malware must be identified by a new signature, or be caught by heuristic analysis.
OS function calls to allow DLL injection are legitimately used for operations such as debugging and monitoring. Another opportunity for malware authors to exploit these calls is the Windows Application Compatibility framework. This allows legacy applications written for an OS, such as Windows® XP, to run on Windows 10. The code library that intercepts and redirects calls to enable legacy mode functionality is called a shim. The shim must be added to the registry and its files (packed in a shim database/.SDB file) added to the system folder. The shim database represents another way that malware with local administrator privileges can run on reboot (persistence).
arbitrary code execution
The purpose of the attacks against application or coding vulnerabilities is to allow the attacker to run his or her own code on the system. This is referred to as arbitrary code execution.
remote code execution
Where the code is transmitted from one machine to another, it is sometimes referred to as remote code execution. The code would typically be designed to install some sort of Trojan or to disable the system in some way (Denial of Service).
privilege escalation
An application or process must have privileges to read and write data and execute functions. Depending on how the software is written, a process may run using a system account, the account of the logged-on user, or a nominated account. If a software exploit works, the attacker may be able to execute his or her own process (a worm or Trojan, for instance) with the same privilege level as the exploited process.
There are two main types of privilege escalation:
- Vertical privilege escalation (or elevation) is where a user or application can access functionality or data that should not be available to them. For instance, a user might have been originally assigned read-only access (or even no access) to certain files, but after vertical escalation, the user can edit or even delete the files in question.
- Horizontal privilege escalation is where a user accesses functionality or data that is intended for another user. For instance, a user might have the means to access another user’s online bank account.
SQL injection
As the name suggests, an SQL injection attack attempts to insert an SQL query as part of user input. The attack can either exploit poor input validation or unpatched vulnerabilities in the database application. If successful, this could allow the attacker to extract or insert information into the database or execute arbitrary code on the remote system using the same privileges as the database application.
XML injection is fundamentally the same thing but targeted against web services using XML data formats, rather than SQL.
Directory traversal
another common input validation attack. The attacker submits a request for a file outside the web server’s root directory by using the command to navigate to the parent directory (../). This attack can succeed if the input is not filtered properly and access permissions on the file are the same as those on the web server root.
command injection
A command injection attack attempts to run OS shell commands from the browser. As with directory traversal, the web server should normally be able to prevent commands from operating outside of the server’s directory root and to prevent commands from running with any other privilege level than the web “guest” user (who is normally granted only very restricted privileges). A successful command injection attack would find some way of circumventing this security (or find a web server that is not properly configured).
Transitive access
describes the problem of authorizing a request for a service that depends on an intermediate service. For example, say a user orders an ebook through some e‑commerce application on a merchant site. The merchant site processes the order and then places a request to a publisher site to fulfill the ebook to the user. Designing the trust relationships between these three parties is complicated:
- The merchant site could impersonate the end user to obtain publisher site services fraudulently.
- The end user could exploit weaknesses in the merchant site to obtain unauthorized services from the publisher site.
Cross-Site Scripting (XSS)
The attacks just described mostly target weaknesses of server-side application code or security measures. There are also many attacks against the browser (client-side code and security measures). Cross-Site Scripting (XSS) is one of the most powerful input validation exploits. XSS involves a trusted site, a client browsing the trusted site, and the attacker’s site.
A typical attack would proceed as follows:
- The attacker identifies an input validation vulnerability in the trusted site.
- The attacker crafts a URL to perform a code injection against the trusted site. This could be coded in a link from the attacker’s site to the trusted site or a link in an email message.
Note: The key to a successful XSS attack is making the link seem innocuous or trustworthy to the user. There are various ways of encoding a link to conceal its true nature.
- When the user clicks the link, the trusted site returns a page containing the malicious code injected by the attacker. As the browser is likely to be configured to allow the site to run scripts, the malicious code will execute.
- The malicious code could be used to deface the trusted site (by adding any sort of arbitrary HTML code), steal data from the user’s cookies, try to intercept information entered into a form, or try to install malware. The crucial point is that the malicious code runs in the client’s browser with the same permission level as the trusted site.
Note: A common technique is to leverage iFrames to disguise the presence of malicious code. An iFrame is a legitimate HTML coding technique that can be used to embed one site within another. A malicious iFrame could either overlay a site with a fake login or host malicious code in an “invisible” 1x1 pixel frame. iFrame attacks can also be launched simply by compromising the web server security and uploading compromised code.
The attack is particularly effective not only because it breaks the browser’s security model, but also because it relies only on scripting, which is generally assumed by browsers to be safe. The vast majority of sites use some sort of scripting and so will not display correctly without it.
The attack described is a reflected or non-persistent XSS attack. A stored (or persistent) XSS attack aims to insert code into a back-end database used by the trusted site. For example, the attacker may submit a post to a bulletin board with a malicious script embedded in the message. When other users view the message, the malicious script is executed.
Both the attacks described exploit server-side scripts. A third type of XSS attack exploits vulnerabilities in client-side scripts. Such scripts often use the Document Object Model (DOM) to modify the content and layout of a web page. For example, the “document.write” method enables a page to take some user input and modify the page accordingly. An attacker could submit a malicious script as input and have the page execute the script. Such exploits can be very powerful as they run with the logged in user’s privileges of the local system.
cookie
HTTP is a stateless protocol meaning that the server preserves no information about the client. As most web applications depend on retaining information about clients, various mechanisms have been used to preserve this sort of stateful information. A cookie is one of those methods. A cookie is created when the server sends an HTTP response header with the cookie. Subsequent request headers sent by the client will usually include the cookie. Cookies are either non-persistent (or session) cookies, in which case they are stored in memory and deleted when the browser instance is closed, or persistent, in which case they are stored on the hard drive until deleted by the user or pass a defined expiration date. For example, if, when logging in, the user selects the Remember Me option, then a cookie is saved and accessed the next time they visit that web page.
Normally, a cookie can only be used by the server or domain that created it, but this can be subverted by a Cross-Site Scripting attack. Another weakness is where cookies are used to establish sessions in an application or for user authentication. Session IDs are often generated using predictable patterns (such as IP address with the date and time), making the session vulnerable to eavesdropping and possibly hijacking, by replaying the cookie to re-establish the session.
Cross-Site Request Forgery (XSRF)
exploit applications that use cookies to authenticate users and track sessions. To work, the attacker must convince the victim to start a session with the target site. The attacker must then pass an HTTP request to the victim’s browser that spoofs an action on the target site, such as changing a password or an email address. This request could be disguised in a few ways (as an image tag, for instance) and so could be accomplished without the victim necessarily having to click a link. If the target site assumes that the browser is authenticated because there is a valid session cookie and doesn’t complete any additional authorization process on the attacker’s input (or if the attacker is able to spoof the authorization), it will accept the input as genuine. This is also referred to as a confused deputy attack (the point being that the user and the user’s browser are not necessarily the same thing).
Locally Shared Objects (LSOs)
Flash cookies, are data that is stored on a user’s computer by websites that use Adobe® Flash® Player. A site may be able to track a user’s browsing behavior through LSOs, causing a breach of privacy. Even if a user wipes tracking objects from their browser, LSOs may remain on their system.
HTTP headers
information processed by the server and browser but not necessarily displayed to the user. One of the headers is the action (GET or POST, for instance). Other headers may contain the user-agent (the type of browser) or custom information. Some applications may use headers to encode some user data, such as setting a cookie or returning the value of a cookie. If this is the case, as with forms and URLs, an attacker could try to inject code to perform a malicious action on the target server or client if the web application does not process the header correctly.
HTTP Response Splitting or CRLF injection
The best-known HTTP header manipulation attack is HTTP Response Splitting or CRLF injection. The attacker would craft a malicious URL and convince the victim to submit it to the web server. This could be encoded in something like an image tag, so the user may not have to choose to click a link. The URL contains extra line feeds, which may be coded in some non-obvious way. Unless the web server strips these out when processing the URL, it will be tricked into displaying a second HTTP response, containing content crafted by the attacker. This content could deface the genuine page, overlay a fake authentication form, perform some sort of XSS injection attack, and so on.
Man-in-the-Browser (MitB)
attack is where the web browser is compromised by installing malicious plug-ins or scripts or intercepting API calls between the browser process and DLLs. The Browser Exploitation Framework (BeEF) (https://beefproject.com) is one well-known MitB tool. There are various vulnerability exploit kits that can be installed to a website and actively try to exploit vulnerabilities in clients browsing the site (https://www.trendmicro.com/vinfo/ie/security/definition/exploit-kit). These kits may either be installed to a legitimate site without the owner’s knowledge (by compromising access control on the web server) and load in an iFrame (invisible to the user), or the attacker may use phishing/social engineering techniques to trick users into visiting the site, using Google™ search results, ads, typosquatting, or clicking an email link.
