Must know "Security Attacks" , for System Administrators
During the weekends, i normally check gurkulindia.com’s security analysis report. And this is the time where my sysadmin mind starts thinking like a security admin, just to understand the risks that my website having now. I know most of us will think about security during our day to day system admin operations, and many times it happens that we do involve in a security fix as part of some security audit.
One interesting thing here is, only few of system admins know about the actual security problems that they are fixing but the rest will just involve in the fixing without having any clue about the problem.
In this post, I am trying to explain few common security threats and vulnerabilities for a little awareness to the sysadmins.
We all know that the programming languages stores data in small blocks of system memory. A Buffer Overflow is a flaw that occurs when more data is written to a block of memory, or buffer, than the buffer is allocated to hold. Exploiting a buffer overflow allows an attacker to modify portions of the target process’ address space. This ability can be used for a number of purposes, including the following:
- Control the process execution
- Crash the process
- Modify internal variables
The attacker’s goal is almost always to control the target process’ execution. This is accomplished by identifying a function pointer in memory that can be modified, directly or indirectly, using the overflow. When such a pointer is used by the program to direct program execution through a jump or call instruction, the attacker-supplied instruction location will be used, thereby allowing the attacker to control the process.
In many cases, the function pointer is modified to reference a location where the attacker has placed assembled machine-specific instructions. These instructions are commonly referred to as shellcode, in reference to the fact that attackers often wish to spawn a command-line environment, or shell, in the context of the running process.
Buffer overflows are most often associated with software written in the C and C++ programming languages due to their widespread use and ability to perform direct memory manipulation with common programming constructs. It should be emphasized, however, that buffer overflows can exist in any programming environment where direct memory manipulation is allowed, whether through flaws in the compiler, runtime libraries, or features of the language itself.
How many of you heard about recent online banking account thefts through fake emails, and these are the best examples of content spoofing.
Now a days most of the websites are using dynamic HTML content sources where the website pages can be added to the site at any time using user friendly interfaces. And these newly created webpages will be linked to existing website using the markup languages like HTML. If an attacker could manage to link his own page, with similar appearance as original page, to the original website, then the attack is called Content spoofing. The technique has been used to create fake web pages including login forms, defacements, false press releases, etc.
If an attacker gets a user to visit a web page designated by their malicious URL, the user will believe he is viewing authentic content from one location when he is not. Users will implicitly trust the spoofed content since the browser location bar displays http://foo.example, when in fact the underlying HTML frame is referencing http://attacker.example.
Creating a spoofed press release. Let’s say a web site uses dynamically created HTML frames for their press release web pages. A user would visit a link such as (http://foo.example/pr?pg=http://foo.example/pr/01012003.html). The resulting web page HTML would be:
<FRAMESET COLS=”100, *”>
<FRAME NAME=”pr_menu” src=”menu.html”>
The “pr” web application in the example above creates the HTML with a static menu and a dynamically generated FRAME SRC. The “pr_content” frame pulls its source from the URL parameter value of “pg” to display the requested press release content. But what if an attacker altered the normal URL to http://foo.example/pr?pg=http://attacker.example/spoofed_press_release.html? Without properly sanity checking the “pg” value, the resulting HTML would be:
<FRAMESET COLS=”100, *”>
<FRAME NAME=”pr_menu” src=”menu.html”>
<FRAME NAME=”pr_content” src=” http://attacker.example/spoofed_press_release.html”>
To the end user, the “attacker.example” spoofed content appears authentic and delivered from a legitimate source. It is important to understand that if you are vulnerable to Cross-Site Scripting (XSS) you are likely vulnerable to content spoofing. Additionally you can be protected from XSS and still be vulnerable to Content Spoofing.
Cross-site scripting (XSS) vulnerabilities let visitor-provided input, such as text in a search or form, influence how a website functions or displays for another visitor.
For example: A blog site lets visitors comment on posts. The site doesn’t check the content to make sure it’s valid, and displays comments without sanitizing them.
Attackers can add comments with malicious links containing scripts that let them take over another user’s session on the site. In simple terms this is similar to open a second web page of the site you are browsing, without using the username and password (this is explained in details in Credential/Session Prediction attack sections of this post) .
Denial of Service
Denial of Service (DoS) is an attack technique with the intent of preventing a web site from serving normal user activity. DoS attacks, which are easily normally applied to the network layer, are also possible at the application layer. These malicious attacks can succeed by starving a system of critical resources, vulnerability exploit, or abuse of functionality.
Many times DoS attacks will attempt to consume all of a web site’s available system resources such as: CPU, memory, disk space etc. When any one of these critical resources reach full utilization, the web site will normally be inaccessible.
As today’s web application environments include a web server, database server and an authentication server, DoS at the application layer may target each of these independent components. Unlike DoS at the network layer, where a large number of connection attempts are required, DoS at the application layer is a much simpler task to perform.
Assume a Health-Care web site that generates a report with medical history. For each report request, the web site queries the database to fetch all records matching a single social security number. Given that hundred of thousands of records are stored in the database (for all users), the user will need to wait three minutes to get their medical history report. During the three minutes of time, the database server’s CPU reaches 60% utilization while searching for matching records.
A common application layer DoS attack will send 10 simultaneous requests asking to generate a medical history report. These requests will most likely put the web site under a DoS-condition as the database server’s CPU will reach 100% utilization. At this point the system will likely be inaccessible to normal user activity.
DoS attacks can be created targeting an Individual user, A Database Server or A Web server
Credential/Session Prediction is a method of hijacking or impersonating a web site user. Deducing or guessing the unique value that identifies a particular session or user accomplishes the attack. Also known as Session Hijacking, the consequences could allow attackers the ability to issue web site requests with the compromised user’s privileges.
Many web sites are designed to authenticate and track a user when communication is first established. To do this, users must prove their identity to the web site, typically by supplying a username/password (credentials) combination. Rather than passing these confidential credentials back and forth with each transaction, web sites will generate a unique “session ID” to identify the user session as authenticated. Subsequent communication between the user and the web site is tagged with the session ID as “proof” of the authenticated session. If an attacker is able predict or guess the session ID of another user, fraudulent activity is possible.
Many web sites attempt to generate session IDs using proprietary algorithms. These custom methodologies might generation session IDs by simply incrementing static numbers. Or there could be more complex procedures such as factoring in time and other computer specific variables.
The session ID is then stored in a cookie, hidden form-field, or URL. If an attacker can determine the algorithm used to generate the session ID, an attack can be mounted as follows:
- attacker connects to the web application acquiring the current session ID.
- attacker calculates or Brute Forces the next session ID.
- attacker switches the current value in the cookie/hidden form-field/URL and assumes the identity of the next user.
Improper Filesystem Permissions
Improper filesystem permissions are a threat to the confidentiality, integrity and availability of a web application. The problem arises when incorrect filesystem permissions are set on files, folders, and symbolic links. When improper permissions are set, an attacker may be able to access restricted files or directories and modify or delete their contents. For example, if an anonymous user account has write permission to a file, then an attacker may be able to modify the contents of the file influencing the web application in undesirable ways. An attacker may also exploit improper symlinks to escalate their privileges and/or access unauthorized files; for example, a symlink that points to a directory outside of the web root.
The following are some of the permissions associated with files
– List Folder Contents
Every file, directory and symlink on the operating system and web server has a set of permissions associated with it.
Web servers use an operating system account to access the resources offered by an underlying filesystem. The operating system account has a set of permissions to access the source code and/or execute server side scripts. When the user’s browser requests a file, the web server decides how to serve the file based on the file type and the pre-defined security settings. In the case of a client requesting an HTML file, the web server attempts to load the file from the file system using it’s operating system system account. Depending on the permissions assigned to the file the web server will either serve the file or return a 403 permission denied error.
This list is not complete, but it is just a start. I will add more whenever I find right information and example for the the rest of the threats.You can refer “Open web application security project site” for more related information on web servers security.