Writing device drivers in Linux(part 5)

Also, note the use of the kmalloc function. This function is used for memory allocation of the buffer in the device driver which resides in kernel space. Its use is very similar to the well known malloc function. Finally, if registering the major number or allocating the memory fails, the module acts accordingly.
The “memory” driver: removing the driver

In order to remove the module inside the memory_exit function, the function unregsiter_chrdev needs to be present. This will free the major number for the kernel.

=

void memory_exit(void) {
/* Freeing the major number */
unregister_chrdev(memory_major, "memory");

/* Freeing buffer memory */
if (memory_buffer) {
kfree(memory_buffer);
}

printk("<1>Removing memory module\n");

}

The buffer memory is also freed in this function, in order to leave a clean kernel when removing the device driver.
The “memory” driver: opening the device as a file

The kernel space function, which corresponds to opening a file in user space (fopen), is the member open: of the file_operations structure in the call to register_chrdev. In this case, it is the memory_open function. It takes as arguments: an inode structure, which sends information to the kernel regarding the major number and minor number; and a file structure with information relative to the different operations that can be performed on a file. Neither of these functions will be covered in depth within this article.

When a file is opened, it’s normally necessary to initialize driver variables or reset the device. In this simple example, though, these operations are not performed.

The memory_open function can be seen below:

=

int memory_open(struct inode *inode, struct file *filp) {

/* Success */
return 0;
}

This new function is now shown in Table 5.

Events User functions Kernel functions
Load module insmod module_init()
Open device fopen file_operations: open
Read device
Write device
Close device
Remove module rmmod module_exit()

Table 5. Device driver events and their associated interfacing functions between kernel space and user space.
The “memory” driver: closing the device as a file

The corresponding function for closing a file in user space (fclose) is the release: member of the file_operations structure in the call to register_chrdev. In this particular case, it is the function memory_release, which has as arguments an inode structure and a file structure, just like before.

When a file is closed, it’s usually necessary to free the used memory and any variables related to the opening of the device. But, once again, due to the simplicity of this example, none of these operations are performed.

The memory_release function is shown below:

=

int memory_release(struct inode *inode, struct file *filp) {
 
  /* Success */
  return 0;
}

This new function is shown in Table 6.

Events	User functions	Kernel functions
Load module	insmod	module_init()
Open device	fopen	file_operations: open
Read device
Write device
Close device	fclose	file_operations: release
Remove module	rmmod	module_exit()

Table 6. Device driver events and their associated interfacing functions between kernel space and user space.

The “memory” driver: reading the device

To read a device with the user function fread or similar, the member read: of the file_operations structure is used in the call to register_chrdev. This time, it is the function memory_read. Its arguments are: a type file structure; a buffer (buf), from which the user space function (fread) will read; a counter with the number of bytes to transfer (count), which has the same value as the usual counter in the user space function (fread); and finally, the position of where to start reading the file (f_pos).
In this simple case, the memory_read function transfers a single byte from the driver buffer (memory_buffer) to user space with the function copy_to_user:
=

ssize_t memory_read(struct file *filp, char *buf, 
                    size_t count, loff_t *f_pos) { 
 
  /* Transfering data to user space */ 
  copy_to_user(buf,memory_buffer,1);

  /* Changing reading position as best suits */ 
  if (*f_pos == 0) { 
    *f_pos+=1; 
    return 1; 
  } else { 
    return 0; 
  }
}

The reading position in the file (f_pos) is also changed. If the position is at the beginning of the file, it is increased by one and the number of bytes that have been properly read is given as a return value, 1. If not at the beginning of the file, an end of file (0) is returned since the file only stores one byte.
In Table 7 this new function has been added.

Events	User functions	Kernel functions
Load module	insmod	module_init()
Open device	fopen	file_operations: open
Read device	fread	file_operations: read
Write device
Close device	fclose	file_operations: release
Remove modules	rmmod	module_exit()

Table 7. Device driver events and their associated interfacing functions between kernel space and user space.

see you next time  :)
http://crazyflx.com/dap/a/?a=79&p=www.crazyflx.com/softwarebots/ultimate-google-suggest-scraper-over-300-to-have-made-yours-for-24-99/

Read More

Writing device drivers in Linux(part 4)

To develop this driver, several new #include statements which appear frequently in device drivers need to be added:

=

/* Necessary includes for device drivers */
#include
#include
#include
#include /* printk() */
#include /* kmalloc() */
#include /* everything... */
#include /* error codes */
#include /* size_t */
#include
#include /* O_ACCMODE */
#include /* cli(), *_flags */
#include /* copy_from/to_user */

MODULE_LICENSE("Dual BSD/GPL");

/* Declaration of memory.c functions */
int memory_open(struct inode *inode, struct file *filp);
int memory_release(struct inode *inode, struct file *filp);
ssize_t memory_read(struct file *filp, char *buf, size_t count, loff_t *f_pos);
ssize_t memory_write(struct file *filp, char *buf, size_t count, loff_t *f_pos);
void memory_exit(void);
int memory_init(void);

/* Structure that declares the usual file */
/* access functions */
struct file_operations memory_fops = {
read: memory_read,
write: memory_write,
open: memory_open,
release: memory_release
};

/* Declaration of the init and exit functions */
module_init(memory_init);
module_exit(memory_exit);

/* Global variables of the driver */
/* Major number */
int memory_major = 60;
/* Buffer to store data */
char *memory_buffer;

After the #include files, the functions that will be defined later are declared. The common functions which are typically used to manipulate files are declared in the definition of the file_operations structure. These will also be explained in detail later. Next, the initialization and exit functions—used when loading and removing the module—are declared to the kernel. Finally, the global variables of the driver are declared: one of them is the major number of the driver, the other is a pointer to a region in memory, memory_buffer, which will be used as storage for the driver data.
The “memory” driver: connection of the device with its files

In UNIX and Linux, devices are accessed from user space in exactly the same way as files are accessed. These device files are normally subdirectories of the /dev directory.

To link normal files with a kernel module two numbers are used: major number and minor number. The major number is the one the kernel uses to link a file with its driver. The minor number is for internal use of the device and for simplicity it won’t be covered in this article.

To achieve this, a file (which will be used to access the device driver) must be created, by typing the following command as root:

# mknod /dev/memory c 60 0

In the above, c means that a char device is to be created, 60 is the major number and 0 is the minor number.

Within the driver, in order to link it with its corresponding /dev file in kernel space, the register_chrdev function is used. It is called with three arguments: major number, a string of characters showing the module name, and a file_operations structure which links the call with the file functions it defines. It is invoked, when installing the module, in this way:

=

int memory_init(void) {
int result;

/* Registering device */
result = register_chrdev(memory_major, "memory", &memory_fops);
if (result < 0) { printk( "<1>memory: cannot obtain major number %d\n", memory_major);
return result;
}

/* Allocating memory for the buffer */
memory_buffer = kmalloc(1, GFP_KERNEL);
if (!memory_buffer) {
result = -ENOMEM;
goto fail;
}
memset(memory_buffer, 0, 1);

printk("<1>Inserting memory module\n");
return 0;

fail:
memory_exit();
return result;
}

Read More

Writing device drivers in Linux(part 3)

The “Hello world” driver: loading and removing the driver in kernel space

When a module device driver is loaded into the kernel, some preliminary tasks are usually performed like resetting the device, reserving RAM, reserving interrupts, and reserving input/output ports, etc.

These tasks are performed, in kernel space, by two functions which need to be present (and explicitly declared): module_init and module_exit; they correspond to the user space commands insmod and rmmod , which are used when installing or removing a module. To sum up, the user commands insmod and rmmod use the kernel space functions module_init and module_exit.

Let’s see a practical example with the classic program Hello world:

=

#include
#include
#include

MODULE_LICENSE("Dual BSD/GPL");

static int hello_init(void) {
printk("<1> Hello world!\n");
return 0;
}

static void hello_exit(void) {
printk("<1> Bye, cruel world\n");
}

module_init(hello_init);
module_exit(hello_exit);

The actual functions hello_init and hello_exit can be given any name desired. However, in order for them to be identified as the corresponding loading and removing functions, they have to be passed as parameters to the functions module_init and module_exit.

The printk function has also been introduced. It is very similar to the well known printf apart from the fact that it only works inside the kernel. The <1> symbol shows the high priority of the message (low number). In this way, besides getting the message in the kernel system log files, you should also receive this message in the system console.

This module can be compiled using the same command as before, after adding its name into the Makefile.

=

obj-m := nothing.o hello.o

In the rest of the article, I have left the Makefiles as an exercise for the reader. A complete Makefile that will compile all of the modules of this tutorial is shown in Appendix A.

When the module is loaded or removed, the messages that were written in the printk statement will be displayed in the system console. If these messages do not appear in the console, you can view them by issuing the dmesg command or by looking at the system log file with cat /var/log/syslog.

Table 4 shows these two new functions.

Events User functions Kernel functions
Load module insmod module_init()
Open device
Read device
Write device
Close device
Remove module rmmod module_exit()

Table 4. Device driver events and their associated interfacing functions between kernel space and user space.
The complete driver “memory”: initial part of the driver

I’ll now show how to build a complete device driver: memory.c. This device will allow a character to be read from or written into it. This device, while normally not very useful, provides a very illustrative example since it is a complete driver; it’s also easy to implement, since it doesn’t interface to a real hardware device (besides the computer itself).

Read More

Writing device drivers in Linux(part 2)

The first driver: loading and removing the driver in user space

 

I’ll now show you how to develop your first Linux device driver, which will be introduced in the kernel as a module.
For this purpose I’ll write the following program in a file named nothing.c
=

(#include
)

MODULE_LICENSE("Dual BSD/GPL");

Since the release of kernel version 2.6.x, compiling modules has become slightly more complicated. First, you need to have a complete, compiled kernel source-code-tree. If you have a Debian Sarge system, you can follow the steps in Appendix B (towards the end of this article). In the following, I’ll assume that a kernel version 2.6.8 is being used.
Next, you need to generate a makefile. The makefile for this example, which should be named Makefile, will be:
=

obj-m := nothing.o

Unlike with previous versions of the kernel, it’s now also necessary to compile the module using the same kernel that you’re going to load and use the module with. To compile it, you can type:
$ make -C /usr/src/kernel-source-2.6.8 M=pwd modules
This extremely simple module belongs to kernel space and will form part of it once it’s loaded.
In user space, you can load the module as root by typing the following into the command line:
# insmod nothing.ko
The insmod command allows the installation of the module in the kernel. However, this particular module isn’t of much use.
It is possible to check that the module has been installed correctly by looking at all installed modules:
# lsmod
Finally, the module can be removed from the kernel using the command:
# rmmod nothing
By issuing the lsmod command again, you can verify that the module is no longer in the kernel.
The summary of all this is shown in Table 3.

Events	User functions	Kernel functions
Load module	insmod
Open device
Read device
Write device
Close device
Remove module	rmmod

Table 3. Device driver events and their associated interfacing functions between kernel space and user space.

Read More

Writing device drivers in Linux (part 1)

Pre-requisites

In order to develop Linux device drivers, it is necessary to have an understanding of the following:

• C programming. Some in-depth knowledge of C programming is needed, like pointer usage, bit manipulating functions, etc.
• Microprocessor programming. It is necessary to know how microcomputers work internally: memory addressing, interrupts, etc. All of these concepts should be familiar to an assembler programmer.

There are several different devices in Linux. For simplicity, this brief tutorial will only cover type char devices loaded as modules. Kernel 2.6.x will be used (in particular, kernel 2.6.8 under Debian Sarge, which is now Debian Stable).

User space and kernel space

When you write device drivers, it’s important to make the distinction between “user space” and “kernel space”.

• Kernel space. Linux (which is a kernel) manages the machine’s hardware in a simple and efficient manner, offering the user a simple and uniform programming interface. In the same way, the kernel, and in particular its device drivers, form a bridge or interface between the end-user/programmer and the hardware. Any subroutines or functions forming part of the kernel (modules and device drivers, for example) are considered to be part of kernel space.
• User space. End-user programs, like the UNIX shell or other GUI based applications (kpresenter for example), are part of the user space. Obviously, these applications need to interact with the system’s hardware . However, they don’t do so directly, but through the kernel supported functions.

All of this is shown in figure 1.

Figure 1: User space where applications reside, and kernel space where modules or device drivers reside

Interfacing functions between user space and kernel space

The kernel offers several subroutines or functions in user space, which allow the end-user application programmer to interact with the hardware. Usually, in UNIX or Linux systems, this dialogue is performed through functions or subroutines in order to read and write files. The reason for this is that in Unix devices are seen, from the point of view of the user, as files.
On the other hand, in kernel space Linux also offers several functions or subroutines to perform the low level interactions directly with the hardware, and allow the transfer of information from kernel to user space.
Usually, for each function in user space (allowing the use of devices or files), there exists an equivalent in kernel space (allowing the transfer of information from the kernel to the user and vice-versa). This is shown in Table 1, which is, at this point, empty. It will be filled when the different device drivers concepts are introduced.

Events	User functions	Kernel functions
Load module
Open device
Read device
Write device
Close device
Remove module

Table 1. Device driver events and their associated interfacing functions in kernel space and user space.

Interfacing functions between kernel space and the hardware device

There are also functions in kernel space which control the device or exchange information between the kernel and the hardware. Table 2 illustrates these concepts. This table will also be filled as the concepts are introduced.

Read More

The Joomla Hacking Compendium

The Joomla Hacking Compendium
                                 ((or: Hacking Joomla for Phun and Profit))
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
[+] Title:      The Joomla Hacking Compendium
[+] Author:     Valentin Hoebel
[+] Contact:    valentin@xenuser.org

[+] Version: 1.0
[+] Date: December 2010
[+] Almost 1000 lines of pure knowledge!
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
:::::::::::::::::::::::::::::: - Chapters - :::::::::::::::::::::::::::::::
0x01 - Purpose of this document
0x02 - Introduction
0x03 - The Basics of Joomla
0x04 - The Joomla core
0x05 - Joomla extensions
0x06 - Hacking Joomla
0x07 - SEO, our strongest enemy
0x08 - Examples for Joomla SQL injections
0x09 - Examples for Joomla local file inclusions
0x10 - Examples for Joomla remote file inclusions
0x11 - Examples for Joomla XSSs/CSRFs
0x12 - How to protect your Joomla
0x13 - Conclusion and a look at Joomla's feature
0x14 - How to stay informed (or: the latest vulnerabilities)
0x15 - Useful tools
0x16 - Greetings and THX
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

::
:: 0x01 - Purpose of this document
::

This document should provide you with security related information about
Joomla and the extensions which are available for it. This paper focuses
on how to hack Joomla installations and how to protect them. I do not
want to motivate you to go out there and hack Joomla websites after you
have read this document, this paper is more a theoretical view of how
attackers could compromise the security of a website. It should help
you to understand basic security mechanics, which finally leads you
to a point where you are able to protect Joomla websites.

I also wrote this document in order to summ up some knowledge I gained
about Joomla. I hope it will be helpful in some way and you learn
something new. If you find any typos: feel free to drop me a mail
or simply ignore them. Fuck office / word / word processor - 
vim rules!

(( This paper was written for educational purposes. Always know and
respect your local laws. ))


(( While writing this document I assumed, that the reader already
gained some knowledge about web security and Joomla. ))



::
:: 0x02 - Introduction
::

When I was looking for a new CMS for my latest project in January 2007,
I immediately fell in love with Joomla. It was small, it was easy, it
was new, it was amazing, it felt so fresh and yes, I wanted to sleep
with it! Finally someone invented a content management system which
was easy to use and supported categories in categories, basic 
magazine features, easy content handling, awesome extensions management
and was fast to install.

While I have been creating countless websites with Joomla, I never
gave security a thought at the beginning. For me it was just about
installing Joomla, applying some cool theme and uploading douzends
of extensions.

But during the years I started to realize that there are kids and
automated scripts out there which looked for vulnerable websites and
"hacked" them automatically. Without any human interaction it was poss-
ible for them to compromise a Joomla installation and make clueless
webmasters angry.

I saw so many defaced sites, being a victim for scripts and not for
skilled hackers.

When I started to do some vulnerability and security research at
March 2010 (the time when I published security related
documents for the first time), I began to focus on Joomla and the
extensions which are available for it. I had no partiuclar reasons
for it, it just happened because so many Joomla websites turned out
to be unsecure.

But I also understood that Joomla itself, the core (sounds very
sci-fi like, doesn't it), seems to be secure in most ways.
I focused on Joomla extensions and discovered many vulnerabilities,
therefore in this document we will mostly have a look at stuff which
is not part of the Joomla core.

Now grab a coffee, switch on the music (I prefer vocal trance, Tiesto
is simply awesome btw!) and be invited to dive into the deepest code lines
and dissections of Joomla. 



::
:: 0x03 - The Basics of Joomla
::

Joomla is a content management system and therefore a feature-rich
application. It is full of functions and possibilities to enhance
its functionalities, therefore there may be many attack vectors
in theory.

When you download Joomla, all you need is a webserver, PHP and MySQL
in order to run it. The download file comes with the core and at least
one example theme.

The Joomla core can be enhanced with the help of..
- modules,
- components 
- and plugins (also known as mambots).

In most cases the components are vulnerable to attacks.
The modules often only are used to display information in small
boxes on the websites and contain no features which can be used
for exploiting weak spots.

The plugins (mambots) are more likely integrated core parts, e.g.
they can be used to embed PHP code into normal Joomla articles.

The components are the most important extensions for this CMS,
they provide classical functionality, like guestbooks, message
boards, galleries, user management.. 

The Joomla core itself is almost never vulnerable for attacks.
When you browse the web, you will have a hard time finding
serious attack vendors. Only some XSS and SQL injection
vulnerabilities are known and they are already fixed.

So let's focus on the Joomla components.



::
:: 0x04 - The Joomla core
::
 
Before inspecting the Joomla component attack vendors we first have a
look at the core.

Download Joomla somewhere and extract all files. Open the file
libraries/phpinputfilter/inputfilter.php
and look at the code:
----------------------------------------
  var $tagsArray; // default = empty array
        var $attrArray; // default = empty array

        var $tagsMethod; // default = 0
        var $attrMethod; // default = 0

        var $xssAuto; // default = 1
        var $tagBlacklist = array ('applet', 'body', 'bgsound' [...]
        var $attrBlacklist = array ('action', 'background'     [...]
----------------------------------------

As you can see, some filter methods of Joomla are based on blacklisting.
This knowledge can be used later to exploit potential vulnerabilities in
a better way. I find this method not very effective, btw.

While HTML tags containing "body" or "bgsound" will be filtered out
at input fields or URL parameters, they can be written in many ways,
e.g. like "bOdY" or "b o DY" etc. You are only limited by your
creativity and will find ways for tricking the blacklist of the
Joomla framework.

Another interesting part is this one (same file):
----------------------------------------
/*
 * Is there a tag? If so it will certainly start with a '<'
 */
$tagOpen_start  = strpos($source, '<');
while ($tagOpen_start !== false)
 {
        /*
         * Get some information about the tag we are processing
         */
         $preTag            .= substr($postTag, 0, $tagOpen_start);
         $postTag                = substr($postTag, $tagOpen_start);
----------------------------------------

As you can see they assume that an HTML tag being used in XSS attacks
starts with a "<". In fact, I never use this character and many 
XSS cheatsheets suggest this, too. With this information in mind,
you can most likely avoid being detected by the filters. You can start
your XSS string with ">

If you want to you can continue looking. You will find other filter
methods and, at the end of the file, there are also built in
mechanics which should help to prevent SQL injection vulnerabilities:

----------------------------------------
$string = mysql_real_escape_string($string);
----------------------------------------

By the way, you might know that mysql_real_escape_string is not
sufficient for preventing SQL injection attacks. Just to let you know.


I highly recommend that you get yourself familiar with the Joomla framework
and the way Joomla works. A good start would be to find out where Joomla
sets some metatags. While looking for the responsible script, you will
look over many parts of the Joomla core and therefore gain a basic 
understanding of what's going on in the backstage area.

And always remember: the more you learn about Joomla, the easier it is
to exploit vulnerabilities later.

Something which takes not long for being understood is how to reach
the backend of Joomla: simply type in
..website/administrator
in your browser and you will find the admin panel there. In most cases
there is a user called "administrator" or "admin". Try to brute force or
guess the password of that user. You will wonder how many times it is
12345 or sex or simply the website's name.



::
:: 0x05 - Joomla extensions
::

Browse extensions.joomla.org and install some components. They are marked
with a green [C] sign and can be installed by visiting the Joomla backend
(http://www.your-site.com/joomla/administrator).

After having installed some of them, go to the menu management and include
some links to the components on the website. Now visit the website and
browse through the links. You will notice that the URL looks like this:
http://www.website.com/joomla/index.php?option=com_blabla&Item=2&ItemId=5

It so much looks like it contains many attack vendors and is certainly
screeming for many penetration testing sessions. Please, come and hack me!

Of course it is not that easy, but look at this URL. It contains the
following pattern:
index.php?option= (which calls the component you are visiting)
com_blabla  (the name of the component)
&Item=2   (some ID, not very interesting)
&ItemId=5  (some ID, also not very interesting)

You realize that there is a pattern, don't you? This helps alot while
trying to hack a Joomla website.

It is often possible to add well-known variables (parameters) to the URL,
in most cases Joomla (respectively the component you are visiting) will
parse them. Some of these parameters are:
- controller
- layout
- category
- cat
- visit
- page

And you know: the more parameters there are, the more attack vendors might
exist.



::
:: 0x06 - Hacking Joomla
::

"Enough of this shit, stop talking! How do I hack it???" - Yah, yah.

Having in mind everything we learned, it is almost impossible to hack
a Joomla website core which was installed with the latest version.

Therefore we focus on the extensions (here: components; but modules are
often vulnerable to XSS attacks). Open your local Joomla test installation
(of course you don't try this on life websites, don't you?) and click
through the menu. Notice what components are installed.

There are the following attack vendors:
- look for input fields,
- look at the URL parameters,
- have a look at the source code,
- view the robots.txt,
- try to login via the admin back panel,
- have a look at the used theme (design)
- and try to find a PHPMyAdmin installation.

Concerning the attack vendors for components only, you can use
SQL injection and XSS attacks for input fields and the URL parameters.
 
If you don't know how to do that, I suggest you Google it up. Try googling
for "SQL injection sheet" or "XSS cheat sheet".

There are many ways for hacking Joomla and some examples will be shown in
the next chapters.



::
:: 0x07 - SEO, our strongest enemy
::

For attacking Joomla effectively, you will try to manipulate the URLs in
most cases. This can only be done when they are shown like this:
http://www.website.com/index.phpoption=com_blabla&Item=2&ItemId=5

When the URLs are like this
http://www.website.com/index,51,blabla
or
http://www.website.com/guestbook/page2
you most likely encounter SEO functionallity.

SEO contains a number of methods which make websites search engine
friendly. A lot of money can be earned in this area.

SEF (search engine friendly) URLs are our strongest enemy. They
hide the original URL from us.

And when there are no parameters in the URLs, we are unable to
find parameters which take our input. But what if we are able to
reconstruct the original URL?

All we need is 
a) to know what component is currently active,
b) what parameters it takes and
c) what their current values are.

The process of reconstructing contains of obtaining information and 
some decent guessing.

Have a look at the source code of the current page and look for
"com_". You most likely will find a part which looks like this:
----------------------------------------




 
----------------------------------------
 
Bingo! We have everything we need. The original URL is composed by the
parameters being shown in the code above. Attention: only code snippets
which do not contain Joomla default components are interesting for us.
Joomla default components could be com_content or com_search. Especially
com_search is included in almost every Joomla source code and therefore
is not very interesting for us - but the related code snippets can be
misleading.

Now compose your original URL, simply fill out the well-known URL
pattern:
http://www.website.com/
index.php?option=com_blabla&ItemId=5&Item=2&Entry=451&view=entries

You understand this part? Good.
We now have a URL we can work with.

Let's continue with some practical stuff.



::
:: 0x08 - Examples for Joomla SQL injections
::

The probably most common case for hacked Joomla websites is that
a SQL injection vulnerability was exploited. A typical URL which
is affected by this type of vulnerability looks like this:
index.php?option=com_blabla&category=5&Item=2

Typically the following parameters are vulnerable:
- cat, category, kat, categories, kats, cats
- id, userid, katid, catid
- sometimes also Item, entry, page

You can find out if a parameter is vulnerable when you change
its value from e.g. category=5 to category='.
Press enter and look for MySQL errors in the website. If you find
one, you might have discovered a SQL inkjection vulnerability.

In order to give you a better understanding and feeling of
how vulnerable URLs might look like, I just show you some
URLs which are known to be vulnerable (I discovered them):

URL: index.php?option=com_jp_jobs&view=detail&id=1
Vulnerable parameter: id

URL: index.php?option=com_mv_restaurantmenumanager&task=menu_display\
&Venue=XX&mid=XX&Itemid=XX
Vulnerable parameter: mid

URL: index.php?option=com_qpersonel&task=qpListele&katid=2
Vulnerable parameter: katid

URL: index.php?com_pandafminigames&Itemid=&task=myscores&userid=2
Vulnerable parameter: userid

URL: index.php?option=com_joltcard&Itemid=21&task=view&cardID=6
Vulnerable parameter: cardID

URL: index.php?com_bfquiztrial&view=bfquiztrial&catid=1&Itemid=62
Vulnerable parameter: catid

URL: index.php?com_golfcourseguide&view=golfcourses&cid=1&id=79
Vulnerable parameter: id

URL: index.php?option=com_nkc&view=insc&lang=en&gp=10
Vulnerable parameter: gp

Notice how many parameters look familiar to you? Yes, I mentioned them
earlier as well-known parameters which are affected on regular
basis :)

Since every Joomla database contains the same structure (like the same
tables etc.), we know enough to inject a SQL statement:

Example #1:
index.php?option=com_qpersonel&task=qpListele&katid=XX+AND+1=2+UNION+\
SELECT+1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,concat(\
username, password)--

Example #2:
index.php?option=com_pandafminigames&Itemid=&task=myscores&userid=XX+\
AND+1=2+UNION+SELECT+concat(password),2,concat(password),4,5,6,7,\
8,9,10,11,12-- 


Example #3:
index.php?option=com_jp_jobs&view=detail&id=1+AND+1=2+UNION+SELECT+\
group_concat(0x503077337220743020743368206330777321,name,username,\
password,email,usertype,0x503077337220743020743368206330777321)--

The selected information will be shown within the website.
Select a username and password from the table and try to crack the
MD5 hash with the help of raindbow tables.

SQL injections in Joomla give us so much freedom as we can get. You can
select everything you want from the database, and if you are lucky,
there are also other tables in the databases which do not belong
to Joomla but still contain some very interesting information.



::
:: 0x09 - Examples for Joomla local file inclusions
::

Local file inclusions are very funny. You tell the website what you
want to see. Awesome! You want to view the configuration file
which contains the database login credentials? No problem.
You want to view the /etc/passwd file if Joomla is hosted
on a Linux box? You can do that.

Local file inclusions are also a common problem in Joomla extensions.
Many of them are vulnerable for this type of attack and some of them
never get fixed. This may lead to a server hack, which is not
funny any more - at least for the system administrator.

A typical URL being vulnerable to LFI looks like this:
index.php?option=com_blablubb&Item=2&view=guestbookpage

Typically most of the vulnerable parameters are this one:
- controller
- view
- layout
- page

To give you some proper understanding of typical affected
URLs I provide you with some examples I found earlier this year:

URL: index.php?option=com_jejob&view=some_value
Vulnerable Parameter: view

URL: index.php?option=com_jeajaxeventcalendar&view=some_value
Vulnerable Parameter: view

URL: index.php?option=com_jradio&controller=some_value
Vulnerable Parameter: controller
((I didn't find this one.))

Now let's see how we can use this:
index.php?option=com_jradio&controller=../../../../etc/passwd

In this case we need to use the famous Nullbyte which helps us
to bypass a restriction which is set in the responsible PHP script
of the component.

In the example above the controller parameter is used to
include a file from the local hard disk. This file contains
useful information for us.

If you are not familiar with local file inclusions I recommend
you look a tutorial up since I will not explain any details here.

Now with the knowledge about a LFI vulnerability within a Joomla
component, we can try to access the configuration.php of Joomla.
This file contains very very interesting information.

Since many LFIs also reveal PHP source code, we try this one:
index.php?option=com_blabla&view=../../../configuration.php

The source code of the file is shown and we receive the login
data for the current database user. Now find a PHPMyAdmin
login on the same server and try to login with this data.

You now have access to all Joomla tables and can basically
do what you want.



::
:: 0x10 - Examples for Joomla remote file inclusions
::

Some Joomla components are also known for containing
remote file inclusion vulnerabilities. RFIs allow us to
include files from another server and to execure code on
the target.

A typical RFI URL looks like a LFI URL. In order to
give you a better feeling of how to see a RFI vulner-
ability within seconds, I show you some examples
(I did not find this ones):

URL: index.php?option=com_sef&Itemid=&mosConfig.absolute.path=.
Vulnerable Parameter: &mosConfig.absolute.path

URL: index.php?option=com_jomestate&task=.
Vulnerable Parameter: task

When you found a RFI vulnerability, try to include your PHP
shell which is hosted on another box.
Once you uploaded it, you are able to browse all Joomla files
and download them, change them, remove them...

No Joomla installation is safe when there is an exploited
RFI.



::
:: 0x11 - Examples for Joomla XSSs/CSRFs
::

XSS/CSRF vulnerabilities can mostly be found in input fields,
such as forms, guestbooks, shoutboxes and search boxes. They
allow to execute HTML/JS/VBS code within the context of the
visitor's browser.

A typical example would be to use this HTML code in order
to see if an input field or a parameter is vulnerable

(( Try to avoid quotes in the XSS string. They are escaped
in most cases because XSS filters do their work. ))

Notice how the XSS string starts with "> and not with a 
HTML tag itself. This is done in order to close the current
tag you are in.

Let's say you are trying this code on an input field.
The code for this field probably looks like this:
----------------------------------------

----------------------------------------

When a web browser parses the source code of a website and
displays an input field, you of course do not see the source
code. But because you are able to do things with the input
field and are able to select it with your cursor, the browser
tells you that you are inside this  tag now.
So while you are typing within an input box, you are
located somewhere here;

     ^
So let's say you are within the quotes of the value attribute
while you type something. This means that the source code looks
like this at this point: value="SOMETHINGYOUTYPEDIN
As you can see, the quotes are not closed. So now close the
quotes and the HTML tag with your XSS string in order to
have clean and working HTML code as a result:
">

Read More

Ubuntu dpkg command

 Ubuntu dpkg command

1. dpkg -l

List all installed packages.

EXAMPLES:

dpkg returns a number of installed packages:

$ dpkg -l | wc -l
1209

ask dpkg to return only packages related to php. This will include installed and non-installed packages:

$ dpkg -l *php*

Using dpkg with grep to see only installed packages

dpkg -l | grep php

2. dpkg -L

dpkg -L will show whether the package is installed. If the package is installed dpkg will show related files and their locations whithin the filesystem.

EXAMPLES:

$ dpkg -L ntpdate
/.
/etc
/etc/network
/etc/network/if-up.d
/etc/network/if-up.d/ntpdate
/etc/logcheck
...

$ dpkg -L php5-json
Package `php5-json' is not installed.

3. dpkg -p

dpkg -p will display an full information regarding to a package name provaded as an argument. The information will nclude but not limited to version, dependecies, sugested packages and more.

EXAMPLE:

$ dpkg -p dpkg
Package: dpkg
Essential: yes
Priority: required
Section: admin
Installed-Size: 7276
Origin: debian
Maintainer: Dpkg Developers
Bugs: debbugs://bugs.debian.org
Architecture: i386
Version: 1.14.28
Replaces: manpages-de (<= 0.4-3), manpages-pl (<= 20051117-1)
Pre-Depends: libc6 (>= 2.7-1), coreutils (>= 5.93-1), lzma
Suggests: apt
Conflicts: apt (<< 0.7.7), aptitude (<< 0.4.7-1), dpkg-dev (<< 1.14.16), dpkg-iasearch (<< 0.11), sysvinit (<< 2.82-1)
Size: 2353726
Description: Debian package management system
This package provides the low-level infrastructure for handling the
installation and removal of Debian software packages.
.
For Debian package development tools, install dpkg-dev.
Homepage: http://wiki.debian.org/Teams/Dpkg

4. dpkg -s

dpkg -s will a status of the package suplied as an argument. This is similar to dpkg -p but also inlcudes a status and config files:

EXAMPLE:

$ dpkg -s dpkg
Package: dpkg
Essential: yes
Status: install ok installed
Priority: required
Section: admin
Installed-Size: 7276
Origin: debian
Maintainer: Dpkg Developers
Bugs: debbugs://bugs.debian.org
Architecture: i386
Version: 1.14.28
Replaces: manpages-de (<= 0.4-3), manpages-pl (<= 20051117-1)
Pre-Depends: libc6 (>= 2.7-1), coreutils (>= 5.93-1), lzma
Suggests: apt
Conflicts: apt (<< 0.7.7), aptitude (<< 0.4.7-1), dpkg-dev (<< 1.14.16), dpkg-iasearch (<< 0.11), sysvinit (<< 2.82-1)
Conffiles:
/etc/logrotate.d/dpkg 501f8c90b83c7ea180868ca82e1e82d1
/etc/dpkg/origins/debian 731423fa8ba067262f8ef37882d1e742
/etc/dpkg/dpkg.cfg f4413ffb515f8f753624ae3bb365b81b
/etc/alternatives/README 69c4ba7f08363e998e0f2e244a04f881
Description: Debian package management system
This package provides the low-level infrastructure for handling the
installation and removal of Debian software packages.
.
For Debian package development tools, install dpkg-dev.
Homepage: http://wiki.debian.org/Teams/Dpkg

5. dpkg -S

this dpkg command will search and display filenames related to an installed package.

EXAMPLES:

$ dpkg -S dpkg.cfg
dpkg: /usr/share/man/hu/man5/dpkg.cfg.5.gz
dpkg: /usr/share/man/pl/man5/dpkg.cfg.5.gz
dpkg: /usr/share/man/sv/man5/dpkg.cfg.5.gz
dpkg: /etc/dpkg/dpkg.cfg
dpkg: /usr/share/man/fr/man5/dpkg.cfg.5.gz
dpkg: /usr/share/man/man5/dpkg.cfg.5.gz
dpkg: /usr/share/man/de/man5/dpkg.cfg.5.gz

$ dpkg -S ports.conf
apache2.2-common: /etc/apache2/ports.conf

6. dpkg -i

-i option will tell dpkg to installe a package.deb. To run this command a superuser/root privilegies are required.

EXAMPLE:

# dpkg -i skype-debian_2.1.0.81-1_i386.deb

this command will install a package which is not part of the debian standard repositories. Synce dpkpg will not install a required prerequisites, dpkg may display an error that prerequisites for this package are not met.

7. dpkg -r

dpkg will remove installed package but not its configurations. Root privilegies are required to execute this command.

EXAMPLE:

# dpkg -r apache2

this command will remove apache2 form system.

8. dpkg -P

with -P option the dpkg command will remove and purge any configuration files related to the package.

EXAMPLE:
# dpkg -P apache2

This command will remove apache2 package from the system including its configuration files. Root permitions required.

9. dpkg-reconfigure

dpkg-reconfigure is commadn of its own but related to the dpkg family and it is also worth to mention it here. dpkg-reconfigure will reconfigure alredy installed package in the system.

EXAMPLE:
# dpkg-reconfigure xserver-xorg

this command will reconfigure a xserver-xorg package. Root privilegies are required to execute this command.

Read More

Ubuntu dpkg command

 Ubuntu dpkg command

1. dpkg -l

List all installed packages.

EXAMPLES:

dpkg returns a number of installed packages:

$ dpkg -l | wc -l
1209

ask dpkg to return only packages related to php. This will include installed and non-installed packages:

$ dpkg -l *php*

Using dpkg with grep to see only installed packages

dpkg -l | grep php

2. dpkg -L

dpkg -L will show whether the package is installed. If the package is installed dpkg will show related files and their locations whithin the filesystem.

EXAMPLES:

$ dpkg -L ntpdate
/.
/etc
/etc/network
/etc/network/if-up.d
/etc/network/if-up.d/ntpdate
/etc/logcheck
...

$ dpkg -L php5-json
Package `php5-json' is not installed.

3. dpkg -p

dpkg -p will display an full information regarding to a package name provaded as an argument. The information will nclude but not limited to version, dependecies, sugested packages and more.

EXAMPLE:

$ dpkg -p dpkg
Package: dpkg
Essential: yes
Priority: required
Section: admin
Installed-Size: 7276
Origin: debian
Maintainer: Dpkg Developers
Bugs: debbugs://bugs.debian.org
Architecture: i386
Version: 1.14.28
Replaces: manpages-de (<= 0.4-3), manpages-pl (<= 20051117-1)
Pre-Depends: libc6 (>= 2.7-1), coreutils (>= 5.93-1), lzma
Suggests: apt
Conflicts: apt (<< 0.7.7), aptitude (<< 0.4.7-1), dpkg-dev (<< 1.14.16), dpkg-iasearch (<< 0.11), sysvinit (<< 2.82-1)
Size: 2353726
Description: Debian package management system
This package provides the low-level infrastructure for handling the
installation and removal of Debian software packages.
.
For Debian package development tools, install dpkg-dev.
Homepage: http://wiki.debian.org/Teams/Dpkg

4. dpkg -s

dpkg -s will a status of the package suplied as an argument. This is similar to dpkg -p but also inlcudes a status and config files:

EXAMPLE:

$ dpkg -s dpkg
Package: dpkg
Essential: yes
Status: install ok installed
Priority: required
Section: admin
Installed-Size: 7276
Origin: debian
Maintainer: Dpkg Developers
Bugs: debbugs://bugs.debian.org
Architecture: i386
Version: 1.14.28
Replaces: manpages-de (<= 0.4-3), manpages-pl (<= 20051117-1)
Pre-Depends: libc6 (>= 2.7-1), coreutils (>= 5.93-1), lzma
Suggests: apt
Conflicts: apt (<< 0.7.7), aptitude (<< 0.4.7-1), dpkg-dev (<< 1.14.16), dpkg-iasearch (<< 0.11), sysvinit (<< 2.82-1)
Conffiles:
/etc/logrotate.d/dpkg 501f8c90b83c7ea180868ca82e1e82d1
/etc/dpkg/origins/debian 731423fa8ba067262f8ef37882d1e742
/etc/dpkg/dpkg.cfg f4413ffb515f8f753624ae3bb365b81b
/etc/alternatives/README 69c4ba7f08363e998e0f2e244a04f881
Description: Debian package management system
This package provides the low-level infrastructure for handling the
installation and removal of Debian software packages.
.
For Debian package development tools, install dpkg-dev.
Homepage: http://wiki.debian.org/Teams/Dpkg

5. dpkg -S

this dpkg command will search and display filenames related to an installed package.

EXAMPLES:

$ dpkg -S dpkg.cfg
dpkg: /usr/share/man/hu/man5/dpkg.cfg.5.gz
dpkg: /usr/share/man/pl/man5/dpkg.cfg.5.gz
dpkg: /usr/share/man/sv/man5/dpkg.cfg.5.gz
dpkg: /etc/dpkg/dpkg.cfg
dpkg: /usr/share/man/fr/man5/dpkg.cfg.5.gz
dpkg: /usr/share/man/man5/dpkg.cfg.5.gz
dpkg: /usr/share/man/de/man5/dpkg.cfg.5.gz

$ dpkg -S ports.conf
apache2.2-common: /etc/apache2/ports.conf

6. dpkg -i

-i option will tell dpkg to installe a package.deb. To run this command a superuser/root privilegies are required.

EXAMPLE:

# dpkg -i skype-debian_2.1.0.81-1_i386.deb

this command will install a package which is not part of the debian standard repositories. Synce dpkpg will not install a required prerequisites, dpkg may display an error that prerequisites for this package are not met.

7. dpkg -r

dpkg will remove installed package but not its configurations. Root privilegies are required to execute this command.

EXAMPLE:

# dpkg -r apache2

this command will remove apache2 form system.

8. dpkg -P

with -P option the dpkg command will remove and purge any configuration files related to the package.

EXAMPLE:
# dpkg -P apache2

This command will remove apache2 package from the system including its configuration files. Root permitions required.

9. dpkg-reconfigure

dpkg-reconfigure is commadn of its own but related to the dpkg family and it is also worth to mention it here. dpkg-reconfigure will reconfigure alredy installed package in the system.

EXAMPLE:
# dpkg-reconfigure xserver-xorg

this command will reconfigure a xserver-xorg package. Root privilegies are required to execute this command.

Read More

Installation of deb kernel in Debian chroot environment

Installation of deb kernel in Debian chroot environment
Here are simple steps on how to install custom build or existing Debian kernel within a chroot environment. In this example we do not install a new version of Debian in chroot environment but we use the existing installation. Let's create directory for a chroot environment:

1. Make directory

# mkdir -p /mnt/chroot

First we need to mount a partition with existing Debian installation. In our case a / partition of existing installation is /dev/hdb1 .

# mount  /dev/hdb1 /mnt/chroot

Next we need to bind hardware with new chroot environment. The next commands will make sure that connected hardware works otherwise update-grub may not function properly.

2. Mount

# mount -o bind /proc /mnt/chroot/proc
# mount -o bind /proc /mnt/chroot/dev

Now we are ready to enter chroot environment
chroot

# chroot /mnt/chroot

3. Install kernel

let's install kernel:

/# dpkg -i linux-image-2.6.26-2-486_2.6.26-21lenny4_i386.deb
Selecting previously deselected package linux-image-2.6.26-2-486.
(Reading database ... 12686 files and directories currently installed.)
Unpacking linux-image-2.6.26-2-486 (from linux-image-2.6.26-2-486_2.6.26-21lenny4_i386.deb) ...
Done.
Setting up linux-image-2.6.26-2-486 (2.6.26-21lenny4) ...
Running depmod.
Running mkinitramfs-kpkg.
Running postinst hook script update-grub.
Searching for GRUB installation directory ... found: /boot/grub
Searching for default file ... found: /boot/grub/default
Testing for an existing GRUB menu.lst file ... found: /boot/grub/menu.lst
Searching for splash image ... none found, skipping ...
Found kernel: /boot/vmlinuz-2.6.26-2-686
Found kernel: /boot/vmlinuz-2.6.26-2-486
Updating /boot/grub/menu.lst ... done

Good luck. 

Read More

APACHE web server and SSL authentication

APACHE web server and SSL authentication

Author: Jaroslav Imrich


The article will deal with authentication of server (One-way SSL authentication), as well as it will also include authentication of clients by using certificates (Two-way SSL authentication).
1. Introduction

If you have decided to enable a SSL ( Secure Sockets Layer ) protocol on your web server it may be because you would like to extend its functionality to achieve an integrity and confidentiality for a data transferred on unsecured networks. However, this protocol with the combination of PKI ( Public Key Infrastructure ) principles can also along the side of integrity and confidentiality provide authentication between both sides involved in the client-server communication.

One-way SSL authentication allows a SSL client to confirm an identity of SSL server. However, SSL server cannot confirm an identity of SSL client. This kind of SSL authentication is used by HTTPS protocol and many public servers around the world this way provides services such as webmail or Internet banking. The SSL client authentication is done on a “application layer” of OSI model by the client entering an authentication credentials such as username and password or by using a grid card.

Two-way SSL authentication also known as mutual SSL authentication allows SSL client to confirm an identity of SSL server and SSL server can also confirm an identity of the SSL client. This type of authentication is called client authentication because SSL client shows its identity to SSL server with a use of the client certificate. Client authentication with a certificate can add yet another layer of security or even completely replace authentication method such us user name and password.

In this document, we will discuss configuration of both types of SSL authentication one-way SSL authentication and two-way SSL authentication.
2. Issuing OpenSSL certificates

This section briefly describes a procedure to create all required certificates using an openssl application. The whole process of issuing openssl certificates is simple. However, in case when a larger amount of issued certificates is required below described procedure would be inadequate, and therefore, I recommend for that case use OpenSSL's CA modul. Reader is expected to have a basic knowledge of PKI, and for that reason all steps will be described just briefly. Please follow this link if you wish to refresh your knowledge about Public key infrastructure.


All certificates will be issued by using OpenSSL application and openssl.cnf configuration file. Please save this file into a directory from which you would run all openssl commands. Please note that this configuration file is optional, and we use it just to make the whole process easier.

openssl.cnf:

[ req ]
default_md = sha1
distinguished_name = req_distinguished_name

[ req_distinguished_name ]
countryName = Country
countryName_default = SK
countryName_min = 2
countryName_max = 2
localityName = Locality
localityName_default = Bratislava
organizationName = Organization
organizationName_default = Jariq.sk Enterprises
commonName = Common Name
commonName_max = 64

[ certauth ]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer:always
basicConstraints = CA:true
crlDistributionPoints = @crl

[ server ]
basicConstraints = CA:FALSE
keyUsage = digitalSignature, keyEncipherment, dataEncipherment
extendedKeyUsage = serverAuth
nsCertType = server
crlDistributionPoints = @crl

[ client ]
basicConstraints = CA:FALSE
keyUsage = digitalSignature, keyEncipherment, dataEncipherment
extendedKeyUsage = clientAuth
nsCertType = client
crlDistributionPoints = @crl

[ crl ]
URI=http://testca.local/ca.crl

As a first step you need to generate self-signed certificate CA. Once prompted for value of “Common Name” insert string “Test CA”:

# openssl req -config ./openssl.cnf -newkey rsa:2048 -nodes \
-keyform PEM -keyout ca.key -x509 -days 3650 -extensions certauth -outform PEM -out ca.cer

If you have not encountered any complications running the above command you would find in your current directory a file “ca.key” with private key of certificate authority (CA) and ca.cer with its self-signed certificate.

In the next step you need to generate private SSL key for the server:

# openssl genrsa -out server.key 2048

To generate Certificate Signing Request in PKCS#10 format you would use a following command as a common name you can specify its hostname – for example “localhost”.

# openssl req -config ./openssl.cnf -new -key server.key -out server.req

With self-signed certificate authority issue server certificate with serial number 100:

# openssl x509 -req -in server.req -CA ca.cer -CAkey ca.key \
-set_serial 100 -extfile openssl.cnf -extensions server -days 365 -outform PEM -out server.cer

New file server.key contains server's private key and file server.cer is a certificate itself. Certificate Signing Request file server.req is not needed any more so it can be removed.

# rm server.req

Generete private key for SSL client:

# openssl genrsa -out client.key 2048

As for the server also for client you need to generate Certificate Signing Request and as a Common Name, I have used string: “Jaroslav Imrich”.

# openssl req -config ./openssl.cnf -new -key client.key -out client.req

With your self-signed Certificate Authority, issue a client certificate with serial number 101:

# openssl x509 -req -in client.req -CA ca.cer -CAkey ca.key \
-set_serial 101 -extfile openssl.cnf -extensions client -days 365 -outform PEM -out client.cer

Save client's private key and certificate in a PKCS#12 format. This certificate will be secured by a password and this password will be used in the following sections to import the certificate into the web browser's certificate manager:

# openssl pkcs12 -export -inkey client.key -in client.cer -out client.p12

File “client.p12” contains a private key and the client's certificate, therefore files “client.key”, “client.cer” and “client.req” are no longer needed, so these files can be deleted.

# rm client.key client.cer client.req

3. One-way SSL authentication

Once the server's private key and certificate are ready, you can begin with SSL configuration of Apache web server. In many cases, this process is comprised of 2 steps – enabling mod_ssl and creating virtual host for port 443/TCP.
Enabling mod_ssl is very easy, all you need to do is to open httpd.conf file and remove comment mark from line:

LoadModule ssl_module modules/mod_ssl.so

Just because the server will serve the HTTPS requests on port 443 in is important to enable port 433/TCP in the apaches's configuration file by adding a line:

Listen 443

Definition of a virtual host can be also defined in “httpd.conf” file and should look as the one below:



ServerAdmin webmaster@localhost

DocumentRoot /var/www

Options FollowSymLinks
AllowOverride None


Options Indexes FollowSymLinks MultiViews
AllowOverride None
Order allow,deny
allow from all


ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/

AllowOverride None
Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch
Order allow,deny
Allow from all

LogLevel warn
ErrorLog /var/log/apache2/error.log
CustomLog /var/log/apache2/ssl_access.log combined

SSLEngine on
SSLCertificateFile /etc/apache2/ssl/server.cer
SSLCertificateKeyFile /etc/apache2/ssl/server.key

BrowserMatch ".*MSIE.*"
nokeepalive ssl-unclean-shutdown
downgrade-1.0 force-response-1.0


In the example above directive “SSLEngine on” enables SSL support virtual host. Directive “SSLCertificateFile” defines a full path of the server's certificate and finally directive “SSLCertificateKeyFile” defines a full path to server's private key. If the private key is secured by password this password will be only needed when starting apache web server.

Any changes to https.conf file such as the changes above require a web server restart. If you encounter some problems during the restart it is likely that this is due to configuration errors in your https.conf file. The actual error should appear in deamon's error log.

Testing of a functionality of our new configuration can be done by using a web browser. The fist attempt to for connection most certainly displays an error message, that the attempt to verify server's certificate failed because, the issuer of the certificate is unknown.

The certificate is not trusted because the issuer certificate is unknown

Importing CA's certificate into the web browser's using its Certificate manager will solve this problem. To add a certificate into a Mozilla Firefox browser navigate to “Preferences > Advanced > Encryption > View certificates > Authorities” and during the import tick the box which says: “This certificate can identify web sites”.

Next attempt to connect the web server should be successful.

SSL server verified certificate

If you want to avoid the need of importing a CA's certificate into the web browser, you can buy server certificate from some commercial authority, which certificates are distributed by the web browser.
4. Two-way SSL authentication

If you have decided that you will require certificate authentication from every client, all you need to do is to add following lines into a virtual host configuration file:

SSLVerifyClient require
SSLVerifyDepth 10
SSLCACertificateFile /etc/apache2/ssl/ca.cer

“SSLVerifyClient require” directive ensures that clients which do not provide a valid certificate from some of the trusted Certificate authorities would not be able to communicate with SSL server. Some CA rely on another CA, which may rely yet on another and so on. Directive “SSLVerifyDepth 10” specifies how far down in the chain of CA reliance, the server will accept CA signed certificate as valid. If, for instance, SSLVerifyDepth directive will hold value 1 then the client's certificate must be signed directly by your trusted CA. In this article, the client's certificate is signed directly by CA and therefore the only sensible value for SSLVerifyDepth directive is 1. Last directive “SSLCACertificateFile” specifies a full path to a Certificate Authority certificate by which a client's certificate was signed.
Do not forget to restart your apache web server after any change made to its configuration files:

# apachectl graceful

If you try to connect to the SSL server without a client certificate an error message will pop up:

SSL peer was unable to negotiate an acceptable set of security parameters.

All what needs to be done is to import previously created a client certificate in PKCS#12 form into to firefox's certificate manager under “Your Certificates” section. This task can be done by navigating to menu then “Preferences > Advanced > Encryption > View certificates > Your certificates”. During the import, you will be asked to enter a password which had been set during the creation of the certificate. Depending on the browser version you use, you may also need to set main password for software token, which is used by the browser to safely store certificates.

Firefox SSL certificate manager

If you make another attempt to connect to the SSL server, browser will automatically pop-up an appropriate certificate for SSL server authentication.

select ssl certificate to by used with ssl connection

After the selection of a valid certificate, the connection to the SSL server will be granted.

SSL server verified certificate
5. Another advantages of SSL authentication

Values from a client certificate can be used by web application for precise identification of the user. It is easy as to use a directive “SSLOptions +StdEnvVars” and mode_ssl will provide information taken from a client certificate as well as a certificate itself to the given web application.

This operation will take a lot of server's run-time, and therefore, it is recommended to use this functionality on for files with certain extension or for files within certain directory as it is shown in the following example:


SSLOptions +StdEnvVars



SSLOptions +StdEnvVars


List of the available variables can be found in a module mod_ssl documentation. Accessing variables provided my mod_ssl is language specific. However, for the sake of completeness, here is a sample of CGI script written in perl which will display a “Common Name” of the client:

#!/usr/bin/perl

use strict;

print "Content-type: text/htmln";
print "n";
print $ENV{"SSL_CLIENT_S_DN_CN"}

Here is an output of the script after its execution by the SSL web server:

mod_ssl - information taken from the client certificate

Mod_ssl also supports a use of above mentioned variables directly from the server's configuration. This way you can restrict an access to some resources for employees of a certain company:


SSLRequire %{SSL_CLIENT_S_DN_O} eq “Jariq.sk Enterprises”


These variables can be also used in conjunction with configuration directive “CustomLog” to enable logging a client's access details . More information can be found in the official mod_ssl documentation.
6. Conclusion

If you have not heard about Two-way SSL authentication yet, it is likely that after reading this article you asked yourself why is this type of SSL authentication not used often in the production environment. The answer is simple – cryptic operations used during SSL connections are difficult to process in regard to the web server resources. It is possible to boost web server performance by so called SSL accelerators ( cards containing a processor optimized for cryptic operations). However, in many cases SSL accelerators are more expensive than the server itself and therefore, Two-way SSL authentication is not attractive to use in the web server environment.
7. Linux Apache2 specific notes:

openning a port 443 is not required, if a configuration file /etc/apache2/ports.conf has defined an IfModule mod_ssl.c directive:


Listen 443


Enabling ssl module can be done by:

a2enmod ssl

If directive IfModule mod_ssl.c in /etc/apache2/ports.conf is defined command a2enmod ssl will also automatically enable listenning on port 443.

Definition of virtual host file needs a slight change:

BrowserMatch “.*MSIE.*” \
nokeepalive ssl-unclean-shutdown \
downgrade-1.0 force-response-1.0

Read More