Like million other hosts in the internet, this box is attacked to exploit vulnerabilities.
I recently saw following piece of code in a Remote File Inclusion (RFI) attack. Although it might be created by a kid, it's still a nice snippet that I want to share with you. Guess what, it actually works.
I hope you see what's wrong here. There's no additional information. This guy is only reporting the impact of a hack. There's no way to help you with this information; furthermore such report doesn't help the TYPO3 community either as our team is unable to analyze it.
The right way:
In short, collect as much information as possible!
In detail:
What happened? What's the impact of the hack? Defacement; your website suddenly delivers malware; there's a new backend user "blackhat"?
When has it happened? When did you recognize the hack? By analyzing the logfiles, when do you estimate did the attacker succeed with his hack?
How have you became aware of the hack? You clients reported malware on your site? You were getting from google to your website and it looks different (with all those links to vi**ra pills).
Where has it happened? on a dedicated server (rootserver, virtual server), on a virtual hosting shared together with other hosting provider customers; is there any other software installed that might be vulnerable
Strange data or behaviour? different website output when accessing the website directly (through a bookmark) or via referrer (directed to from a search engine); new not TYPO3 related files (webshell.pl)
What kind of software is installed? TYPO3 version, list of installed extensions with version numbers (are they up to date); is your server up to date with all those TYPO3 Security advisories
Is your local client safe? did you check your local client with at least two different malware scanners; did you recently access your website via insecure wireless lan; how do you transfer data to your server (via insecure ftp, sftp, scp)
Data you should and we are interested in: TYPO3 sys_log table entries, web server access logs, PHP error logs, modsecurity logs, list of unexpected files or files with a strange access/modification time, OS logs (auth, audit, messages, secure), IDS logs, AIDE/tripwire reports
Bonus: You have already analyzed the complete hack and are now able to report the exact attacker's entry point. Great, your place in the top ten of "best vulnerability reports" is guaranteed. But we're sorry, first rank is already given away! ;-)
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!
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 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.
