about
blog
tutorials
RSA Authentication for TYPO3 4.3
Posted in TYPO3/ on April 30, 2009 by .
Asymmetric Encryption for authentication - a major security improvement
Today, TYPO3 made a huge step forward in regards to security. Dmitry Dulepov has sent a patch (#11016) to the TYPO3 Core mailinglist that implements RSA authentication for TYPO3 Backend and Frontend.
RSA is a method of asymmetric encryption - something you might already know if you are using GnuPG or PGP. A key pair (public and private key) is created and then, a message can be encrypted using the public key. Only the owner of the private key is later able to decrypt the message.
In case of TYPO3, TYPO3 itself will create a key pair for each login attempt. The public key is given to the client (your browser) which will use it to encrypt you password. So sniffing your traffic will not reveal the password and you are able to login to your TYPO3 installation in an unencrypted wireless LAN without having second thoughts on a possible compromise later.
TYPO3 will then decrypt the message with the private key so that the plain-text password is again available on TYPO3 side.
Having plain-text passwords available on TYPO3 side (not only hashed ones like currently) will enable the possibility to apply arbitrary complex transformations on (original) plain-text passwords before being stored into the database. You might even consider to encrypt your passwords in the database.
The next step and also planned to be shipped with TYPO3 4.3 are salted hashed passwords for FE and BE user accounts. An already existing extension (t3sec_saltedpw) will therefore be integrated in TYPO3 Core.
RSA authentication will replace the currently used superchallenge authentication method. However, if you are already using SSL to secure authentications for FE or BE ("normal login method"), there's no need to use RSA.
Give TYPO3 4.3 a try; test and review the upcoming alpha3 release! You won't regret it.
Thanks to Dmitry for his efforts. "Inspiring people to share" at its best!
Backups are great
Posted in TYPO3/ on April 22, 2009 by .
Protect TYPO3 export files
TYPO3 allows to create export files. They are useful as poor man's backups or if you want to move your TYPO3 instance to another server. TYPO3 allows to configure which data to include in such an export. Usually they are written to or below fileadmin directory.
What's wrong about it?
These files might contain credentials (username and passwords of FE and BE users) and are written below DocumentRoot (publicely available). Think of having DirectoryIndex enabled or an easy to guess filename (backup.t3d)!
Using apache as web server it is easy to restrict access to such files. Simply put following lines in the vhost configuration:
<FilesMatch "\.t3d$">
Order allow,deny
Deny from all
</FilesMatch>
Further requests to such files will result in a 403 Forbidden status message.
The TYPO3 Install Tool - great help for Blackhats
Posted in TYPO3/ on April 21, 2009 by .
Protect the TYPO3 Install Tool
The TYPO3 install tool is a great help when initially installing TYPO3, configuring TYPO3 or debugging it.
As it should run during the install process, it's a complete isolated module. It is restricted by a password only.
When TYPO3 is running smoothly, there's no need to let the tool enabled. Enabling it is done with creation of one single file called
typo3conf/ENABLE_INSTALL_TOOL
Obviously the first task is to change the initial password (joh316) to something different and more complex. Just assign the md5-hash of the new password to
$TYPO3_CONF_VARS['BE']['installToolPassword']
and put the line in file
typo3conf/localconf.php
If you regulary need to access the tool, set up an additional barrier like a htaccess protection for directory
typo3/install
So what's the problem of the install tool?
It allows to modify files with the rights of the web server user account. If someone unauthorized gains access to the tool, he has the same possibilities like somebody with a local user account on the web server.
In the past there were several reports where Blackhats used the TYPO3 Install Tool to setup a webshell on the server. You obviously want to avoid that.
If your website administrators need to use the TYPO3 Install Tool and therefore are able to create the ENABLE_INSTALL_TOOL file by themselfes (using ftp access or whatever), you might want to consider running an hourly cronjob to remove these files again.
Call following command every hour as root:
find / -name ENABLE_INSTALL_TOOL -type f -mmin +60 -exec rm -f {} \;
This removes such files if they are older than 60 minutes.
Protect your database
Posted in database/ on April 21, 2009 by .
Limit access to the database server
You have a web application firewall or even a dedicated appliance to protect your web server? If so, that's great. But, what are you doing to protect the data itself?
The database server much more deserves to be properly secured; it's where your actual data is stored. The web server together with TYPO3 Core is just a nice frontend to the database.
To back that up:
In February 2009, TYPO3 fixed a severe vulnerability where any file the web server user account has access to was exposed to website users. (TYPO3-SA-2009-002). Crackers exploited that vulnerability and placed a fake message on the website of the well-known german soccer team FC Schalke 04. That message announced the dismissal of a player. You can imagine that this attracted attention by press and damaged the teams reputation.
According to reports, the cracker did not use TYPO3 at all. No, he just connected to the database server with the credentials he gained by exploiting the vulnerability and modified data there.
So the web site service provider failed to secure the database server.
How to avoid it:
If your web and database server are on the same host, there's no need to let the database server listen on a publicly available interface. Bind the server to localhost (127.0.0.1) only!
If your web and database server are on different hosts, restrict access to the database server with a firewall rule to the subnet only where you web servers are running in. The connection could be secured by using a VPN or VLAN.
Then, on the database server itself, let the database user only connect from a specific IP or subnet to the TYPO database. (see tutorial IP restricted DB access)
First things first
Posted in advisory/ on April 21, 2009 by .
Subscribe to the announce mailinglist
As security aware person you want to be informed of security updates. Nothing easier than that. The TYPO3 announce mailinglist is a low traffic list; only common major minor releases are announced besides the important security updates.
On that list, security fixes for the TYPO3 Core and for TYPO3 extensions (available in TER) are announced.
In the past, for severe vulnerabilities and according security fixes pre-announcement have been posted there so that every TYPO3 admin is prepared for immediate action.
So, if you are maintaining TYPO3 websites, please make sure to be subscribed to that list.
In addition, you might want to subscribe to the Security newsfeed listed on http://news.typo3.org/xml-feeds/
Both, announce mailinglist and security newsfeed are updated when there's a new security advisory. But in case of mail server problems on your side you may want have a backup in place - the security news feed.
