Previously, web applications have been discussed with a technical analysis of the specific attack types that target them. Many of these high-profile attacks on companies use similar methods and tools to gain access, and some components of web services are especially vulnerable in comparison to others, especially at points where users are able to input text data. An open field, file, or form that will take input and allow server processing may not have properly cleansed that input, allowing the remote execution of hidden and embedded code in that data that was not intended to be run on that server. This type of attack uses structured query language (SQL), which is a language used to query databases and insert data within them. SQL is a special-purpose programming language designed for managing data held in a relational database management system (RDBMS), or for stream processing in a relational data stream management system (RDSMS).
Other attacks similar in nature to SQL include the cross-site request forgery (CSRF) approach, wherein an already-attacked website sends a request to a website it wishes to attack using previously obtained and valid credentials. CSRF is a type of attack that occurs when a malicious website, an e-mail, a blog, an instant message, or a program causes a user’s web browser to perform an unwanted action on a previously trusted website for which the user is currently authenticated, and which is therefore trusted by that targeted but unsuspecting website. Cross-site scripting (XSS) also allows for an attack website to execute a script that extracts information from the web server being targeted for attack. XSS is a type of computer security vulnerability quite frequently found in web applications. XSS enables attackers to inject client-side script into web pages that are then viewed by other users.
SQL injection is a code injection technique used to attack data-driven applications in which malicious SQL statements are inserted into an entry field for execution. For example, the goal may be to dump the database contents to the attacker’s computer. SQL is an access and storage language used by most programmers against relationally stored databases. It is also frequently used by programmers who write in the PHP hypertext processor (PHP) programming language to access database information in order to provide front-end web services. In this case, the client accesses a desired web server and provides a username and password for authorization. Then, the client submits the normal SQL sequence of commands (select, from, where). The web server then submits those commands to the database server (or performs the database access function locally). The database determines the result of the query and then returns it to the client, as shown in Figure 11.1. This figure portrays a standard two-stage SQL (client to web server and then web server on to database server) access to a database wherein the SQL query has been infected with an SQL injection attack.
Figure 11.1 Querying a database by means of an infected (SQL injection) web server.
This two-stage design provides a separation or partitioning between the client, the web server, and the database server with the desired data to which the client seeks access. All processing, from initial log-on through authentication and then query request, are processed by the web server, which is separated from the back-end database server.
Once the entry web server has been infected by means of an SQL injection attack, the user input fields such as “user” and “pwd” are then overwritten by malicious PHP code with an input string that, once forwarded to the database server, would force that database server to perform an operation outside the security measures (which are meant to insure it as a safe data container) or the safe operating goals of the system. Figure 11.2 illustrates an example in which passwords would be overwritten by an SQL injection string.
This string will cause the login process to succeed, allowing a web-based attacker to move past the login screen and gain access to resources on an untraceable account. Beyond this method, the attacker may be able to add or remove users of the database and create the attacker’s own user accounts for malicious purposes. Among the best methods to prevent these injection techniques from occurring is to only use tested and secured code supplied directly from a known and trusted vendor rather than to allow public apps (applications), which might be downloaded from invalidated sites. Furthermore, it is important to ensure that scanning and data cleansing are being carried out at any client-side input area and on the web server to reduce the risk of PHP parameter infection, resulting in an SQL injection risk.
Figure 11.2 Passwords overwritten by SQL injection attack.
More Examples of Injection-Based Attacks
Many entry points exist on a client machine. From e-mail messaging to SMS messaging and texting, there are many ways for an attacker to directly place malicious code on a user’s machine and on web servers that are accessed by that user. So, the user may always be susceptible to infection by malicious code. It is difficult to secure many of these entry points without interfering with the functional process that the user’s (and the web server’s) applications perform. To secure against e-mail-based attacks, filters are placed to restrict the user from opening an e-mail from an illegitimate or unwanted source. However, fewer restrictions exist for text messages. Furthermore, the discovery and isolation of malicious spam e-mail is largely managed at high level by Internet service providers or corporate e-mail systems. However, a small spam e-mail, presented to an unwary user in such an attractive form that the user is compelled to click on it and follow its malicious link, is frequently all that is required for a chain of malicious processes to be triggered.
As an additional source of such malware infection, Adobe products have long been an easy and frequent target for infection because of their prevalence on user systems and their incorporation of automatic download processes for frequent upgrades. An infected Adobe PDF document has the potential to transmit malware code once an infected upgrade is downloaded and opened, since the PDF format has many rich options within the base of the file format itself. Additionally, the Java set of routines are universally present on user machines, and the launching of JavaScript code can then allow an attacker to launch malware on a user’s system, if downloaded, in the following fashion:
http://path/to/pdf/file.pdf#whatever_name_you_want=javascript:code_here
This downloading and execution of code, scripts, and documents challenges the conventional notions of coding structure and the acquisition of program code from a limited set of trustworthy sources. Furthermore, scripts are normally intended to be executed in a narrow set of specific ways and areas of operation in order to promote efficiency and control security. With these new sources of threat, quite often the source of malicious coding is being executed in areas where the client did not expect code to be placed. This may be among images, frames, videos, and forms that may all load from remote sites onto a trusted site but can bring malicious code along with them as they are downloaded to the client’s personal computer or mobile device.
A Review of the ScanBox Software
One of the attack tools that have been used in recent data breaches, such as the Anthem breach, is the downloaded ScanBox keystroke-logging software. It was triggered by the target client technician unwittingly clicking on an attractive spear-phishing or spam e-mail, which then triggered the ScanBox download. The ScanBox software was able to perform keylogging functions without the users ever noticing the installation of this malware on their machine. As long as the user was unwittingly heading to a compromised website, the resulting process of information collection from the now-compromised user’s machine could continue. This phase of an attack quickly transitions into enabling a high-level corporate attack, infestation, reconnaissance, and information download phase, followed by the placement of software enabling a long-term anonymous persistent presence in the attacked corporate systems. The time elapsing from the compromise of a critical account to the occurrence of the actual attack, infection, and data theft has been reduced to within a day, and the anonymous persistent presence of the attacker and the attacker’s installed malware are cloaked from detection.
QUESTIONS
1. How does a hacker perform keylogging functions without the user noticing?
2. What is SQL and what are some examples?
3. What are the commands for SQL injection?
4. CSRF relies on what four things?