Ιστογνώσις ΛΤΔ Σχεδίαση και ανάπτυξη ιστοσελίδων και εφαρμογών διαδικτύου
It is often possible to make the contents of a web page take fewer bytes without changing the appearance or function of the page. Reducing the number of bytes a client has to download makes the page load faster. In this tutorial we look at three ways to reduce the size of web content. We also explain how to use Page Speed to help make resources smaller.

Page Speed is a Firefox extension that evaluates web pages and gives suggestions on how to improve them. Instructions for installing Page Speed are available at http://code.google.com/speed/page-speed/download.html. I chose Page Speed because I am familiar with it. YSlow is a similar tool which also gives excellent advice to make your web pages faster.

Compress images

Image files are often created with extra information embedded in the file. For example, JPEG files written by many image programs include the name of the program that wrote them. PNG images can often be made smaller by changing the way the image is encoded. These transformations are lossless. That is, the compressed image looks identical to the uncompressed image, but uses fewer bytes.

The Page Speed rule "Optimize images" tries to losslessly compress all images in a page. When it succeeds, it shows the compressed versions. To use the minimized version of an image, in the Page Speed panel, click the link to the compressed version, save it, and use it instead of the original image

Minify JavaScript

Removing comments and white space from large JavaScript files can make them substantially smaller, without changing their functionality.

The Page Speed rule "Minify JavaScript" runs all JavaScript on a page through a JavaScript minimizer. If this generates a smaller file, Page Speed displays a link to that file. To use the minified JavaScript, click the link, save the minified file, and change your HTML to refer to the minified file.

You will want to keep the original JavaScript file around in case you want to change it in the future. Minified JavaScript is much harder to read and modify. If you modify your JavaScript frequently, a command line JavaScript minimizer that runs as part of your build process might be more convenient than Page Speed. JSMIN, available at http://www.crockford.com/javascript/jsmin.html, is such a program.

Remove unused CSS

CSS files contain rules that apply style attributes to elements in a web page. If a rule does not apply to any element in a page, removing it will result in fewer bytes being sent to the client, with no change in the appearance of the web page. However, because external style sheets may be included by more than one page, you must be careful to only remove rules that no page uses. The Page Speed rule "Remove unused CSS" can tell you which rules are not used in a given page. By running Page Speed on all pages that use an external stylesheet file, you can determine which rules are not used and remove them.

More ways to make your pages faster

The three suggestions above are a small sample of the issues Page Speed can detect and recommend fixes for. Page Speed and YSlow both rank their suggestions, so that you know which changes to your page are most likely to have a large impact. Running these tools on your page periodically and fixing issues they find will give your users faster pages.

source: http://code.google.com/speed/articles/identifying-page-speed-problems.html

Ιστογνώσις ΛΤΔ Σχεδίαση και ανάπτυξη ιστοσελίδων και εφαρμογών διαδικτύου

Authors: Gregory Baker, Software Engineer on GMail & Erik Arvidsson, Software Engineer on Google Chrome

Recommended experience: Working knowledge of JavaScript

Client-side scripting can make your application dynamic and active, but the browser's interpretation of this code can itself introduce inefficiencies, and the performance of different constructs varies from client to client. Here we discuss a few tips and best practices to optimize your JavaScript code.

Working with strings

String concatenation causes major problems with Internet Explorer 6 and 7 garbage collection performance. Although these issues have been addressed in Internet Explorer 8 -- concatenating is actually slightly more efficient on IE8 and other non-IE browsers such as Chrome -- if a significant portion of your user population uses Internet Explorer 6 or 7, you should pay serious attention to the way you build your strings.

Consider this example:

var veryLongMessage =
'This is a long string that due to our strict line length limit of' +
maxCharsPerLine +
' characters per line must be wrapped. ' +
percentWhoDislike +
'% of engineers dislike this rule. The line length limit is for ' +
' style purposes, but we don't want it to have a performance impact.' +
' So the question is how should we do the wrapping?';

Instead of concatenation, try using a join:

var veryLongMessage =
['This is a long string that due to our strict line length limit of',
maxCharsPerLine,
' characters per line must be wrapped. ',
percentWhoDislike,
'% of engineers dislike this rule. The line length limit is for ',
' style purposes, but we don't want it to have a performance impact.',
' So the question is how should we do the wrapping?'
].join();

Similarly, building up a string across conditional statements and/or loops by using concatenation can be very inefficient. The wrong way:

var fibonacciStr = 'First 20 Fibonacci Numbers
';
for (var i = 0; i < 20; i++) {
fibonacciStr += i + ' = ' + fibonacci(i) + '
';
}

The right way:

var strBuilder = ['First 20 fibonacci numbers:'];
for (var i = 0; i < 20; i++) {
strBuilder.push(i, ' = ', fibonacci(i));
}
var fibonacciStr = strBuilder.join('');

Building strings with portions coming from helper functions

Build up long strings by passing string builders (either an array or a helper class) into functions, to avoid temporary result strings.

For example, assuming buildMenuItemHtml_ needs to build up a string from literals and variables and would use a string builder internally, instead of using:

var strBuilder = [];
for (var i = 0, length = menuItems.length; i < length; i++) {
strBuilder.push(this.buildMenuItemHtml_(menuItems[i]));
}
var menuHtml = strBuilder.join();

Use:

var strBuilder = [];
for (var i = 0, length = menuItems.length; i < length; i++) {
this.buildMenuItem_(menuItems[i], strBuilder);
}
var menuHtml = strBuilder.join();

Defining class methods

The following is inefficient, as each time a instance of baz.Bar is constructed, a new function and closure is created for foo:

baz.Bar = function() {
// constructor body
this.foo = function() {
// method body
};
}

The preferred approach is:

baz.Bar = function() {
// constructor body
};

baz.Bar.prototype.foo = function() {
// method body
};

With this approach, no matter how many instances of baz.Bar are constructed, only a single function is ever created for foo, and no closures are created.

Initializing instance variables

Place instance variable declaration/initialization on the prototype for instance variables with value type (rather than reference type) initialization values (i.e. values of type number, Boolean, null, undefined, or string). This avoids unnecessarily running the initialization code each time the constructor is called. (This can't be done for instance variables whose initial value is dependent on arguments to the constructor, or some other state at time of construction.)

For example, instead of:

foo.Bar = function() {
this.prop1_ = 4;
this.prop2_ = true;
this.prop3_ = [];
this.prop4_ = 'blah';
};

Use:

foo.Bar = function() {
this.prop3_ = [];
};

foo.Bar.prototype.prop1_ = 4;

foo.Bar.prototype.prop2_ = true;

foo.Bar.prototype.prop4_ = 'blah';

Avoiding pitfalls with closures

Closures are a powerful and useful feature of JavaScript; however, they have several drawbacks, including:

• They are the most common source of memory leaks.

• Creating a closure is significantly slower then creating an inner function without a closure, and much slower than reusing a static function. For example:

  function setupAlertTimeout() {
var msg = 'Message to alert';
window.setTimeout(function() { alert(msg); }, 100);
}

  is slower than:

  function setupAlertTimeout() {
window.setTimeout(function() {
var msg = 'Message to alert';
alert(msg);
}, 100);
}

  which is slower than:

  function alertMsg() {
var msg = 'Message to alert';
alert(msg);
}

function setupAlertTimeout() {
window.setTimeout(alertMsg, 100);
}

• They add a level to the scope chain. When the browser resolves properties, each level of the scope chain must be checked. In the following example:

  var a = 'a';

function createFunctionWithClosure() {
var b = 'b';
return function () {
var c = 'c';
a;
b;
c;
};
}

var f = createFunctionWithClosure();
f();

  when f is invoked, referencing a is slower than referencing b, which is slower than referencing c.

See IE+JScript Performance Recommendations Part 3: JavaScript Code inefficiencies for information on when to use closures with IE.

Avoiding with

Avoid using with in your code. It has a negative impact on performance, as it modifies the scope chain, making it more expensive to look up variables in other scopes.

Avoiding browser memory leaks

Memory leaks are an all too common problem with web applications, and can result in huge performance hits. As the memory usage of the browser grows, your web application, along with the rest of the user's system, slows down. The most common memory leaks for web applications involve circular references between the JavaScript script engine and the browsers' C++ objects' implementing the DOM (e.g. between the JavaScript script engine and Internet Explorer's COM infrastructure, or between the JavaScript engine and Firefox XPCOM infrastructure).

Here are some rules of thumb for avoiding memory leaks:

Use an event system for attaching event handlers

The most common circular reference pattern [ DOM element --> event handler --> closure scope --> DOM ] element is discussed in this MSDN blog post. To avoid this problem, use one of the well-tested event systems for attaching event handlers, such as those in Google doctype, Dojo, or JQuery.

In addition, using inline event handlers can lead to another kind of leak in IE. This is not the common circular reference type leak, but rather a leak of an internal temporary anonymous script object. For details, see the section on "DOM Insertion Order Leak Model" in Understanding and Solving Internet Explorer Leak Patterns and and an example in this JavaScript Kit tutorial.

Avoid expando properties

Expando properties are arbitrary JavaScript properties on DOM elements and are a common source of circular references. You can use expando properties without introducing memory leaks, but it is pretty easy to introduce one by accident. The leak pattern here is [ DOM element --> via expando--> intermediary object --> DOM element ]. The best thing to do is to just avoid using them. If you do use them, only use values with primitive types. If you do use non-primitive values, nullify the expando property when it is no longer needed. See the section on "Circular References" in Understanding and Solving Internet Explorer Leak Patterns.

source: http://code.google.com/speed/articles/optimizing-javascript.html

Ιστογνώσις ΛΤΔ Σχεδίαση και ανάπτυξη ιστοσελίδων και εφαρμογών διαδικτύου

Rootkits are far from being something new, as their origins can be traced back to UNIX platforms. However, over recent years they have been used with increased frecuency to hide the existence of dangerous malware in computers that have been infected.

• What is a rootkit?
• What danger is presented by rootkits?
• What are the different types of rootkit?
• How can I protect myself from rootkits?

What is a rootkit?

Originally, within the context of UNIX-type systems, a rootkit was a group of tools belonging to the operating system itself, such as netstat , passwd and ps , which were modified by an intruder in order to gain unlimited access to the computer , without this intrusion being detected by the system administrator.

Within the framework of UNIX system terminology, the system administrator was called "root", thus the generic term for these tools, which remained hidden in the system once they had obtained root privileges.

Windows systems are today the most widespread operating systems, yet the concept still remains the same. 

A Windows rootkit is a program that hides certain elements (files, processes, entries in the Windows Registry , memory addresses, network connections, etc.) from other programs or the operating system.

As it can be seen, this definition does not in itself represent any kind of damaging effect on the system - it is a technology that can be used for constructive as well as destructive ends.

What danger is presented by rootkits?

In this way, and contrary to popular belief, rootkits are not tools which can be used to expose a computer to risk.

In UNIX systems, rootkits are used as a way to guarantee continuous access to a remote computer that has been previously compromised in order to, for example:

• Install backdoors through which the computer can be accessed.
• Hide those modifications that have been made to the configuration.
• Hide those logs left behind as a record of system intrusion.

For Windows systems the objective remains similar: to hide the existence of other elements within the computer, so that both their presence and execution remain undetected by the eyes of the user, and even by the security software itself. If these elements are viruses, then the computer owner is faced witha truly serious problem.

The year 2005 saw the first detections of variants of malware that use rootkits (external tools, and even techniques included in their code) to avoid detection. Bots , adware and spyware have added these characteristics to their own features, a trend which has only increased as time has gone by.

This fact is perfectly in line with the current malware dynamic. As the aim of malware is to carry out information crimes with the ultimate goal of economic gain, it is of the utmost importance that it passes by with little or no detection. In this way, the malware will stay active within the computer for the longest time possible, all the while remaining undetected.

On the other hand, there are potential benefits of using rootkits, which can be legitimately applied to the following areas:

• Monitoring employees.
• Protection of intellectual data.
• Protecting programs from malware activity or user errors (accidental deletion, for example).

In the wake of these possibly beneficial uses there was a case that received wide media coverage at the end of 2005. Expert Mark Russinovich discovered that the anti-copy protection system that Sony had included in some of its products contained a rootkit called XCP , that aimed to prevent the aforementioned protection from being disabled.

After a detailed analysis of this situation was published, it was not long before examples of malware began to appear (for example, the Ryknos.A backdoor), which maliciously used this rootkit to hide in those systems on which the anti-copy system was installed.

Sony was finally forced to supply a tool that would delete the rootkit and uninstall the anti-copy system.

As can be seen in the light of this example, even when a rootkit is being used for legitimate purposes, there are implications that must be carefully considered.

What are the different types of rootkits?

Rootkits can be classified in accordance with the following characteristics:

• Persistence: 
  
  - A persistent rootkit is one that is activated every time the system starts up. To do so, it must store its code in some way within the computer, and must also have some way to automatically start itself up. 
  
  - On the other hand, a non-persistent rootkit is not capable of automatically running again after the system has been restarted.
• The way in which they are executed: 
  
  - User mode: this kind of rootkit hooks system calls and filters the information returned by the APIs (Application Programming Interface). The most well-known rootkit of this type is Hacker Defender. 
  
  - Kernel mode (nucleus of the operating system): these rootkits modify the kernel data structures, as well as they hook the kernel's own APIs. This is the most reliable and robust way of intercepting the system.

As far as other methods or techniques used to produce rootkits are concerned, of particular note is the case of the University of Michigan and Microsoft. In March 2006 a rootkit based on virtual technology was developed. Its main function was to modify the computer's start-up sequence, so that it was loaded instead of the operating system. The rootkit then went on to load the operating system as if it were a virtual machine, so that all communication between the operating system and the hardware was intercepted. Once installed, this rootkit is basically undetectable.

How can I protect myself from rootkits?

The fight against rootkits is a real armed struggle, with creators developing measures to remain undetected and security companies releasing counter-measures to protect their clients.

The following techniques can be used to detect the existence of rootkits within a system:

• Signature-based detection: mature technology which has been successfully used by antivirus companies for many years now. This technology is based on scanning files and comparing them with a collection of signatures from known malware.
• Heuristic or behavior-based detection: identifies rootkits by recognizing any deviations in the computer's normal activity.
• Detection by comparison: it compares results returned by the operating system with those obtained through low-level calls - if any differences are detected, a rootkit is present in the system.
• Integrity-based detection: shows the existence of a rootkit by comparing files and memory with a test status that is known to be reliable.

Each of these techniques has its limitations, and for this reason it is highly recommended to integrate various different technologies. It must also be taken into account that some of these rootkits are expressly designed to avoid detection by those antivirus companies that lead the market.

The first line of defense against rootkits consists in preventing them from entering your computer. To do this, please bear in mind the following basic advice on protection against malware:

• Install a good antimalware solution on your computer, and always keep it activated and updated.
• Install a firewall that will protect against unauthorized access to your computer.
• Always ensure that the applications installed on your computer are kept up-to-date, and make sure to install any security patches supplied by manufacturers.

However, the task of protecting yourself against rootkits is not to be taken lightly, and cannot be limited to a series of generic protection measures.

In order to help users to detect the existence of rootkits in their computers and delete them with absolute precision, Panda Security makes available the tool Panda Anti-Rootkit . Use this free utility to detect and delete any possible rootkits in your computer.

The main threats we face are:

Mobile-Threats

Security Threats to mobile devices(Smartphones, PDA) are on the rise, as more sensitive information is stored on them.

Crimeware: the silent epidemic

Malware evolves to focus on obtaining financial returns

Rootkits:

Malware is hidden to increase its useful life span and avoid detection.

Viruses:

All you need to know to understand viruses and other malware.

Spyware

Spyware is perhaps the most worrying of all IT threats, as it intrudes on your privacy without you realizing

Phishing: personal data theft

Have you received an email message from your bank, in which you are asked to verify your account details?

Spam: Unsolicited email messages

Miracle products? Make money easily? Unbeatable mortgage terms? Spam, spam, wonderful spam.

Panda Cloud-computing

Thanks to Collective Intelligence, Panda's exclusive cloud-computing technology, the company's 2010 solutions leverage the knowledge gathered from the community of millions of Panda users around the world. Each new file received is automatically classified within six minutes and the Collective Intelligence servers classify more than 50,000 new malware samples every day. These technologies correlate information on malware received from each computer to continuously improve the protection level for the worldwide community of users. Panda's 2010 solutions have continuous, real-time contact with this vast knowledge base allowing the company to offer users the fastest response against the new malware that appears every day.

The Cloud Security Company

Founded in 1990, Panda Security is the world's leading provider of cloud-based security solutions, with products available in more than 23 languages and millions of users located in 195 countries around the world. Panda Security was the first IT security company to harness the power of cloud computing with its Collective Intelligence technology. This innovative security model can automatically analyze and classify thousands of new malware samples every day, guaranteeing corporate customers and home users the most effective protection against Internet threats with minimum impact on system performance. Panda Security has 56 offices throughout the globe with US headquarters in California and European headquarters in Spain.

source: http://www.pandasecurity.com/homeusers/security-info/types-malware/rootkit/?wbc_purpose=Basicdefault

Ιστογνώσις ΛΤΔ Σχεδίαση και ανάπτυξη ιστοσελίδων και εφαρμογών διαδικτύου

A rootkit is software that enables continued privileged access to a computer, while actively hiding its presence from administrators by subverting standard operating system functionality or other applications. Typically, an attacker installs a rootkit on a computer after first obtaining root-level access, either by exploiting a known vulnerability orcracking a password. Once a rootkit is installed, it allows an attacker to mask the active intrusion and to gain privileged access to a computer by circumventing normalauthentication and authorization mechanisms. Although rootkits can serve a variety of ends, they have gained notoriety primarily as malware, hiding applications that appropriate computing resources or steal passwords without the knowledge of administrators and users of affected systems. Rootkits can target firmware, a hypervisor, thekernel or, most commonly, user-mode applications.

The term rootkit is a concatenation of the "root" user account in Unix operating systems and the word "kit", which refers to the software components that implement the tool. The term has negative connotations through its association with malware.^[1]

Contents [hide] 1 History 2 Uses 3 Types 3.1 User-mode 3.2 Kernel-mode 3.2.1 Boot loader level (Bootkit) 3.3 Hypervisor level 3.4 Hardware/Firmware 4 Installation and cloaking 5 Detection 5.1 Alternative trusted medium 5.2 Behavioural-based 5.3 Signature-based 5.4 Difference-based 5.5 Integrity checking 5.6 Memory dumps 6 Removal 7 Public availability 8 See also 9 Notes 10 References 11 Further reading 12 External links

History

The very first, documented computer virus to target the PC platform in 1986, used cloaking techniques to hide itself; the Brain virus intercepted attempts to read the boot sector, and redirected these to elsewhere on the disk where a copy of the original boot sector was kept.^[2] Over time, DOS cloaking methods became more sophisticated, with advanced techniques including the hooking of interrupt 13 API calls in order to hide modifications to files.^[2]

The term rootkit or root kit originally referred to a maliciously modified set of administrative tools for a Unix-like operating system, which granted "root" access.^[3] If an intruder could replace the standard administrative tools on a system with a rootkit, the intruder could obtain root access over the system whilst simultaneously concealing these activities from the legitimate system administrator. These early rootkits were trivial to detect by using uncompromised tools to access the same information.^[4] Lane Davis and Steven Dake appear to have written the earliest known rootkit in 1990 for SunOS 4.1.1.^[5] An earlier exploit equivalent to a rootkit was perpetrated by Ken Thompson of Bell Labs against a naval laboratory in California to settle a wager. To achieve this, Thompson subverted the C compiler in a Unix distribution and discussed the exploit in the lecture he gave upon receiving theTuring award in 1983.^[6]

The first malicious rootkit for the Windows NT operating system appeared in 1999 with a trojan called NTRootkit created by Greg Hoglund,^[7] followed by HackerDefender in 2003.^[2]

In 2005, Sony BMG included a rootkit program called Extended Copy Protection (XCP) – created by First 4 Internet^[8] – on many of its music CDs^[9], in an attempt to enforceDRM.^[10] Sony BMG at that time included an application on some of their CD's that ostensibly played music CD's, but that silently installed a rootkit without informing nor requesting a user's permission. In addition to the intentional unauthorised modifications made to the target computer, the Sony BMG rootkit would automatically hide any file whose name started with "$sys$". Malware soon appeared that started to take advantage of the free cloaking provided by the Sony BMG permutation, in order to hide fromantivirus software.^[2] Noted software engineer and architect Mark Russinovich, created a tool called RootkitRevealer, with which he was able to discover Sony BMG's rootkit.^[2]Russinovich published this information in his blog, consequently leading to a highly-publicised scandal that subsequently raised the public's awareness of rootkits.^[11] The public relations fallout for Sony BMG was compared by one analyst to the Tylenol Scare.^[12] In light of adverse publicity, Sony BMG released patches to remedy the breaches, but initial attempts failed to remove the flow-on, security vulnerabilities that the rootkit had either created or that were indirectly attributable to it. A resultant class action lawsuit was eventually brought against Sony BMG, in the United States.^[13]

Uses

Modern rootkits for the Windows platform do not elevate access,^[3] but rather are used to make some other software payload undetectable by adding stealth capabilities.^[7]Most rootkits are classified as malware because the payloads they are bundled with are malicious, for example to covertly steal user passwords, credit card information, computing resources, or to conduct other unauthorized activities. A small number are legitimate utility applications—an example of the latter is a rootkit that provides CD-ROM emulation capability allowing video game users to defeat anti-piracy features that require the original installation media.

Rootkits and their payloads have many uses, mostly nefarious:

• Provide an attacker with full access via a back door so the attacker can for example, steal or falsify documents. One of the ways to carry this out is to subvert the login mechanism (such as the /bin/login program on Unix-like systems or GINA on Windows) The replacement appears to function as normal, but also accepts secret login combination that allows an attacker direct access with administrative privileges to a system, bypassing standard authentication and authorization mechanisms.
• Conceal other malware, notably password-stealing key loggers and computer viruses.^[14]
• Conceal cheating in online games from software like Warden.^[15]
• Appropriate the compromised machine as a zombie computer for attacks on other computers. (The attack originates from the compromised system (or network) instead of the attacker's.) "Zombie" computers are typically members of large botnets that can launch denial-of-service attacks and distribute e-mail spam.
• Detect attacks, for example in a honeypot.^[16]
• Enhance emulation software and security software.^[17] Alcohol 120% and Daemon Tools are commercial examples of non-hostile rootkits that are used to defeat copy-protection mechanisms such as SafeDisc and SecuROM. Kaspersky antivirus software also uses techniques resembling rootkits to protect itself from malicious actions. It loads its own drivers to intercept system activity and then prevents other processes from doing harm to itself. Its processes are not hidden, but cannot be terminated by standard methods.
• Anti-theft protection.^[18]
• Enforcement of DRM.

Types

There are at least five types of rootkit, ranging from those at the lowest level in firmware (with the highest privileges), through to the least privileged user-based variants that operate in Ring 3. Hybrid combinations of these may occur spanning, for example, user mode and kernel mode.

User-mode

User-mode rootkits run in Ring 3 as user rather than low-level system processes.^[19] They have a number of possible installation vectors in order to intercept and modify the standard behaviour of APIs. Some inject a library (DLL) in other processes, and are thereby able to execute inside any target process in order to spoof it; others with sufficient privileges simply overwrite the memory of a target application. Injection mechanisms include:^[19]

• Use of vendor-supplied application extensions. For example, Windows Explorer has public interfaces that allow third parties to extend its functionality.
• Interception of messages
• Debuggers
• Exploitation of security vulnerabilities
• Function hooking or patching of commonly used API's, for example to mask a running process or file that resides on a filesystem.

"...since user mode applications all run in their own memory space, the rootkit needs to perform this patching in the memory space of every running application. In addition, the rootkit needs to monitor the system for any new applications that execute and patch those programs’ memory space before they fully execute."^[3]

Kernel-mode

Kernel-mode rootkits run with the highest operating system privileges (Ring 0) by adding additional code or replacing portions of the core operating system, including both thekernel and associated device drivers. Most operating systems support kernel-mode device drivers which execute with the same privileges as the operating system itself.^[20] As such, many kernel mode rootkits are developed as device drivers or loadable modules, such as loadable kernel modules in Linux or device drivers in Microsoft Windows. This class of rootkit has unrestricted security access, but is more difficult to write.^[21] The complexity makes bugs common, and any bugs in code operating at the kernel level may seriously impact system stability, leading to discovery of a rootkit.^[21] One of the first widely known kernel rootkits was developed for Windows NT 4.0 and released inPhrack^[22] in the mid-1990s by Greg Hoglund.^[23]

Kernel rootkits can be especially difficult to detect and remove, because they operate at the same security level as the operating system itself, and are thus able to intercept or subvert operating system operations. Any software, such as antivirus software, running on the compromised system is equally subvertible. In this situation no part of the system can be trusted.

A rootkit can modify data structures in the kernel (direct kernel object modification), it can hook kernel functions in the System Service Descriptor Table (SSDT) or modify the gates between user mode and kernel mode in order to implement its cloaking.^[3]

Boot loader level (Bootkit)

A kernel-mode rootkit variant called a bootkit is used predominantly to attack full disk encryption systems, for example as in the "Evil Maid Attack".^[24] The term bootkit itself was coined by Indian security researchers (Nitin Kumar & Vipin Kumar) who presented it at Blackhat Europe 2007.^[25][26] A bootkit replaces the legitimate boot loader with one controlled by an attacker; typically the malware loader persists through the transition to protected mode when the kernel has loaded. For example, the "Stoned Bootkit"^[27]subverts the system by using a compromised boot loader to intercept encryption keys and passwords. Apart from preventing unauthorized physical access to machines (a particular problem for portable machines), a Trusted Platform Module, configured to protect the boot path, is the only known defense against this attack.

Hypervisor level

Rootkits have been created as Type II Hypervisors in academia only as proofs of concept. By exploiting hardware features such as Intel VT or AMD-V, this type of rootkit runs in Ring -1 and hosts the target operating system as a virtual machine, thereby enabling the rootkit to intercept all hardware calls made by the original operating system.^[4]Unlike normal hypervisors, they do not have to load before the operating system, but can load into an operating system before promoting it into a virtual machine.^[4] A hypervisor rootkit does not have to make any modifications to the kernel of the target in order to subvert it—however that does not mean to say that it cannot be detected by the guest operating system, as timing differences may for example be detectable in CPU instructions.^[4] The "SubVirt" laboratory rootkit, developed jointly by Microsoft andUniversity of Michigan researchers, is an academic example of a virtual machine based rootkit (VMBR),^[28] while Blue Pill is another.

In 2009, researchers from Microsoft and North Carolina State University demonstrated a hypervisor-layer anti-rootkit called Hooksafe that provides generic protection against kernel-mode rootkits.^[29]

Hardware/Firmware

A firmware rootkit uses device or platform firmware to create a persistent malware image in hardware such as a network card, hard drive or the system BIOS.^[19] The rootkit hides in firmware, because it is not usually inspected for code integrity. John Heasman demonstrated the viability of firmware rootkits in both ACPI firmware routines^[30] and in a PCI expansion card ROM.^[31]

In October 2008, criminals tampered with European credit card reading machines before they were installed. The devices intercepted and transmitted credit card details via a mobile phone network.^[32] In March 2009, researchers Alfredo Ortega and Anibal Sacco^[33] published details of a BIOS-level Windows rootkit that was able to survive disk replacement and OS re-installation.^[34][35]

A few months later they found that some laptop BIOSes come with a legitimate preinstalled rootkit known as Computrace LoJack. This is an anti–theft technology system that, as the researchers showed can be turned to malicious purposes.^[36]

Installation and cloaking

Rootkits employ a variety of techniques to gain control of a system; the type of rootkit will also influence the attack vector that is chosen. The most common is to leveragesecurity vulnerabilities. Another approach is to become a Trojan horse, deceiving a computer user into trusting the rootkit's installer as benign—in this case, social engineeringconvinces a user that the rootkit is beneficial.^[21] The installation task is made easier if the principle of least privilege is not applied, since the rootkit then does not have to explicitly request elevated (administrator-level) privileges. Other classes of rootkits can be installed only by someone with physical access to the target system.

The installation of rootkits is commercially driven, with a Pay-Per-Install (PPI) compensation method for distributors.^[37]

Once installed, a rootkit takes active measures to obscure its presence within the host system through subversion or evasion of standard operating system security tools andAPI's used for diagnosis, scanning and monitoring. Rootkits achieve this by modifying the behavior of core parts of an operating system by loading code into other processes, the installation or modification of drivers or kernel modules. Obfuscation techniques include concealing running processes from system monitoring mechanisms and hiding system files and other configuration data.^[38] It is not uncommon for a rootkit to disable the event logging capacity of an operating system in an attempt to hide evidence of an attack. Rootkits can in theory subvert any operating system activities except CPU scheduling.^[39] The "perfect rootkit" can be thought of as similar to a "perfect crime", one that nobody realizes has taken place.

In addition to installing more commonly into Ring 0 (kernel-mode) where they have complete access to a system, rootkits also take a number of measures to ensure their survival against detection and cleaning by antivirus software. These include polymorphism, stealth techniques, regeneration and disabling anti-malware software.^[40]

Detection

The fundamental problem with rootkit detection is that if the operating system has been subverted, particularly by a kernel-level rootkit, it cannot be trusted to find unauthorized modifications to itself or its components.^[39] Actions such as requesting a list of running processes, or a list of files in a directory, cannot be trusted to behave as expected. In other words, rootkit detectors that work while running on infected systems are only effective against rootkits that have some defect in their camouflage, or that run with lower user-mode privileges than detection software in the kernel.^[21] As with computer viruses, the detection and elimination of rootkits is an ongoing struggle between both sides of this conflict.^[39]

Detection can take a number of different approaches, including signatures (e.g. antivirus software), integrity checking (e.g. digital signatures), difference-based detection (comparison of expected vs actual results) and behavioural detection (e.g. monitoring CPU usage or network traffic).

Several products detect some rootkits. Unix offerings include Zeppoo, chkrootkit, rkhunter and OSSEC. For Windows, free detection tools include Microsoft Sysinternals Rootkit Revealer, avast! antivirus, Sophos Anti-Rootkit, F-Secure Blacklight (the first rootkit detector^{[citation needed]}), and Radix. Any rootkit detectors that prove effective ultimately contribute to their own ineffectiveness as malware authors adapt and test their code to escape detection by well-used tools.^{[Notes 1]}

Alternative trusted medium

The best and most reliable method for operating system-level rootkit detection is to shut down the computer suspected of infection, and then to check its storage by bootingfrom an alternative trusted medium (e.g. a rescue CD-ROM or USB flash drive).^[41] The technique is effective because a rootkit cannot actively hide its presence if it is not running.

Behavioural-based

This approach attempts to infer the presence of a rootkit by looking for rootkit-like behaviour. For example, by profiling a system, differences in the timing and frequency of API calls, or in overall CPU utilization can be attributed to a rootkit. The method is complex and is hampered by a high incidence of false positives. Defective rootkits can sometimes introduce very obvious changes, for example the Alureon rootkit which crashed Windows systems after a security update was applied.^[42][43]

Signature-based

Antivirus products rarely catch all viruses in public tests, even though security software vendors incorporate rootkit detection into their products. Should a rootkit attempt to hide during an antivirus scan, a stealth detector may notice; if the rootkit attempts to temporarily unload itself from the system, fingerprint (or signature) detection can still find it. This combined approach forces attackers to implement counter-attack mechanisms ("retro" routines) that attempt to terminate antivirus programs. Signature-based detection methods can be effective against well-published rootkits, but less so against specially crafted, custom root rootkits.^[39]

Difference-based

Another method that can detect rootkits compares "trusted" raw data with "tainted" content returned by an API. For example, binaries present on disk can be compared with their copies within operating memory, or the results returned from file system or Registry APIs can be checked against raw structures on the underlying physical disks^[39][44]—however in the case of the former, some valid differences can be introduced by operating system mechanisms, e.g., memory relocation or shimming. This was the method used by Mark Russinovich's RootkitRevealer tool to find the Sony DRM rootkit.^[2]

Integrity checking

A cryptographic hash function can be used to compute a "fingerprint" or digital signature that can help to detect subsequent unauthorized changes to on-disk code libraries.^[45] However, unsophisticated schemes check only whether the code has been modified since release by the "publisher"; subversion prior to that time is not detectable. The fingerprint must be re-established each time changes are made to the system. The fingerprinting process creates a message digest dependent on every bit in each file being fingerprinted. By recalculating and comparing the message digest at regular intervals, changes in the system can be detected and monitored as long as the original baseline was not created when the malware was already present. More sophisticated rootkits are able to subvert the verification process by presenting an unmodified copy of the file for inspection, or by making modifications in memory rather than on disk. The technique is therefore effective only against the earlist forms of rootkit that simply replaced Unix commands like "ls" in order to mask the presence of a file.

Similarly, detection in firmware can be achieved by computing a cryptographic hash of firmware and comparing hash values to awhitelist of expected values, or by extending the hash value into TPM (Trusted Platform Module) configuration registers, which are later compared to a whitelist of expected values. Code that performs hash, compare, and/or extend operations must also be protected. The notion of an immutable root-of-trust, ensures that a rootkit (or more specifically a bootkit) does not compromise the system at its most fundamental level. A method of rootkit detection using a TPM is described by the Trusted Computing Group.^[46]

Memory dumps

Forcing a kernel or complete memory dump will capture an active kernel-mode or user-mode rookit in the resulting dump file, allowing offline analysis to be performed with a debugger and without the rootkit being able to take any measures to cloak itself. This technique is highly specialised, and may require access to non-public source code or symbols. Memory dumps cannot be used to detect a hyprevisor-based rootkit, which is able to intercept and subvert the lowest-level attempts to read memory.^[4]

Removal

Most rootkits install hooks in user-mode processes;^[19] those that operate at the lowest level of the OS (Ring 0), have system privileges, so booting into Safe Mode on a Windows machine will not usually allow removal. Given the stealth nature of rootkits, some experts believe that the only reliable way to remove them is to re-install the operating system from trusted media.^[47]

A number of vendors of security software offer tools to automatically detect and remove rootkits, typically as part of an antivirus suite. As of 2005, Microsoft's monthly Malicious Software Removal Tool is able to detect and remove some rootkits.^[48][49]

Manual removal is often too difficult for a typical computer user.^[50] Conversely, antivirus and malware removal tools running on an untrusted system may be ineffective against well-written kernel-mode rootkits. Booting an alternate operating system from trusted media can allow an infected system volume to be mounted and potentially safely cleaned, critical data to be copied off, or alternatively, a forensic examination performed.^[51] Lightweight operating systems such as Windows PE, Windows Recovery Console, Windows Recovery Environment, BartPE or Live Distros can be used for this purpose, allowing the system to be cleaned.

Some antivirus scanners can bypass file system APIs, which are vulnerable to manipulation by a rootkit. They access raw file system structures directly and use this information to validate the results from system APIs to identify any differences that may be caused by a rootkit that has subverted the system.^{[Notes 2][52][53][54][55][56]}

More often, manual repair is impractical. Even if its type and nature are known, re-installing the operating system and applications is simpler and quicker. Re-installation time can be greatly reduced by modern drive imaging software, especially when the source image includes necessary hardware drivers and software applications. This is true even if the rootkit is well-known and can be completely removed.^{[citation needed]}

Public availability

Like much malware used by attackers, many rootkit implementations are shared and are easily available on the Internet. It is not uncommon to see a compromised system in which a sophisticated publicly available rootkit hides the presence of unsophisticated worms or attack tools that appear to have been written by inexperienced programmers.

Most of the rootkits available on the Internet are constructed as an exploit or academic "proof of concept" to demonstrate varying methods of hiding things within a computer system and of taking unauthorized control.^[57] Since these are often not fully optimized for stealth, they sometimes leave unintended evidence of their presence. Even so, when such rootkits are used in an attack they are often effective.

 

1. ^ "Glossary of malware terminology". Anti-Spyware Coalition. Retrieved 2010-09-11.
2. ^ ^{a b c d e f} "Rootkits, Part 1 of 3: The Growing Threat". McAfee. 2006-04-17. Retrieved 2010-08-16.
3. ^ ^{a b c d} Windows Rootkit Overview. Symantec. 2006-03-26. Retrieved 2010-08-17.
4. ^ ^{a b c d e} Michael Myers & Stephen Youndt (2009-11-18). An Introduction to Hardware-Assisted Virtual Machine (HVM) Rootkits. Harris Corporation. Retrieved 2010-08-18.
5. ^ Andrew Hay, Daniel Cid, Rory Bray (2008). OSSEC Host-Based Intrusion Detection Guide. Syngress. p. 276. ISBN 159749240X.
6. ^ Thompson, Ken (August 1984). "Reflections on Trusting Trust" (pdf).Communications of the ACM 27 (8).
7. ^ ^{a b} Greg Hoglund, James Butler (2006). Rootkits: Subverting the Windows kernel. Addison-Wesley. p. 4. ISBN 0321294319.
8. ^ "XCP.Sony.Rootkit". Computer Associates. 2005-11-05. Retrieved 2010-08-19.
9. ^ "XCP Titles". Sony BMG. 2006.
10. ^ Mark Russinovich (31 October 2005). "Sony, Rootkits and Digital Rights Management Gone Too Far". Retrieved 2008-09-15.
11. ^ Mark Russinovich (2005-10-31). "Sony, Rootkits and Digital Rights Management Gone Too Far". Microsoft. Retrieved 2010-08-16.
12. ^ "Sony's long-term rootkit CD woes". BBC News. 21 November 2005. Retrieved 2008-09-15.
13. ^ Mark Lyon (06 Feb 2006). "Settlement Notice". Sonysuit.com.
14. ^ Mark Russinovich (June 2005). "Unearthing Root Kits". Windows IT Pro.
15. ^ "World of Warcraft Hackers Using Sony BMG Rootkit". The Register. 2005-11-04. Retrieved 2010-08-23.
16. ^ Steve Hanna (September 2007). Using Rootkit Technology for Honeypot-Based Malware Detection. CCEID Meeting.
17. ^ Russinovich, Mark (6 February 2006). "Using Rootkits to Defeat Digital Rights Management". Winternals. SysInternals. Archived from the original on 31 August 2006. Retrieved 2006-08-13.
18. ^ Alfredo Ortega, Anibal Sacco (2009-07-24). Deactivate the Rootkit: Attacks on BIOS Anti-Theft Technologies. Core Security Technologies. Retrieved 2010-09-16.
19. ^ ^{a b c d} Aditya Kapoor and Ahmed Sallam (2007-04-03). "Rootkits Part 2: A Technical Primer". McAfee. Retrieved 2010=08-14.
20. ^ The 64-bit version of Windows XP and Server 2008 are a notable exception "Driver Signing Requirements for Windows". Microsoft. Retrieved 2008-07-06.
21. ^ ^{a b c d} "Understanding Anti-Malware Technologies". Microsoft. Retrieved 2010-08-17.
22. ^ issue 55
23. ^ Rootkit Evolution by Alisa Shevchenko (1 September 2008), An Overview of Unix Rootkits by Anton Chuvakin (February 2003)
24. ^ Bruce Schneider (23 October 2009). ""Evil Maid" Attacks on Encrypted Hard Drives". Retrieved 2009-11-07.
25. ^ "Black Hat Europe 2007 Topics and Speakers". March 2007.
26. ^ Nitin Kumar (23 October 2009). "BOOT KIT Custom boot sector based Windows 2000/XP/2003 Subversion". Retrieved 2009-11-07.
27. ^ Peter Kleissner (19 October 2009). "Stoned Bootkit". Insecurity Systems. Retrieved 2009-11-07.
28. ^ "SubVirt: Implementing malware with virtual machines" (PDF). University of Michigan, Microsoft. 3 April 2006. Retrieved 2008-09-15.
29. ^ Zhi Wang, Xuxian Jiang, Weidong Cui & Peng Ning (11 August 2009) (pdf Protection). Countering Kernel Rootkits with Lightweight Hook. Microsoft/North Carolina State University. Retrieved 2009-11-11.
30. ^ Implementing and Detecting an ACPI Rootkit by John Heasman, presented at BlackHat Federal, 2006.
31. ^ Implementing and Detecting a PCI Rootkit by John Heasman, November 15, 2006.
32. ^ Austin Modine (10 October 2008). "Organized crime tampers with European card swipe devices: Customer data beamed overseas". The Register. Retrieved 2008-10-13.
33. ^ Sacco, Anibal; Ortéga, Alfredo. "Persistent BIOS infection". Core Security Technologies. Retrieved 2009-10-06.
34. ^ Dan Goodin (24 March 2009). "Newfangled rootkits survive hard disk wiping". The Register. Retrieved 2009-03-25.
35. ^ Phrack Magazine #66
36. ^ Sacco, Anibal; Ortéga, Alfredo (2009). "Deactivate the Rootkit". Black Hat USA.
37. ^ Aleksandr Matrosov & Eugene Rodionov (2010-06-25). "TDL3: The Rootkit of All Evil?". ESET. Retrieved 2010-08-17.
38. ^ Brumley, David (16 November 1999). "invisible intruders: rootkits in practice".USENIX.
39. ^ ^{a b c d e} "Hacking Exposed Malware and Rootkits". Massachusetts Institute of Technology. Retrieved 2010-08-14.
40. ^ Defeating Rootkits and Keyloggers. Trlokom. 2006-07-05. Retrieved 2010-08-17.
41. ^ Josh Harriman (2007-10-19). A Testing Methodology for Rootkit Removal Effectiveness. Dublin, Ireland: Symantec Security Response. Retrieved 2010-08-17.
42. ^ Mircea Cuibotariu (2010-02-12). "Tidserv and MS10-015". Symantec. Retrieved 2010-08-19.
43. ^ "Restart Issues After Installing MS10-015". Microsoft. 2010-02-11. Retrieved 2010-10-05.
44. ^ "Strider GhostBuster Rootkit Detection". Microsoft Research. Retrieved 2010-08-14.
45. ^ "Signing and Checking Code with Authenticode". Microsoft. Retrieved 2008-09-15.
46. ^ "Stopping Rootkits at the Network Edge" (PDF). Trusted Computing Group. 4 January 2007. Retrieved 2008-07-11.
47. ^ Ellen Messmer (2006-08-26). "Experts Divided Over Rootkit Detection and Removal". NetworkWorld.com. Retrieved 2010-08-15.
48. ^ Kurt Dillard (2005-08-03). "Rootkit battle: Rootkit Revealer vs. Hacker Defender".
49. ^ "The Microsoft Windows Malicious Software Removal Tool helps remove specific, prevalent malicious software from computers that are running Windows 7, Windows Vista, Windows Server 2003, Windows Server 2008, or Windows XP". Microsoft. 2010-09-14.
50. ^ "Rootkits Part 2: A Technical Primer". McAfee. 2007-04-03. Retrieved 2010-08-17.
51. ^ Steve Anson, Steve Bunting (2007). Mastering Windows Network Forensics and Investigation. John Wiley and Sons. pp. 73–74. ISBN 0470097620.
52. ^ Posted by Flashlight (30 April 2007). "Tech Loop: Rootkits: The next big enterprise threat?". Techloop.blogspot.com. Retrieved 2009-04-07.
53. ^ "Security Watch: Rootkits for fun and profit - CNET Reviews". Reviews.cnet.com. 19 January 2007. Retrieved 2009-04-07.
54. ^ Sponsored by Dell. "Six ways to fight back against botnets - Business Center". PC World. Retrieved 2009-04-07.
55. ^ 12:00 AM. "Handling Today's Tough Security Threats: Rootkits - Malicious Code - STN Peer-to-Peer Discussion Forums". Forums.symantec.com. Retrieved 2009-04-07.
56. ^ Hultquist, Steve (30 April 2007). "Rootkits: The next big enterprise threat? | Security Central". InfoWorld. Retrieved 2009-04-07.
57. ^ Larry Stevenson, Nancy Altholz (2007). Rootkits for Dummies. John Wiley and Sons Ltd. p. 175. ISBN 0471917109.

Ιστογνώσις ΛΤΔ Σχεδίαση και ανάπτυξη ιστοσελίδων και εφαρμογών διαδικτύου

We hear the same terms bandied about whenever a popular site gets hacked. You know… SQL Injection, cross site scripting, that kind of thing. But what do these things mean? Is hacking really as inaccessible as many of us imagine; a nefarious, impossibly technical twilight world forever beyond our ken?

Not really.

 

When you consider that you can go to Google right now and enter a search string which will return you thousands of usernames and passwords to websites, you realize that this dark science is really no mystery at all. You'll react similarly when you see just how simple a concept SQL Injection is, and how it can be automated with simple tools. Read on, to learn the basics of how sites and web content management systems are most often hacked, and what you can do to reduce the risk of it happening to you.

 

SQL Injection

SQL Injection involves entering SQL code into web forms, eg. login fields, or into the browser address field, to access and manipulate the database behind the site, system or application.

 

When you enter text in the Username and Password fields of a login screen, the data you input is typically inserted into an SQL command. This command checks the data you've entered against the relevant table in the database. If your input matches table/row data, you're granted access (in the case of a login screen). If not, you're knocked back out.

 

The Simple SQL Injection Hack

 

In its simplest form, this is how the SQL Injection works. It's impossible to explain this without reverting to code for just a moment. Don't worry, it will all be over soon.

 

Suppose we enter the following string in a Username field:

 

' OR 1=1

 

The authorization SQL query that is run by the server, the command which must be satisfied to allow access, will be something along the lines of:

 

SELECT * FROM users WHERE username = ‘USRTEXT '

AND password = ‘PASSTEXT’

 

…where USRTEXT and PASSTEXT are what the user enters in the login fields of the web form.

 

So entering `OR 1=1 — as your username, could result in the following actually being run:

 

SELECT * FROM users WHERE username = ‘' OR 1=1 — 'AND password = '’

 

Two things you need to know about this:

['] closes the [username] text field.

 

'' is the SQL convention for Commenting code, and everything after Comment is ignored. So the actual routine now becomes:

 

SELECT * FROM users WHERE username = '' OR 1=1

 

1 is always equal to 1, last time I checked. So the authorization routine is now validated, and we are ushered in the front door to wreck havoc.

 

Let's hope you got the gist of that, and move briskly on.

 

Brilliant! I'm gonna go hack me a Bank!

Slow down, cowboy. This half-cooked method won't beat the systems they have in place up at Citibank, evidently.

 

But the process does serve to illustrate just what SQL Injection is all about — injecting code to manipulate a routine via a form, or indeed via the URL. In terms of login bypass via Injection, the hoary old ' OR 1=1 is just one option. If a hacker thinks a site is vulnerable, there are cheat-sheets all over the web for login strings which can gain access to weak systems. Here are a couple more common strings which are used to dupe SQL validation routines:

 

username field examples:

 

admin'—

') or ('a'='a

”) or (“a”=”a

hi” or “a”=”a

… and so on.

 

Backdoor Injection- Modules, Forums, Search etc.

Hacking web forms is by no means limited exclusively to login screens. A humble search form, for instance, is necessarily tied to a database, and can potentially be used to amend database details. Using SQL commands in search forms can potentially do some extremely powerful things, like calling up usernames and passwords, searching the database field set and field names, and amending same. Do people really get hacked through their search forms? You better believe it. And through forums, and anywhere else a user can input text into a field which interacts with the database. If security is low enough, the hacker can probe the database to get names of fields, then use commands like INSERT INTO, UNION, and so forth to get user information, change product prices, change account settings/balances, and just about anything else… depending on the security measures in place, database architecture and so on.

 

So you can have security locked down at the login, but poor security on other forms can still be exploited. Unfortunately this is a real worry regarding 3rd party modules for Web CMS products which incorporate forms, and for CMS products these 3rd party modules are often the weakest links which allows hackers access to your database.

 

Automated Injection

There are tools to automate the process of SQL Injection into login and other fields. One hacker process, using a specific tool, will be to seek out a number of weak targets using Google (searching for login.asp, for instance), then insert a range of possible injection strings (like those listed above, culled from innumerable Injection cheat-sheets on the Web), add a list of proxies to cover his movements, and go play XBox while the program automates the whole injection process.

 

Remote Injection

This involves uploading malicious files to inject SQL and exploit other vulnerabilities. It's a topic which was deemed beyond the scope of this report, but you can view this PDF if you'd like to learn more.

 

SQL Injection in the Browser Address Bar

Injections can also be performed via the browser address bar. I don't mean to have a pop at Microsoft, but when it comes to such vulnerabilities, HTTP GET requests with URLs of the following form are most often held to be vulnerable:

 

http://somesite.com/index.asp?id=10

 

Try adding an SQL command to the end of a URL string like this, just for kicks:

http://somesite.com/index.asp?id=10 AND

 

See if both articles come up. Don't shoot your webmaster just yet if it's your own site and you get two articles popping up: this is real low-level access to the database. But some such sites will be vulnerable. Try adding some other simple SQL commands to the end of URLs from your own site, to see what happens.

 

As we saw above, access to the database raises a number of interesting possibilities. The database structure can be mapped by a skilled hacker through ill-conceived visibility of error messages — this is called database footprinting — and then this knowledge of table names and so forth can be used to gain access to additional data. Revealing error messages are manna - they can carry invaluable table name and structural details.

 

The following illustrative string is from Imperva.

 

http://www.mydomain.com/products/products.asp?productid=123 UNION SELECT username, password FROM USERS

 

There are vast swathes of information on SQL Injection available, here are a couple of good sources:

 

GovernmentSecurity.org

SecurityDocs.com

Cross Site Scripting (XSS)

XSS or Cross Site Scripting is the other major vulnerability which dominates the web hacking landscape, and is an exceptionally tricky customer which seems particularly difficult to stop. Microsoft, MySpace, Google… all the big cahunas have had problems with XSS vulnerabilities. This is somewhat more complicated than SQL Injection, and we'll just have a quick look to get a feel for it.

 

XSS is about malicious (usually) JavaScript routines embedded in hyperlinks, which are used to hijack sessions, hijack ads in applications and steal personal information.

 

Picture the scene: you're there flicking through some nameless bulletin board because, yes, you really are that lazy at work. Some friendly girl with broken English implores you to get in touch. 'Me nice gurl', she says. You've always wondered where those links actually go, so you say what the hell. You hover over the link, it looks like this in the information bar:

 

[%63%61%74%69%6f%6e%3d%274%74%70%3a%2f%2f%77%7…]

 

Hmmm…what the hell, let's give it a bash, you say. The one thing I really need right now is to see an ad for cheap Cialis. Maybe the linked page satisfies this craving, maybe not. Nothing dramatic happens when you click the link, at any rate, and the long day wears on.

 

When a link in an IM, email, forum or message board is hexed like the one above, it could contain just about anything. Like this example, from SandSprite, which helps steal a session cookie, which can potentially be used to hijack a session in a web application, or even to access user account details.

 

Stealing cookies is just the tip of the iceberg though — XSS attacks through links and through embedded code on a page or even a bb post can do a whole lot more, with a little imagination.

 

XSS is mostly of concern to consumers and to developers of web applications. It's the family of security nightmares which keeps people like MySpace Tom and Mark Zuckerberg awake at night. So they're not all bad then, I suppose…

 

For additional resources on this topic, here's a great overview of XSS (PDF) and just what can be accomplished with sneaky links. And here's an in-depth XSS video.

 

Authorization Bypass

Authorization Bypass is a frighteningly simple process which can be employed against poorly designed applications or content management frameworks. You know how it is… you run a small university and you want to give the undergraduate students something to do. So they build a content management framework for the Mickey Bags research department. Trouble is that this local portal is connected to other more important campus databases. Next thing you know, there goes the farm

 

Authorization bypass, to gain access to the Admin backend, can be as simple as this:

 

Find weak target login page.

View source. Copy to notepad.

Delete the authorization javascript, amend a link or two.

Save to desktop.

Open on desktop. Enter anything into login fields, press enter.

Hey Presto.

Here's a great video of a White Hat going through the authorization-bypass process on YouTube. This was done against a small university's website. It's a two-minute process. Note that he gets into the User 1 account, which is not the Admin account in this case. Is Admin User 1 on your User table?

 

Google Hacking

This is by far the easiest hack of all. It really is extraordinary what you can find in Google's index. And here's Newsflash #1: you can find a wealth of actual usernames and passwords using search strings.

 

Copy and paste these into Google:

 

inurl:passlist.txt

inurl:passwd.txt

…and this one is just priceless…

“login: *” “password= *” filetype:xls

 

Such strings return very random results, and are of little use for targeted attacks. Google hacking will primarily be used for finding sites with vulnerabilities. If a hacker knows that, say, SQL Server 2000 has certain exploits, and he knows a unique string pushed out by that version in results, you can hone in on vulnerable websites.

 

For specific targets Google can return some exceptionally useful information: full server configurations, database details (so a good hacker knows what kind of injections might work), and so forth. You can find any amount of SQL database dumps as well (fooling around with a Google hack while preparing this article, I stumbled across a dump for a top-tier CMS developer's website). And a vast amount more besides.

 

johnny.ihackstuff.com is the man to go to for Google hacks. One interesting one I toyed with invited me to the Joomla! install page for dozens of sites… people who had uploaded Joomla!, decided against installing it, and subsequently had either left the domain to rot, or else set a redirect on the page to, say, their Flickr account (in one case). Allowing anybody to walk in and run through the installer. Other query strings target unprotected email/IM archives, and all sorts of very sensitive information. What fun we can have!

 

Password Cracking

Hashed strings can often be deciphered through 'brute forcing'. Bad news, eh? Yes, and particularly if your encrypted passwords/usernames are floating around in an unprotected file somewhere, and some Google hacker comes across it.

 

You might think that just because your password now looks something like XWE42GH64223JHTF6533H in one of those files, it means that it can't be cracked? Wrong. Tools are freely available which will decipher a certain proportion of hashed and similarly encoded passwords.

 

A Few Defensive Measures

If you utilize a web content management system, subscribe to the development blog. Update to new versions soon as possible.

Update all 3rd party modules as a matter of course — any modules incorporating web forms or enabling member file uploads are a potential threat. Module vulnerabilities can offer access to your full database.

Harden your Web CMS or publishing platform. For example, if you use WordPress, use this guide as a reference.

If you have an admin login page for your custom built CMS, why not call it 'Flowers.php' or something, instead of “AdminLogin.php” etc.?

Enter some confusing data into your login fields like the sample Injection strings shown above, and any else which you think might confuse the server. If you get an unusual error message disclosing server-generated code then this may betray vulnerability.

 

Do a few Google hacks on your name and your website. Just in case…

When in doubt, pull the yellow cable out! It won't do you any good, but hey, it rhymes.

 

Ιστογνώσις ΛΤΔ Σχεδίαση και ανάπτυξη ιστοσελίδων και εφαρμογών διαδικτύου

The 10 Most Dangerous Things You Can Do Online

1. Opening attachments from unknown senders is the riskiest thing you can do. Research shows that email attachments remain the number one means by which worms and viruses propagate.

2. Installing unauthorized applications such as file-sharing tools (Limewire, Azureus and other Bit Torrent clients) - Illegal downloads are against university policy and they, like email attachments, are simply another means by which "bad" files get on your computer.

3. Number three is disabling security tools. While trouble-shooting slow applications, many users will turn off their anti-virus and/or firewall. The problem is they forget to turn them back on!

4. While most people may know not to open email attachments, many don't realize that dangers can lie in the body of an email too. HTML mail or mails that contain embedded photos are just as dangerous. Embedded images and PDFs can contain malicious code that is harmful.  So be sure not to open any unsolicited/suspicious mail.

5. Surfing questionable sites is always dangerous. You will find, more times than not, that porn, gambling and sites that host illegal content are the same sites that install malicious software on your computer.

6. Giving/lending passwords - Don't be too trusting of fellow students and colleagues.  Keep your BroncoName and BroncoPassword to yourself.  Exposing it means you're exposing salary, banking, class registration information, etc.!

7. Browsers are quickly becoming some of the larger vulnerabilities in computing. Adware and spyware are written specifically to exploit Internet Explorer and Firefox. So avoid surfing sites that you don't already know and stick with the ones you trust.

8. Wireless networks are a huge risk because they are shared. The guy sitting across from you could be a hacker, stealing your password. Make sure you leave the firewall turned on and avoid sending passwords through the air. Only use encrypted wireless networks as they offer higher levels of protection.

9. Filling in web forms and registration pages - There may be nobody behind you watching you as you type. But that doesn't stop a keylogger (a program or device that logs all your key-strokes) from collecting your information. Try to keep all sensitive material on your own machine (the one that you maintain and protect), and keep it off those public computers.

10. Avoid social networking sites. Sites like MySpace and Facebook are a dream for thieves and stalkers. They allow anyone the ability to gather information about you that may aid them in stealing your identity. Think twice before you post any sensitive or damaging information on these sites.

Top 10 BroncoPassword Tips

1. Never tell your password to anyone!
2. Never write down your password.
3. Make your password hard to guess — do not use the name of your pet (or your child).
4. Avoid using words found in a dictionary.
5. Never write down your password.
6. The more random your password is, the better.
7. Be sure that you don't use personal identifiers in your password (like your name or BroncoName).
8. Never write down your password.   
9. Take responsibility for your BroncoName and BroncoPassword.
10. And never tell your password to anyone!

A compromised password not only puts your own information at risk, it may also expose sensitive campus data and systems. Click here to find more tips and info on creating strong passwords.

Top 10 Tips for Identity Theft Protection

1. Protect your Social Security Number (SSN): minimize use of your SSN and don’t carry your Social Security card in your wallet.
2. Don't be "hooked" by phishing email scams. Don’t respond to requests to verify your account number or password. Click here to learn more.
3. Shred often - shred or tear up documents with personally identifiable information before you throw them away, including convenience checks and credit card offers.
4. Shield your computer from viruses and spyware: follow our Getting Started Guide and use strong passwords.
5. Click with caution. Read a website’s privacy policy, look for opportunities to opt out of information sharing and only enter personal information on secure web pages with “https” in the address bar and a padlock symbol at the bottom of the browser window.
6. Check your bills and bank statements: for any unauthorized charges or withdrawals. Report unauthorized use immediately.
7. Stop pre-approved credit offers; they make a tempting target for identity thieves who steal your mail. Remove your name from credit bureau marketing lists by visiting https://www.optoutprescreen.com or calling 1-888-5OPTOUT begin_of_the_skype_highlighting            1-888-5OPTOUT      end_of_the_skype_highlighting.
8. Ask questions: whenever you are asked for personal information that seems inappropriate for the transaction, ask how the information will be used, if it will be shared and how it will be protected. Not satisfied with the answers? Do business elsewhere.
9. Monitor your credit report: you’re entitled to free credit reports at http://www.annualcreditreport.com.
10. Take this Quiz: see how you stack up in this Identity Theft IQ Quiz provided by the Privacy Rights Clearinghouse

source: http://www.csupomona.edu/~ehelp/security/security_tips.html.