Published on

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide


  1. 1. Denial of Service (DoS) This attack aims at preventing, for legitimate users, authorized access to a system resource or the delaying of system operations and functions. The attacker sends a few messages crafted in a specific manner that take advantage of the given vulnerability. Another way is to send a vast number of messages that consume some key resource at the target such as bandwidth, CPU time, memory, etc. The target application, machine, or network spends all of its critical resources on handling the attack traffic and cannot serve for its legitimate clients. The attack would last only as long as the attack is active. Distributed Denial of Service Attack (DDoS) DDoS are distributed Denial of Service attacks that achieve larger magnitude by launching coordinated attacks by using a framework of “handlers” and “agents”. A DDoS is innovative in the form of coordination of the attack, not in the attacker’s aim. Characteristics of DDoS DDoS Attack is a large-scale and coordinated attack on the availability of services of a victim system. The services under attack are those of the “primary victim,” while the compromised systems used to launch the attack are often called the “secondary victims”. This makes it difficult to detect because attacks originate from several IP addresses. If a single IP address is attacking a company, it can block that address at its firewall. If it is 30,000, this is extremely difficult. Perpetrator is able to multiply the effectiveness of the Denial of Service significantly by harnessing the resources of multiple unwitting accomplice computers which serve as attack platforms. Smurf The attacker would send a lot of ICMP echo request packets to a broadcast address, wherein the source address of the packets are set to the address of victim host ( instead of the attacker’s address), which is called spoofed source address. The requested hosts would respond the victim’s host by sending ICMP echo reply packets. The attacked host is flooded with ICMP reply packets and then can’t serve for other legitimate users. Buffer overflow Buffer overflow occurs any time the program writes more information into the buffer than the space allocated in the memory. The attacker can overwrite the data that controls the program execution path and hijack the control of the program to execute the attacker’s code instead of the process code. Sending email messages that have attachments with 256-character file names can cause buffer overflow. Teardrop IP requires that a packet that is too large for the next router to handle should be divided into fragments. The attacker's IP puts a confusing offset value in the second or later fragment. If the receiving operating system is not able to aggregate the packets accordingly, it can crash the system. It is a UDP attack, which uses overlapping offset fields to bring down hosts.
  2. 2. Ping of Death The attacker deliberately sends an IP packet larger than the 65,536 bytes allowed by the IP protocol. Fragmentation allows a single IP packet to be broken down into smaller segments. The fragments can add up to more than the allowed 65,536 bytes. The operating system, unable to handle oversized packets freezes, reboots, or simply crashes. The identity of the attacker sending the oversized packet can be easily spoofed. SYN The attacker sends bogus TCP SYN requests to a victim server. The host allocates resources (memory sockets) to the connection. Prevents the server from responding to the legitimate requests. This attack exploits the three-way handshake. Malicious flooding by large volumes of TCP SYN packets to the victim’s system with spoofed source IP addresses can cause DoS. Countermeasures Implement router filters. If they are available for your system, install patches to guard against TCP SYN flooding. Disable any unused or unneeded network services. Enable quota systems on your operating system if they are available. Observe your system performance and establish baselines for ordinary activity. Use the baseline to gauge unusual levels of disk activity, CPU usage, or network traffic. Use Tripwire or a similar tool to detect changes in configuration information or other files. Invest in redundant and fault-tolerant network configurations. Establish and maintain regular backup schedules and policies, particularly for important configuration information. Establish and maintain appropriate password policies, especially access to highly privileged accounts such as UNIX root or Microsoft Windows NT Administrator. DDoS countermeasure Configure routers to filter and limit traffic (ICMP, SYN, UDP, etc). Deploy firewalls at the boundaries of your network and filtering system must be able to distinguish harmful uses of a network service from legitimate uses. Install IDS (Intrusion Detection Systems) capable of detecting.
  3. 3. Buffer Overflow Buffer overflow is caused by an attacker making the program write more data into the buffer on memory than the buffer can hold, and the over run data in that buffer overflows onto another adjacent memory space that is used for other purposes. The problem is that no automatic bounds-checking is made while passing data. Buffer overflow allows the attackers to run their own codes on the attacked system. Stack Based overflow The stack on a memory is used to store temporary information. The attacker would add more information into the variable, when the program runs the variable assigned in the stack on memory exceed the limit and overflow occurs. The attacker can change the return address with a pointer to attacker’s executable codes in the stack. When a function call is executed, the address of the instruction is put onto the stack to be saved so that the function knows where to return control. Then the attacker’ code gain control and execute his programs. A buffer overflow occurring in the heap data area is referred to as a heap overflow and is exploitable in a different manner to that of stack-based overflows. Memory on the heap is dynamically allocated by the application at run-time and typically contains program data. Exploitation is performed by corrupting this data in specific ways to cause the application to overwrite internal structures such as linked list pointers. The canonical heap overflow technique overwrites dynamic memory allocation linkage (such as malloc meta data) and uses the resulting pointer exchange to overwrite a program function pointer. Heap based overflow The heap, a space on memory is utilized and assigned dynamically by the application at runtime. Dynamic variables are assigned on the heap with functions like malloc interface. Program data on heap is overflowed by an attacker to overwrite other dynamic variables. Shellcode is a method to exploit stack-based overflows Shellcodes exploit computer bugs in how the stack is handled In computer security, a shellcode is a small piece of code used as the payload in the exploitation of a software vulnerability. It is called "shellcode" because it typically starts a command shell from which the attacker can control the compromised machine. Shellcode is commonly written in machine code, but any piece of code that performs a similar task can be called shellcode. Libsafe is a library which re-writes some sensitive libc functions (strcpy, strcat, sprintf, vsprintf, getwd, gets, realpath, fscanf, scanf, sscanf) to prevent any overflow caused by a misuse of any one of them. It launches alerts when an overflow attempt is detected. Libsafe intercepts the calls to the unsafe functions and uses its own implementation of the function instead.
  4. 4. While keeping the same semantic, it adds detection of the bound violations. Buffer Overflow Countermeasure Manually audit the codes to make sure the stacks are not altered when the program is running. One good way is to disable the stack from executing other extra instructions. But manage the computer to use heap and stack for only data. Compilers should be programmed to do bound checks to process only appropriate inputs. Return Address Defender (RAD) is a simple patch for the compiler that automatically creates a safe area to store a copy of return addresses. After that, RAD automatically adds protection code into applications and compiles them to defend programs against buffer overflow attacks. Using a well supported and safe library could enable the programs run secure without overwriting. A SQL injection attack consists of insertion or "injection" of a SQL query via the input data from the client to the application. A successful SQL injection exploit can read sensitive data from the database, modify database data (Insert/Update/Delete), execute administration operations on the database (such as shutdown the DBMS), recover the content of a given file present on the DBMS file system and in some cases issue commands to the operating system. SQL injection attacks are a type of injection attack, in which SQL commands are injected into data-plane input in order to effect the execution of predefined SQL commands. Exploiting sql injection It exploits web applications using client-supplied sql queries. It enables an attacker to execute unauthorized SQL commands. It also takes advantage of unsafe queries in web applications and builds dynamic SQL queries. For example, when a user logs onto a web page by using a user name and password for validation, a SQL query is used. However, the attacker can use SQL injection to send specially crafted user name and password fields that poison the original SQL query. Try to look for pages that allow a user to submit data, for example: a log in page, search page, feedback, etc Look for HTML pages that use POST or GET commands If POST is used, you cannot see the parameters in the URL
  5. 5. Check the source code of the HTML to get information For example, to check whether it is using POST or GET, look for the <Form> tag in the source code <Form action=search.asp method=post> <input type=hidden name=X value=Z> </Form> Hacker breaks into the system by injecting malformed SQL into the query •strQry = "SELECT Count(*) FROM Users WHERE UserName='" + txtUser.Text + "' AND Password='" + txtPassword.Text + "'"; Original SQL Query: •SELECT UserName='Paul' In the case of the user entering a valid user name of "Paul" and a password of "password", strQry becomes: Count(*) FROM Users WHERE AND Password='password' But when the hacker enters ' Or 1=1 -- the query now becomes: •SELECT Count(*) FROM Users WHERE UserName='' Or 1=1 --' AND Password='' Because a pair of hyphens designates the beginning of a comment in SQL, the query becomes simply: •SELECT Count(*) FROM Users WHERE UserName='' Or 1=1 Blind SQL injection is a hacking method that allows an unauthorized attacker to access a database server It is facilitated by a common coding blunder: program accepts data from a client and executes SQL queries without validating client’s input Attacker is then free to extract, modify, add, or delete content from the database Hackers typically test for SQL injection vulnerabilities by sending application input that would cause server to generate an invalid SQL query To secure an application against SQL injection, developers must never allow client-supplied data to modify the syntax of SQL statements The best protection is to isolate the web application from SQL altogether All SQL statements required by application should be in stored procedures and kept on database server Application should execute stored procedures using a safe interface such as JDBC’s CallableStatement or ADO’s Command Object If arbitrary statements must be used, use PreparedStatements Both PreparedStatements and stored procedures compile SQL statement before user input is added, making it impossible for user input to modify actual SQL statement
  6. 6. Minimize the privileges of database connections Disable verbose error messages Protect the system account “sa” Audit source codes • Escape single quotes • Input validation • Reject known bad input • Input bound checking Never trust user input • Validate all textbox entries using validation controls, regular expressions, code, and so on Never use dynamic SQL • Use parameterized SQL or stored procedures Never connect to a database using an admin-level account • Use a limited access account to connect to the database Do not store secrets in plain text • Encrypt or hash passwords and other sensitive data; you should also encrypt connection strings Exceptions should divulge minimal information • Do not reveal too much information in error messages; use custom errors to display minimal information in the event of an unhandled error; set debug to false Cross-site scripting (XSS) Cross-site scripting (XSS) is a type of computer security vulnerability typically found in web application that enables malicious attackers to inject client-side script into web pages viewed by other users. An exploited cross-site scripting vulnerability can be used by attackers to bypass access controls such as the same origin policy. Their impact may range from a petty nuisance to a significant security risk, depending on the sensitivity of the data handled by the vulnerable site, and the nature of any security mitigations implemented by the site's owner. Cross-site scripting holes are web application vulnerabilities that allow attackers to bypass client-side security mechanisms normally imposed on web content by modern browsers. By finding ways of injecting malicious scripts into web pages, an attacker can gain elevated access privileges to sensitive page content, session cookies, and a variety of other information maintained by the browser on behalf of the user.
  7. 7. Non-persistent XSS These holes show up when the data provided by a web client, most commonly in HTTP query parameters or in HTML form submissions, is used immediately by server-side scripts to generate a page of results for that user, without properly sanitizing the response. If one searches for a string, the search string will typically be redisplayed on the result page to indicate what was searched for. If this response does not properly escape or reject HTML control characters, a cross-site scripting flaw will ensue. It is important to realize, however, that a third-party attacker may easily place hidden frames or deceptive links on unrelated sites and cause victims' browsers to navigate to URLs on the vulnerable site automatically and in such a case, the attacker can intrude into the security context that rightfully belonged to the victim. Persistent XSS The persistent (or stored) XSS vulnerability is a cross-site scripting flaw: it occurs when the data provided by the attacker is saved by the server, and then permanently displayed on "normal" pages returned to other users in the course of regular browsing, without proper HTML escaping. An attacker's malicious script is rendered automatically, without the need to individually target victims or lure them to a third-party website. Particularly in the case of social networking sites, the code would be further designed to self-propagate across accounts, creating a type of a client-side worm. In some cases, the attacker may not even need to directly interact with the web functionality itself to exploit such a hole. Any data received by the web application (via email, system logs, etc.) that can be controlled by an attacker could become an injection vector. DOM-based vulnerabilities This is the standard model for representing HTML or XML contents which is called Document Object Model (DOM). DOM-based vulnerabilities occur in the content processing stages performed by the client, typically in client-side JavaScript. JavaScript programs manipulate the state of a web page and populate it with dynamically-computed data primarily by acting upon the DOM. A typical example is a piece of JavaScript accessing and extracting data from the URL via the location.* DOM, or receiving raw non-HTML data from the server via XML http request, and then using this information to write dynamic HTML without proper escaping, entirely on client side. Content validation, escaping and filtering
  8. 8. One way to eliminate some XSS vulnerabilities is to validate and reject undesirable characters in input fields using a blacklist, whitelist or combination of both. Another way is to escape all untrusted data using a method appropriate for the output context. Many operators of particular web applications (e.g. forums and webmail) wish to allow users to utilize some of the features HTML provides, such as a limited subset of HTML markup. To achieve this while preventing cross-site scripting flaws, some web applications attempt to identify malicious HTML constructs, and remove or rewrite them to prevent attacks. Cookie security Many web applications rely on session cookies for authentication between individual HTTP requests, and because client-side scripts generally have access to these cookies, simple XSS exploits can steal these cookies. To avoid this particular threat, many web applications tie session cookies to the IP address of the user who originally logged in, and only permit that IP to use that cookie. Disabling scripts Some web applications are written to operate completely without the need for client-side scripts. This allows users to have chance to disable scripting in their browsers before using the application. In this way, even potentially malicious client-side scripts could be inserted unescaped on a page, and users would not be susceptible to XSS attacks. Some browsers or browser plugins can be configured to disable client-side scripts on a per-domain basis. Functionality that blocks all scripting and external inclusions by default and then allows the user to enable it on a per-domain basis is more effective. The Firefox NoScript extension enables users to allow scripts selectively from a given page while disallowing others on the same page.