The Value of Vulnerability Assessments

With this out of sequence post we start a series of guest contributions. In these days of complexity in our everybay business of IT security, it is advisable to remember the foundations to protect your boxes from known threats. Here you are 7 down-to-Earth tips to secure your servers:

Do you know how your server measures up to potential threats? If you haven't performed a vulnerability
assessment on your servers yet, you may not be aware of issues that may leave you exposed to hackers and web-based attacks. A vulnerability assessment is the process of inventorying systems to check for possible security problems, and is an important part of system management and administration.

Vulnerabilities are weaknesses within a server or network that can be exploited in order to gain unauthorized access to a system, usually with the intention of performing malicious activities. The most common way to address many software-related vulnerabilities is through patches, which will usually be provided by the software manufacturer to correct security weaknesses or other bugs within a program.

However, there may be times when a patch is not available to address a possible security hole, and not all vulnerabilities are software-related to where a patch would be offered. This is where the concept of vulnerability assessments comes into play. Minimizing the attack surface and the effect that a potential hacking attempt could have on your system is a proactive way of effectively managing a server network.

Protecting your data vault
While there is no 100% way to protect your servers against vulnerabilities, in performing a vulnerability
assessment there are some steps you can take to minimize your risk:

Close unused ports
Ideally, your server network setup should include at least a network firewall and a server-level firewall to block undesired traffic. Undesired traffic would include traffic to ports that are unused or that correspond with services that shouldn't be publicly-available. These ports should be blocked in your firewall(s).

Don't over-share
If servers on your network are set up to share files with others, or to access network shares (such as file servers and other resources), make sure that those shares are configured to only allow access as appropriate. Hosts that don't participate in sharing resources should have that capability turned off completely.

Stop unnecessary services
The more services you have on your server, especially those that listen on network ports, the more avenues a hacker has to get into your system. This is especially true if you have services running that aren't being monitored or used, and therefore are unmaintained. Stop services that are not in use or necessary, and restrict access to others that are not intended for public access.

Remove unnecessary applications
Many operating systems come with a wide set of programs that may not be necessary for normal server
operations. Find out what software is installed on your system, and then determine which of those
applications are not necessary and remove them.

Change your passwords
Using default vendor passwords is more common than you may think – but since those passwords are usually publicly-known, they are often the first ones used during hacking attempts. Secure passwords should always be used in favor of the vendor defaults, and industry experts recommend changing them every 30-60 days.

Do some research
When software or new applications are installed, users often neglect the time needed to review their settings to ensure that everything is up to par with modern security standards. Take some time to research what you are installing and any security implications that it may have, including what features may be enabled that could introduce security problems, and what settings need to be adjusted.

Encrypt when possible
Many services and network hardware have the capability of encrypting traffic, which decreases the likelihood of information being “sniffed” out of your network. When transmitting sensitive data, such as passwords, always use an encrypted connection.

Regular vulnerability assessment is a vital part of maintaining system security. Not only will it help diminish the success or possible effects of malicious activity against your servers, but it's also a requirement for many modern compliance standards such as PCI DSS, HIPAA, SOX, GLB/GLBA, and other regulatory standards.

This guest post was provided by Vanessa Vasile on behalf of GFI Software Ltd. GFI is a leading software developer that provides a single source for network administrators to address their network security, content security and messaging needs. More information: GFI vulnerability assessment.


All product and company names herein may be trademarks of their respective owners. 

SQL injection - Attacks and defense by Justin Clarke et al. - Book review

This book was published by Syngress in 2009. It was the book of the year in 2009 for Richard Bejtlich in taosecurity. It has ten authors, the main one is Justin Clarke.

In my eyes, this is an obliged reference book for everyone testing web applications using a database (most of them, BTW) today (and in the last 10 years!)

The book is broken down into 10 chapters - Let's go one by one:

Chapter 1 - What is SQL injection?
A generic introduction to the topic of the book. A little bit confusing chapter. I would recommend to re-read it at the end. The reader will then have more than one eureka moment.

Chapter 2 - Testing for SQL injection
This chapter wears the "hacker's hat" and shows how to find SQL injection samples in a web application connected to a database. This is a nice intro to the rest of the book. It provides useful tips about displayed SQL errors in MS SQL server, MySQL and Oracle. One of the coolest points of this book is the collection of tools that most of the chapters offer at their end. This is also the case for chapter 2. Worth mentioning, mainly because it is a free tool (and a very good one!) is the Paros Proxy.

Chapter 3 - Reviewing code for SQL injection
This chapter wears the "developer's hat" and shows how to follow user data (the use the nice term of "tainted data") through lines of PHP, Java and C# code. The end of the chapter mentions some source code analysis tools like YASCA or the MS Source Code Analyzer for SQL Injection.

Chapter 4 - Exploiting SQL injection
These pages show the deep foundations of this art, with steps such as identifying the database, extracting data through UNION statements, using conditional statements, enumerating the database schema, escalating privileges, stealing password hashes, out-of-band communication and finally, they present some tools to automate SQL injection exploitation such as sqlmap and bobcat.

Chapter 5 - Blind SQL injection exploitation
This chapter wears the "advance hacker/detective's hat". Using time-based, binary search, bit-by-bit inference and response=based techniques, they present ways to infer knowledge out of the interaction with a database. They also mention some tools such as Absinthe, Sqlninja and Squeeza.

Chapter 6 - Exploiting the operating system
Normally a database is an application software residing on top of an operating system. In this chapter, they keep on wearing the "advanced hacker/detective's hat" and present ways to read and write files and execute OS commands.

Chapter 7 - Advanced topics
Richard Bretjlich considers funny that in this "advanced & technical" book the authors have inserted a chapter for "even more" advanced topics. I agree with him. Whatever our views are, this chapter describes ways to evade input filters, to exploit second-order SQL injection and to use hybrid attacks.

Chapter 8 - Code-level defenses
This is the chapter that "developers" should read without any doubt. The key to avoid SQL injection attacks is to completely code the access to a database based on customised parameters that are out of the users' reach. The authors propose a series of recommendations to validate input and to encode output.

Chapter 9 - Platform-level defenses
Together with excellent coding practices, there are some measures, related to the operating platform, that we can take to avoiod SQL injection. These are, for example, using web application firewalls, web server filters, IDSs and securing the database itself.

Chapter 10 - This chapter is the chapter every "white hat hacker" should have at hand when assessing a web app connected to a database. It is a great reference of SQL commands and SQL injection tweaks for SQL Server, MySQL, Oracle, PostgreSQL and even DB2. If you need to select only one chapter, focus on this
one.

You can also read Richard's reference to this book in Amazon.

All in all, a book worth its price, keep it as a web app pen test reference book! Thanks to the authors for this nice work. And also a special mention to the one who merged and composed the input from 10 different authors into a unique book.

Happy reading!