Best of RFI - Part 1

Posted in hacks/PHP/ on May 16, 2009 by Marcus.

Even a loser gets lucky sometimes

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.

Disclaimer: I'm unsure about the license.

<?php
function ConvertBytes($number){
        $len=strlen($number);
        if($len<4){
                returnsprintf("%d b",$number);
        }
        if(($len>=4)&&($len<=6)){
                returnsprintf("%0.2f Kb",$number/1024);
        }
        if(($len>=7)&&($len<=9)){
                returnsprintf("%0.2f Mb",$number/1024/1024);
        }
        returnsprintf("%0.2f Gb",$number/1024/1024/1024);
}                
       

$dir=@getcwd();

        // free
$freeBytes= disk_free_space($dir);
$freeUnits= ConvertBytes($freeBytes);
if(!$freeUnits)$freeUnits=0;

        // total
$allBytes= disk_total_space($dir);
$allUnits= ConvertBytes($allBytes);
if(!$allUnits)$allUnits=0;

        // used
$usedUnits= ConvertBytes($allBytes-$freeBytes);

       
echo('free: '  .$freeUnits."<br>\r\n");
echo('total: '.$allUnits  ."<br>\r\n");
echo('used: '  .$usedUnits."<br>\r\n");
?>

I personally like the CamelCase approach, the sprintf() usage and the early returns. What do you think?

Permalink | Comments: 2
Tags: php, rfi, , snippet
Views: 0


How not to report a security incident

Posted in hacks/ on May 14, 2009 by Marcus.

Have a look, I got hacked.

Your TYPO3 website has been hacked and you need quick help? Well, then help us too.

A report like following reached the TYPO3 Security Team:

Hi guys,
have a look at http://example.org/path/to/website/defacement/, I got hacked.

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! ;-)

Permalink | Comments: 2
Tags:  reporting
Views: 0


RSA Authentication for TYPO3 4.3

Posted in TYPO3/ on April 30, 2009 by Marcus.

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!

Permalink | Comments: 2
Tags: typo3, authentication, ,rsa, , encryption
Views: 0


Backups are great

Posted in TYPO3/ on April 22, 2009 by Marcus.

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.

Permalink | Comments: 0
Tags: t3d, apache
Views: 0


The TYPO3 Install Tool - great help for Blackhats

Posted in TYPO3/ on April 21, 2009 by Marcus.

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.

Permalink | Comments: 1
Tags:  installtool
Views: 0


Categories

  • advisory(9)
  • book(1)
  • [-]database(1)
  • exploit(1)
  • hacks(2)
  • others(6)
  • PHP(1)
  • TYPO3(23)