Using idle scanning can reveal sensitive configuration information about targets via a side channel. Not only can this type of scan show services that might otherwise be invisible, it is also completely passive. This means that the target of the scan will never observe traffic from the actual source of the scans. Only the idle host will be aware of any contact with the scanning machine. This can allow attackers to perform reconnaissance to either perform a completely hidden scan, for instance by using an idle zombie in a third party organization making it extremely difficult to trace the origin of the scan, or to map trust relationships in an organization by using a zombie target within the target organization.
Nikto is an extremely popular web application vulnerability scanner. Web application vulnerability scanners are designed to examine a web server to find security issues. Identifying security problems proactively, and fixing them, is an important step towards ensuring the security of your web servers. Nikto checks for a number of dangerous conditions and vulnerable software. Running Nikto on a regular basis will ensure that you identify common problems in your web server or web applications. Because most web servers host a number of web applications, with new software deployed over time, it is a good idea to run a scanner like Nikto against your servers on a routine basis.
Metasploit is a well known penetration testing tool that can be used quite effectively to test new exploits and plan defensive strategies. Using Java run time exploits is a perfect example. Metasploit allows defensive practitioners to test exploits and evaluate mitigations in a controlled environment to make well reasoned and grounded recommendations for mitigation to 0 day vulnerabilities.
I'm often asked to explain information security to non technical computer users and when I do it generally overwhelms them so that instead of anxiety they react with numbness. The problem is that information security is largely a technical problem, with technical solutions. Anyone who advocates user training is blissfully ignorant of the wealth of academic research that clearly demonstrates user education is fairly useless in the face of modern security threats.
About XSSCross site scripting (XSS) is a pervasive problem in Drupal because the development team takes the approach that data should be sanitized upon display rather than input. The rational for this decision is to maintain data integrity despite translation or manipulation. This is a somewhat non-standard approach in web application circles and leads to no small amount of confusion about "trusted" data sources and the display of data. In general, all user supplied data must be filtered upon display. Drupal provides several useful API calls to facilitate this transformation. These include, but are not limited to, filter_xss(), check_plain(), and the t() function. Drupal output sanitization functions must be used carefully and properly, however, especially the t() function as misuse can introduce unexpected vulnerabilities.
When reviewing code it is often easy to find flaws when developers attempt to filter input by excluding values that they suspect may be bad. This default accept policy, that it to accept everything by default, then deny specific dangerous inputs, is especially problematic for several reasons. Firewall designers have know about the wisdom of a default deny policy for decades, but such knowledge seems to come slow to programmers intent on pushing boundaries often at the expense of lessons from history.
Luc de Louw's Blog recently presented an article on hardening RHEL systems based on critique and updates of the NSA's seminal, and 200 page, "Guide to the Secure Configuration of Red Hat Enterprise Linux 5" (http://www.nsa.gov/ia/_files/os/redhat/rhel5-guide-i731.pdf). Luc's post gives some extra guidance on security configuration that I think is well reasoned and worth noting. I think it also points to the fundamental problem with Linux security in general, however.
When evaluating content management systems (CMS) it is extremely important to include criteria covering security considerations. CMS'es are complex, and extremely powerful web applications, and as such present interesting security challenges. Although many of these challenges are not unique to CMS systems, they are often overlooked when performing product evaluations. CMS'es are quickly becoming the de facto standard for deploying web based information systems – from websites to complex web applications.
Drupal 6 provides the syslog module by default which allows Drupal to write some log entries directly to the system log. OSSEC open source host based intrusion detection system is a perfect system for monitoring events in a system log. By implementing a custom decoder and a few rules you can easily modify your OSSEC installation to monitor your Drupal site for common attacks, including brute force attacks or other malicious activity.
Cross site request forgery (CSRF (pronounced sea-surf) or XSRF) is a trust exploitation that shares many similarities with cross site scripting (XSS). Drupal implements a robust forms API that helps protect against XSRF so these types of vulnerabilities are uncommon in Drupal. Unfortunately they do still exist with certain module implementations. It is important to understand the causes of XSRF in Drupal in order to spot potential problems in module code.
Drupal provides robust, and largely ignored, XML remote procedure call (RPC) functionality. This functionality is available through the xmlrpc.php file that is available at the Drupal root in any installation. Any module can provide a hook into the XMLRPC interface by providing a moduleName_xmlrpc() function. However, some XMLRPC functionality allows malicious attackers to launch a brute force attack against a site without causing any login failure messages to appear in the site logs.
Drupal provides robust, and largely ignored, XML remote procedure call (RPC) functionality.
Cross site scripting (XSS) vulnerabilities can have an incredibly damaging effect on a Drupal site. In addition to introducing malware, redirecting users, or other nefarious interactions, arbitrary script on a Drupal site can actually interact with the system allowing an XSS vulnerability to escalate into an account compromise or even a site compromise. Finding XSS vulnerabilities in Drupal modules can be a tricky task, but there are some general guidelines you can follow to ease the task.
Securing a default Drupal installation takes some work and forethought. Drupal has a number of extremely helpful features that enable users to do some powerful things, but many of these features can be used for malicious purposes in the wrong hands. Some of the Drupal features that were intended to make users lives easier are extremely functional, but others only serve a small minority. The features that open vulnerability gaps that are not employed by most Drupal users should be disabled, or removed entirely. Many of the default Drupal features present vulnerabilities that can only be mitigated through careful configuration.
Drupal sites typically grant elevated privileges to authenticated users and special privileges to site administrators. If an attacker can compromise account credentials to a Drupal site then they can easily elevate their privileges, perhaps gaining the ability to write arbitrary HTML or even PHP. Once an attacker compromises a valid Drupal account they can begin to leverage their new access to do more damage to the target site, perhaps even to hijack the entire web server process. Drupal uses form posts with predictable formats for user authentication and no defensive measures to prevent a brute force, or password guessing, attack. Furthermore, some Drupal sites facilitate the easy capture of user accounts for the creation of a targeted user list to increase the likelihood of a successful brute force attack.
The Drupal content management system (CMS) is a wonderful for maintaining multiple, user driven and owned websites. From a security context, however, Drupal can present a challenge. Much of Drupal's power comes from its high degree of customization and the fact that users need nothing more than a web browser to maintain a website. Drupal is also described as �community plumbing,� a driving principle that seeks to include the input of website visitors as contributors. These factors combined make Drupal a perfect target for enterprising attackers who wish to post malicious content, spam, and other undesirable material to your websites. Fortunately Drupal includes several technical safeguards to prevent your websites from being compromised, but much of Drupal customizable power, if utilized incorrectly, can actually assist attackers in hijacking your sites.
As a software developer with over 7 years of experience you'd think one of the things I could easily do would be to gage how long it would take me to complete a certain project. The truth of the matter is I couldn't. Of course I can take a stab at an estimate, using rough remembrance of my past projects, but this is obviously a very poor guide. Unfortunately nobody ever told me to track my time on projects, until recently.
Keep your Drupal installation and modules up to date. Subscribe to the security mailing list at http://drupal.org/security. When you see announcement be sure to upgrade in a timely manner.
There are two main types of cell phones used in the US. These are GSM (Global System for Mobile Communications) and CDMA/iDEN. GSM phones utilize SIM cards (Subscriber Identity Module) while CDMA/iDEN do not. As of this writing only T-Mobile and Cingular utilize GSM in the US, Sprint and Verizon use CDMA/iDEN.
The Drupal Node2Node module was recently flagged by the Drupal security team as insecure and unmaintained (http://drupal.org/node/572852). The module was subsequently unpublished by Drupal, removing it from the main site downloads. This means that the module is no longer supported by Drupal. The Drupal security team announcement did not specify what vulnerabilities were contained within the Node2Node module, but a quick glance at the code and some testing quickly reveals a cross site scripting (XSS) vulnerability in the Node2Node module. To exploit the vulnerability simply follow the proof of concept steps below:
Consider the typical LAMP stack. You've got your trusty PHP web application running on Apache, connecting to your MySQL database all centralized on one easy to manage machine that you can SSH to. This architecture is compact, it's convenient, and it's stable. Now, for a moment, consider this architecture from a security standpoint and your perception becomes quite different. You've got all your eggs in one basket. A compromise at almost any level of the LAMP stack can lead to compromises on any other level. If an intruder compromises the web application, they might be able to get file system access, read files, including the plain text MySQL database files, or modify logs. If one of your SSH accounts is compromised via brute force your entire server is in jeopardy � your web sites, your databases, even your logs could be tampered with.
Many PHP based web applications use md5 hashing in order to obscure stored passwords. At first glance this seems like an effective security measure, however upon further examination it becomes clear that this approach does little to secure a password. Let us assume that an attacker somehow captures the md5 hash of a users password. This could happen in many ways, the most obvious being a SQL injection that reveals the password.
JPEG image format is a widespread encoding standard for digital imagery and photography. JPEG contains the well documented Exif metadata specification that allows textual information to be encoded into the image itself. This creates a powerful, and portable, extension to image data that aids in organization and indexing. Exif does introduce some significant security and privacy implications and it is important to understand how metadata works and is encoded into imagery in order to protect your data.
Writing a buffer overflow attack against a Windows program present several challenges that make it a bit more difficult than writing exploits on a Linux platform. In addition to not having popular tools such as gdb (the GNU Debugger) an attacker is faced with a closed box. Not only are most Windows applications closed source, but the operating system itself doesn't provide much transparency. When taken together this makes an attackers job fairly daunting.
The Drupal Suggested Terms module is a convenience module that helps a content producer by presenting a hyperlinked list of taxonomy terms that can be clicked to populate category vocabulary. However, in versions prior to 5.x-1.2 a cross site scripting (XSS) vulnerability exists. This vulnerability was announced on June 25, 2008 in SA-2008-039 and requires that a malicious user be able to create or edit content using the suggested terms module.
Drupal is a wonderful Content Management System (CMS) that comes with a lot of extensible functionality. While the Drupal security team does a great job of making sure the core modules distributed with Drupal are secure, there are a host of third party contributed modules that often contain security problems. In this tutorial I'm going to pick on one module in particular and show you how to deduce security holes based on announcements to the Drupal security list.
The purpose of this tutorial is to provide a basic introduction to incident response. This document is by no means comprehensive, it is intended as a starting point, and provides a framework for approaching a broad spectrum of security incidents.
Arbitrary code execution vulnerabilities are the most damaging sorts of vulnerabilities to find in web applications. A web application that exposes an attacker to a direct connection provides an easy route for system compromise. At the very least this sort of application will ensure a server compromise. Discovering, and preventing, code execution vulnerabilities is critical for developers in order to protect the systems that host their web applications.
File upload vulnerabilities (and local file disclosure vulnerabilities) are some of the most devastating vulnerabilities in PHP applications. Learning how to spot these sort of vulnerabilities, and prevent them, is critical to web application developers. In this, the fifth installment of the web hacking lessons, we explore how file file upload and local file inclusion vulnerabilities can be exploited to compromise a web application's security.
PHP file include vulnerabilities are some of the most destructive that an attacker can exploit. By allowing an attacker to include remote PHP code in the compilation of your scripts, or by allowing the attacker to include arbitrary code from your filesystem, a web application can malfunction badly and lead to a system compromise. This article is the fourth installment of the Web Hacking Lesson series that accompanies a sample PHP/MySQL application that can be downloaded for live exercises.
Brute forcing a web application is a method to bypass traditional authentication checks. Although brute forcing may seem like an attack that a PHP developer might not be able to mitigate, it is actually an important consideration when developing web applications.
SQL injection attacks bear many of the same fundamental hallmarks as XSS attacks. At its core and SQL injection abuses the web application to introduce unintended functionality. SQL injection aims to escape out of the confines of a developer crafted SQL statement to alter the SQL. This tutorial/exercise demonstrates using SQL injection to bypass authentication. It also suggests several ways to mitigate the threat of SQL injection or prevent it altogether.
This is the first in a series of training articles that goes hand in hand with a test site that should be downloaded and installed by the reader. The training is designed to help you gain experience with methods used by attackers to compromise web applications so you can build better applications and learn to defend your applications more successfully. This initial lesson covers Cross Site Scripting (XSS) attacks and includes instructions on downloading and installing the test application.
Netcat is an oft maligned program that can easily be used for many interesting and useful purposes. While many admins have heard of netcat, it is usually in the context of detecting rootkits or evidence of intrusion. The fact that netcat is a favorite tool among malicious hackers does a great disservice to the tool, but it also demonstrates its utility.
User input validation is consistently one of the most widespread problems in software contributing to security incidents. Often times software developers assume that users will only provide valid user input, or that users will only provide user input in one form. Many web application developers fail to understand the hostile environment their code will be exposed to. Gathering input via a form doesn't guarantee that the only data passed to the form processing script will be passed by the form. Developers should not expect that input type, names, or formats will match those laid out in the form the developers produce.
Exploiting form input validation failures is one of the easiest ways to leverage control of a web server through an online application. Being able to pull off this kind of attack requires a fairly comprehensive understanding of the methods used, as well as the weaknesses of various online applications. While there are myriad weaknesses in most common web applications, exploiting form input is one of the most common ways attackers use to gain control of a server process.
A discussion of preventative measures PHP application developers can take when deploying their programs on a Linux filesystem. This includes setting proper file permissions as well as protecting files from unwanted exposure on the web.
It has been a long time since a relevant buffer overflow tutorial was written. While the classics still serve as wonderful guides I thought it might be time to put together an up to date tutorial that incorporated many of the techniques of other tutorials along with a few things I've learned on my own.
A short instructional article on using the Command prompt. Some basic tools as well as a few tips and tricks I've found useful over the years.
Simple guide to security for home users. Covers easy steps you can take to protect your home system.
An examination of the how-to steps taken by many system crackers. Also includes some information on learning about system security, including how to set up a lab environment.
Where to go to look for more information on HTML
Using comments and tables.
Including images in your web pages, including getting them and generating new ones.
Using lists in HTML
Building a template, formatting text, and using links in your HTML pages.
Instructions on accessing unprotected Netbios shares on a Windows machine from Linux.
A rather long white paper on all sorts of aspects of computer security. Developed for a training program on computer security.
Cold Fusion web server security do's, don's and how-to's. Includes a discussion of accessing the CFIDE administrator function on Cold Fusion servers and RDS security.
A list of simple steps you can take to significantly increase the level of security on a default installation of Windows 2000.
Getting some server functionality from your Windows desktop with a home operating system.
Finding open ports on a remote Unix or Linux machine.
Breaking in - using a brute forcer to find a username and password for the target system. This article uses brutus specifically (from hoobie.net) to break into a Windows 2000 FTP site.
Automating hacking tools, making a program to do what we did by hand in Tutorial 9. Includes the code for madirish.bat.
Finding and exploring Windows shares by hand.
Finding a target and seeing what is available on target systems (target enumeration).
Compiling raw C code (for exploits).
Getting started with Unix/Linux, some basic commands you will need to know.
A deeper look at TCP/IP and ports.
Getting connected and getting online.
Understanding your tools, a brief look at computer components and hardware, what they all do and why.
A quick look at TCP/IP, ports, and what goes on across the internet.
Getting started as a hacker, what system to choose and why.
A list of computer security terminology to get you started.
Removing a file from your computer is not as simple as just moving it to the 'Recycle Bin', read up on why and how to actually delete material from your hard drive.
Single factor authentication (passwords) is the most common authentication method in use for computer access. This article describes tips for picking a good password and deciding if your current passwords are not up to snuff.
A comprehensive training white paper desinged to get you started with MySQL, including installation and use.
By: Justin Klein Keane
Business Process Solutions
September 26, 2001
Table of Contents
Getting Verizon DSL to play nicely with your Linux system.
Overview white paper developed for training, discussion of using and installing PHP as a scripting language.
Getting started with HTML, what is it and how do you use it.