Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

FileZilla Has an Evil Twin That Steals FTP Logins

Unknown Lamer posted about 9 months ago | from the install-our-toolbar-today dept.

Security 197

Nerval's Lobster writes "On the same day the world discovered Western intelligence agencies were siphoning user information from Angry Birds and other popular smartphone apps, a leading antivirus developer revealed hackers are doing the same thing with one of the most popular open-source applications on the Internet. Maliciously modified versions of the popular FTP application FileZilla look and act just like the real thing, but include extra code that steals the login data typed in by users and sends it to an unauthorized server using the same FTP operation launched by the user without going through a firewall that might spot what it's doing, according to an alert posted this afternoon by antivirus developer Avast Software. The malicious version is fully functional, uses the same graphical interface and component file names as the original, and masks itself further by avoiding any suspicious entries in the system registry, overt attempts to communicate with outside servers or other changes, according to the Jan. 27 alert from Avast. The most obvious differences are that the poisoned version of filezilla.exe is 6.8MB smaller than the real thing and there are two DLL libraries included in the fake that are not present in the original. They are labeled ibgcc_s_dw2-1.dll and libstdc++-6.dll, according to Avast. The official version's Nullsoft installer is v2.45-Unicode; the evil twin uses v2.46.3-Unicode. Automatic updates also fail on the poisoned version 'which is most likely a protection to prevent overwriting of the malware binaries,' Avast added."

Sorry! There are no comments related to the filter you selected.

Also Ran (0)

Anonymous Coward | about 9 months ago | (#46089377)

ibgcc_s_dw2-1.dll appears in GIMP 2 and EaseUS Partition master, libstdc++-6.dll in GIMP 2.

Re:Also Ran (5, Informative)

Anonymous Coward | about 9 months ago | (#46089399)

Mostly because these dll's are present in projects compiled with MingW.

Re:Also Ran (0)

Anonymous Coward | about 9 months ago | (#46089491)

So what?

Gorilla Cuntilla (-1, Offtopic)

smitty_one_each (243267) | about 9 months ago | (#46089379)

Gorilla [youtube.com]
FileZilla
Fur Transfer Protocol
Killa
Burma Shave

Blame Source Forge... (1)

Anonymous Coward | about 9 months ago | (#46089381)

...for their new installer

Re:Blame Source Forge... (5, Informative)

Anonymous Coward | about 9 months ago | (#46089889)

it wouldn't surprise me that if it were SourceForge's own "custom downloader" that's the one pushing the altered versions with login stealing functionality... it's been pushing adware and other crap too and FileZilla especially has been hit by this. Here's a short selection of complaints from the FileZilla forums:

https://forum.filezilla-project.org/viewtopic.php?f=2&t=30240
(this one has screenshots documenting the EXE installer hijacking done by SourceForge)

or this one: https://forum.filezilla-project.org/viewtopic.php?f=1&t=31127
and more... https://forum.filezilla-project.org/search.php?keywords=sourceforge+adware

Not the same thing (1)

Anonymous Coward | about 9 months ago | (#46089383)

The NSA listens to data that the original, unmodified games and apps send. The FileZilla "clone" is manipulated software. If you use the original, your data is not sent to some hacker and hackers have no way of intercepting your data (use of properly encrypted protocols presumed, so not FTP).

Defamation (-1, Offtopic)

DarkOx (621550) | about 9 months ago | (#46089387)

I hope the authors sue the fuck out if the NSA for defamation. Releasing a faulty product proporting to be their own. I say that even though as a tax payer I am the one who will really pay the damages. This sort of thing isn't ok and deserves public shaming

Re:Defamation (5, Insightful)

Dan East (318230) | about 9 months ago | (#46089411)

You really think the NSA is sending their data to Russian servers? That's where the article says it's going.

Re:Defamation (0, Troll)

Anonymous Coward | about 9 months ago | (#46089427)

Yes, because the NSA officially is not allowed to spy on their own citizens, it will send the information to a friendly country like russia. The russian's intelligence agency will then forward this information to the NSA and no harm has been done.

Re:Defamation (0)

Anonymous Coward | about 9 months ago | (#46089443)

Yes, because the NSA officially is not allowed to spy on their own citizens, it will send the information to a friendly country like russia. The russian's intelligence agency will then forward this information to the NSA and no harm has been done.

And somehow, this textbook definition of strawman purchase is allowed to happen.

Re:Defamation (0, Redundant)

Joce640k (829181) | about 9 months ago | (#46089777)

You really think the NSA is sending their data to Russian servers? That's where the article says it's going.

That's exactly what the NSA wants you to think...

Re:Defamation (4, Funny)

smallfries (601545) | about 9 months ago | (#46089421)

So... am I the only one that thinks the NSA version sounds like the better option? Smaller, newer runtime, other bufixes. Sounds like an upgrade.

Re:Defamation (0)

Anonymous Coward | about 9 months ago | (#46089461)

So... am I the only one that thinks the NSA version sounds like the better option? Smaller, newer runtime, other bufixes. Sounds like an upgrade.

Yes, and I'm sure they can make crypto much more efficient too...by removing all that "excess" code.

Re:Defamation (1)

SuricouRaven (1897204) | about 9 months ago | (#46089503)

There's no evidence this is an NSA program.

Re:Defamation (3, Insightful)

Chrisq (894406) | about 9 months ago | (#46089719)

There's no evidence this is an NSA program.

To be honest I really hope there wouldn't be!

Re:Defamation (2)

SuricouRaven (1897204) | about 9 months ago | (#46089843)

Dependency upon additional external DLLs? If this was an NSA thing, they'd design it better than that.

Unless they deliberately introduced an obvious substandard design element precisely to make people think someone else did it, of course.

What about GNU/Linux ? (1)

Anonymous Coward | about 9 months ago | (#46089389)

I am under the assumption that these dll's (ibgcc_s_dw2-1.dll and libstdc++-6.dll) indicate that this version may have been compiled with MingW. (I am not sure about this, please correct me if I'm wrong) This would mean that it would be safe to assume that there could easily be a Linux version of that FileZilla Evil Twin out there...

native elders to give ny ny to chelsea clinton (-1)

Anonymous Coward | about 9 months ago | (#46089393)

as a way of saying thanks to hillary for helping us years ago. it's badly used but could be restored is the thinking. creation is still the sleekest partnering process

Firewall (5, Interesting)

Dan East (318230) | about 9 months ago | (#46089407)

I'm not fully understanding the "sends it to an unauthorized server using the same FTP operation launched by the user without going through a firewall that might spot what it's doing" part. It's posting the stolen credentials via http, not FTP. If FileZilla is only given access to the FTP port then it should block this behavior, correct? I'm just not understanding what's magical about this - any app that is already given blanket permission to access the network in a general way can send data to places it shouldn't go without being blocked by firewalls. They make it sound like there's something special or exotic it's doing to avoid the firewall and I'm not understanding exactly what that is.

Re:Firewall (2, Interesting)

Anonymous Coward | about 9 months ago | (#46089431)

More importantly, any app which legitimately needs access to an internet-enabled DNS resolver can exfiltrate data without permission to access the internet on its own. What you need in order to catch this kind of thing is an IDS, not a firewall.

Re:Firewall (1)

mwvdlee (775178) | about 9 months ago | (#46089507)

As long as an app can connect to a random IP, there is a way to send data.
No need for any particular port access if you control the receiving server.

Re:Firewall (4, Interesting)

fatphil (181876) | about 9 months ago | (#46089937)

Absolutely, side channels are everywhere if all you care about is small packets of data. You don't even need to "connect" to pass the data, as some things happen before the connection you'd think of filtering. Try resolving the domain name fatphil.hunter2.haxorsrus.ru., and when the DNS server for *.haxorsrus.ru. responds with a random address, you never need to connect to it on any port, the payload's been delivered already. You can't filter DNS without breaking way too much of the internet.

Re:Firewall (0)

Anonymous Coward | about 9 months ago | (#46089471)

I believe it's using FTP's ability to do server to server transfers. Usually called FXP. This causes the user's server to connect a remote server.

Re:Firewall (2)

jones_supa (887896) | about 9 months ago | (#46089529)

The summary claims that it's using "same FTP operation launched by the user" to send the credentials. FXP would require establishing another connection to the FTP server. Besides the FXP feature is turned off on most FTP servers anyway.

Re:Firewall (0)

Anonymous Coward | about 9 months ago | (#46089761)

A few things, even though I believe it uses https to do the nasty. See other replies.

1. I believe it is possible to setup a FTP server/client or write one yourself that would allow any incoming port connection to be accepted. You could even use the port numbers and multiple commands as a way of encoding the login. A pit of coding and you have nice list of logins
2. Yes, most public FTP servers forbid FXP for guests. But many allow it for privileged users.

Re:Firewall (5, Insightful)

Dan East (318230) | about 9 months ago | (#46089537)

That would indeed be a bit more exotic, but from what I can tell it's just doing a simple http get to the Russian server with the encoded credentials. From the Avast report:
https://blog.avast.com/wp-cont... [avast.com]

The DNS lookup to the Russian server and the http get are there as plain as day.

Re:Firewall (4, Informative)

mysidia (191772) | about 9 months ago | (#46089845)

If FileZilla is only given access to the FTP port then it should block this behavior, correct?

What "FTP" port? Every FTP transfer requires a control connection and a data connection --- the data connection is established based on a procedure that depends on transfer mode -- there is standard mode, or passive mode (for firewall traversal).

In either case, the destination port number is not a specific FTP port, but a port number dynamically allocated by the server and presented to the client, or vice-versa

In Passive mode, to establish the data connection, the FTP client must open a connection back to the server ON ANY PORT specified by the server, sourced from its ftp-data port.

In Active mode, the client must select an ephemeral port from the 32768 to 65535 range, send it over the control connection, and accept a TCP connection from the server.

Re:Firewall (2)

Bacon Bits (926911) | about 9 months ago | (#46090021)

FTP: Still sucking because it was invented with NCP in mind.

Re:Firewall (1)

fatphil (181876) | about 9 months ago | (#46090055)

Ignore the summary, and *both* links, there's mangled illogic everywhere.

"You canâ€(TM)t find any suspicious behavior, entries in the system registry, communication or changes in application GUI." Apart from the suspicious behaviour and the communication, that is - duh!

If they can't describe what it does, they clearly don't understand what it does.

Just make sure you compare known hashes which you got from a secure (and trusted by you) server when you download binaries. Then this problem mostly disappears (unless the NSA wants in on the action).

ibgcc_s_dw2-1.dll (0)

Anonymous Coward | about 9 months ago | (#46089423)

ibgcc_s_dw2-1.dll

Well done, editors.

people still use FTP? (0)

Anonymous Coward | about 9 months ago | (#46089437)

WTF? It's 2014. SSH has existed for almost 19 years already.

Re: people still use FTP? (3, Insightful)

DVega (211997) | about 9 months ago | (#46089773)

SSH will not help here. A modified SSH client (eg. WinSCP) could do exactly the same. It can even steal your private keys.

Re: people still use FTP? (0)

Anonymous Coward | about 9 months ago | (#46089811)

A genuine copy of WinSCP is signed with a trusted publisher certificate, which Windows will tell you about, when you install WinSCP.

Re:people still use FTP? (1)

hawkinspeter (831501) | about 9 months ago | (#46089785)

Fair point, but is it included in Windows?

Re:people still use FTP? (2)

Kazoo the Clown (644526) | about 9 months ago | (#46090173)

Yes, and it's more than 10x slower than FTP.

What we need is a mechanism (1)

vikingpower (768921) | about 9 months ago | (#46089439)

to compile your own binaries from source, and then letting you compare its fingerprint with "official" pre-compiled binaries. No, not a simple hash. Various fingerprints, spread over security-sensitive parts of the software. No idea if such a thing exists, although I remember having seen a discussion here on /. last year.

Re:What we need is a mechanism (0, Informative)

Anonymous Coward | about 9 months ago | (#46089451)

What you seem to want is Gentoo.

Re:What we need is a mechanism (5, Funny)

camperdave (969942) | about 9 months ago | (#46089729)

What you seem to want is Gentoo.

Gentoo? I've only got an 8 core machine with 64G of RAM.

Re:What we need is a mechanism (4, Informative)

drinkypoo (153816) | about 9 months ago | (#46089765)

The question is really do you have SSD. It only takes a few days to build gentoo on some architecture which actually benefits from it, like a K6... with a laptop drive. On a modern machine with a SSD you ought to be able to knock it out in actually quite reasonable time.

Re:What we need is a mechanism (1)

Shinobi (19308) | about 9 months ago | (#46090063)

With 64GiB, he doesn't even need a SSD. Just use a RAM disk for the build process

Re:What we need is a mechanism (1)

MrBingoBoingo (3481277) | about 9 months ago | (#46089457)

These things actually do indeed exist. You know in the *NIX and Open source universe things that approach this are rather standard.

Re:What we need is a mechanism (1)

vikingpower (768921) | about 9 months ago | (#46089595)

No need to be condescending. I use FOSS all the time. Yet, AFAIK, there is no such mechanism that lets a developer introduce security fingerprints which "tag" a critical section of code, and which the compiler adds to the binaries, in such a way that after compiling source locally, you can check critical parts of your binaries on compliance with the "official" fingerprints. Or am I mistaken ?

Re:What we need is a mechanism (4, Informative)

gnasher719 (869701) | about 9 months ago | (#46089679)

No need to be condescending. I use FOSS all the time. Yet, AFAIK, there is no such mechanism that lets a developer introduce security fingerprints which "tag" a critical section of code, and which the compiler adds to the binaries, in such a way that after compiling source locally, you can check critical parts of your binaries on compliance with the "official" fingerprints. Or am I mistaken ?

There is no mechanism in most compilers/linkers that allows you to recreate the exact same executable that someone else built, byte by byte. You would need a compiler to be hundred percent deterministic. I could imagine some optimisation algorithms working better with some randomisation, so that wouldn't be possible. a+b could sometimes translate to "load a, add b" and sometimes "load b, add a". Things like the __FILE__ macro in C or C++ include the full path of the file, which is different on your machine than on mine. And of course you'd need the exact same build environment. Exact same version of every library that is used.

Re:What we need is a mechanism (2)

ppanon (16583) | about 9 months ago | (#46089707)

It doesn't exist because the results of your compilation would depend on the version of the compiler you used to do the compilation and what optimization flags you used (due to target object code and optimizations performed). Either you compile from source which you can first check against a known cryptographic checksum, or you run binaries that have been cryptographically signed by the developer. What you are suggesting would require unnecessary added complexity for no gain in security.

Re:What we need is a mechanism (3, Insightful)

mwvdlee (775178) | about 9 months ago | (#46089487)

Then the problem shifts from getting your binaries from the right website to getting your sourcecode from the right website.

Re:What we need is a mechanism (1)

vikingpower (768921) | about 9 months ago | (#46089597)

Correct. That, however, can be in part dealt with by taking hashes....

Re:What we need is a mechanism (1)

Anonymous Coward | about 9 months ago | (#46089697)

hashes do not help, if somebody compromised the source, they can also compromise the hashes by changing them to match
if you had been reading the news since last summer, you would see that injection/impersonation/etc. attacks on HTTP (and other protocols) are confirmed to be in use in the wild, and even before that, many malware/viruses have been found redirecting traffic (albeit in a more hacky way)

the same way that a few years ago one had to be careful with diskettes and where had they been and where were they coming from, now it is the internet, and arguably is a much harder problem, with internet you need to trust the router, the ISP, and all the routers that led you to the server, in addition to the server. That's too much trust to be put spread on many things you cannot control.
When computers were not connected the risk of data exfiltration was much lower than today.

OSs and they security models are totally outdated, and/or based on a trust model that is hardly true today. What we need is an OS whose security model allows fine grain access/deny (deny should be "stealth", that is, processes should not be able to know they are being denied) permissions on EVERY i/o a program possibly make, whether it is network access to a given port, access to a contact/calendar database, access to files, access to sensors, etc.
Would that prevent exfiltration? not 100%, but it would make it harder, right now it is trivial for any app to harvest data and then send it to some other place we were attempting to connect to.
Right now the OS trusts and gives too much freedom to processes.

that still does not helps the trust issue on the net though.

Re:What we need is a mechanism (2)

Arancaytar (966377) | about 9 months ago | (#46089753)

The binary is never going to be identical - it contains all kinds of platform- or compiler-dependent stuff, as well as timestamps. Depending on optimization flags, the compiler may even restructure it differently, with no practical way to isolate security-relevant portions that should remain unchanged. And a malicious payloads could be basically anywhere in the executable, so every part is security-relevant.

The approach is still good, but since it already involves distributing the source code, it would make more sense to sign the source instead of the binary.

Re:What we need is a mechanism (3, Informative)

Anonymous Coward | about 9 months ago | (#46089795)

You're over thinking it.

if you're compiling from source, check the hash of the source against an official source of the source.

If you're running a pre-compiled binary, then check the hash of the binary with an official source of the binary.

Passwords are stored in plain text anyway (1, Informative)

Anonymous Coward | about 9 months ago | (#46089449)

Take a look in
%APPDATA%\FileZilla\sitemanager.xml

Re:Passwords are stored in plain text anyway (2)

ledow (319597) | about 9 months ago | (#46089925)

Well, yes, because you have to store and send the original password.

You can't send the hash to a remote FTP server as a login, they won't accept it. And the definition of a hash is basically to make it difficult to "work backwards" to a username from it.

So, somewhere, you either have to store in plaintext or in a file which the program encrypts and has full capabilities and permissions to read. About the only way to do this efficiently and safely is to have a "locked" wallet kind of affair that the user has to supply a global password too.

The problem here is NOT that the passwords are stored (FileZilla is an end-user tool, so the chances of some ISP "losing" thousands of passwords by using it is stupidity itself). It's that the program itself is malware and capable of doing anything that FileZilla has permission to do - e.g. read from the keyboard and connect to remote servers.

Re:Passwords are stored in plain text anyway (1)

Arancaytar (966377) | about 9 months ago | (#46089971)

What else are you going to store? Of course you could use sftp and rely on ssh-agent to manage the key, but then you'd be using Linux instead of Windows with FileZilla.

Re:Passwords are stored in plain text anyway (0)

Anonymous Coward | about 9 months ago | (#46089979)

In my version it is in filezilla.xml but in clear nonetheless.

Re:Passwords are stored in plain text anyway (2)

KiloByte (825081) | about 9 months ago | (#46090065)

It's a FTP client! If you use passwords there, you're doing it wrong.

It's an ancient protocol that sends logins and passwords over the network in plain text, and you're concerned with storing them on your disk unencrypted?

This dll names look like legal ones (0)

Anonymous Coward | about 9 months ago | (#46089455)

This dll names look like legal ones atleast in Linux world. I several time install libstdc++ as an dependencies of other packages.

Re:This dll names look like legal ones (0)

Anonymous Coward | about 9 months ago | (#46089469)

Good software can be used for evil. News at 11.

Re:This dll names look like legal ones (3, Informative)

jones_supa (887896) | about 9 months ago | (#46089541)

This dll names look like legal ones atleast in Linux world. I several time install libstdc++ as an dependencies of other packages.

Duh, logic fail. The article does not claim that these particular DLLs provide the malicious code, but are simply some easily observable differences between the friendly and malicious version.

Re:This dll names look like legal ones (0)

Anonymous Coward | about 9 months ago | (#46089807)

This dll names look like legal ones atleast in Linux world. I several time install libstdc++ as an dependencies of other packages.

Duh, logic fail. The article does not claim that these particular DLLs provide the malicious code, but are simply some easily observable differences between the friendly and malicious version.

Agreed. But where are the information in article for that something like "these are normal DLLs using for other purposes. They just should not be there as they are not part of official one." Read summary, and a windows user will assume that this DLLs must be have code for hack.

This is BIGGER than Filezilla (2)

gooman (709147) | about 9 months ago | (#46089459)

Without a doubt this will be used as propaganda against the entire Open Source community. Everything OSS.
I'd bet the Sales & Marketing Dept. at Microsoft and the all the rest will have talking points in their sales peoples hands before the end of the day.

At this moment, there is nothing about this on the Filezilla project's website. GET ON IT people!
An accurate explanation should be front page before the scare tactics have a chance to work.
Plus, users need an instant & easy way to identify if their version is legit to ease their minds.

Now concerning the bad guys... I'd suggest some sort of vigilante justice is in order.
Perhaps identifying the rogue servers and uploading something the local authorities might be interested in.

Re:This is BIGGER than Open Source (0)

Anonymous Coward | about 9 months ago | (#46089489)

Any software can be malicious, regardless of whether you paid for it or whether you can see the source code. Quick, criminalize the entire software industry. It's the only way to be safe from the terrorists.

Actually, Windows is partly to blame here (2)

davide marney (231845) | about 9 months ago | (#46089619)

There is no equivalent in the Windows world to the signed source repositories of Linux. Windows keeps itself updated through signed updates, but does nothing about the other thousands of applications and libraries that are installed. There's probably a good reason why this rogue FTP app isn't in a repository, those evil library files would have to be included in the dependency manifests for all to see. These things survive in Windows because users are forced to install everything from the untrusted web.

Re:Actually, Windows is partly to blame here (1)

Anonymous Coward | about 9 months ago | (#46089641)

There is. Win8/Store.

Re:Actually, Windows is partly to blame here (1)

Anonymous Coward | about 9 months ago | (#46089685)

Windows software can have digital signatures. WinSCP is third-party software, and its installer is signed.

Re:Actually, Windows is partly to blame here (1)

hawkinspeter (831501) | about 9 months ago | (#46089803)

There's a world of difference between software having a digital signature and the software installer actually checking the digital signature. Does Windows even have a mechanism to check the signature?

Re:Actually, Windows is partly to blame here (3, Informative)

heypete (60671) | about 9 months ago | (#46089895)

There's a world of difference between software having a digital signature and the software installer actually checking the digital signature. Does Windows even have a mechanism to check the signature?

Yes. Many (most?) installers for Windows check the signature when you open the installer. This has been the case for ages, with even Windows XP checking signatures (though not for nearly as many things as Windows Vista/7/8 do).

If a program wants admin rights (and many installers do), Windows will check the signature and display a different prompt for signed and unsigned code (see here [wikipedia.org] for an example).

Re:Actually, Windows is partly to blame here (1)

hawkinspeter (831501) | about 9 months ago | (#46089969)

So, it's the software that you download that verifies itself? Or, does Windows have a list of checked software along with their signatures?

I had a quick look in your link to the UAC and couldn't see much relevance as it all seemed to be about elevating privileges rather than authenticating 3rd party software. I've never seen Windows do any checking except for drivers.

Re:Actually, Windows is partly to blame here (0)

Anonymous Coward | about 9 months ago | (#46090101)

Windows checks software certificates with public key cryptography, in the same way that web browsers check SSL certificates. Martin Pikryl's certificate used to sign WinSCP is issued by VeriSign.

Re:Actually, Windows is partly to blame here (0)

Anonymous Coward | about 9 months ago | (#46090185)

No, this is OS level feature.

Any application marked as downloaded from Internet is verified before running and shows a confirmation dialog saying either "The publisher can't be verified. Do you want to run this? [red shield icon] Publisher: unknown" or "Do you want to run this? [yellow shield icon] Publisher: (signature here)".

You can also manually check it by going to Properties - Digital signatures.

And your look at UAC prompt was too quick - did you miss the part where it's different depending on whether a program requesting admin access has a valid signature?

Re:Actually, Windows is partly to blame here (1)

fatphil (181876) | about 9 months ago | (#46090085)

> These things survive in Windows because users are forced to install everything from the untrusted web.

Deeper - they survive in Windows because users don't give a damn 99.9% of the time, and the only .1% of the time is the short period after a fatal infection, and is quickly forgotten. If you've worked in IT, you'll know that educating users is a futile goal. (As is trying to label all bad things with a "this is bad" label, which is stupidly what all anti-virus programs do.)

Re:This is BIGGER than Filezilla (0)

Anonymous Coward | about 9 months ago | (#46089643)

This is not a big deal really.

This is just infected copy, there are plenty of programs closed source or not, that may have infected copies. People do understand what virus is.

Re:This is BIGGER than Filezilla (1)

Alarash (746254) | about 9 months ago | (#46089695)

When was the last time you heard Microsoft bash OSS? I'm genuinely curious. I've only seen them pushing code to Git or opening their own specs or frameworks lately (MVC, for instance). I think your point is correct, but I don't think Microsoft is the right example anymore.

Re:This is BIGGER than Filezilla (1)

oscrivellodds (1124383) | about 9 months ago | (#46089825)

Plus, users need an instant & easy way to identify if their version is legit to ease their minds.

How about searching for "ibgcc" on your computer? Seems instant enough.

Re:This is BIGGER than Filezilla (1)

Anonymous Coward | about 9 months ago | (#46089841)

Indeed, what size is the legitimate file and what size is the smaller corrupt one? It's OK going about saying there's a problem but if people don't know how to identify it then how can they do anything about it?

Re:This is BIGGER than Filezilla (0)

Anonymous Coward | about 9 months ago | (#46089873)

I'd bet the Sales & Marketing Dept. at Microsoft and the all the rest will have talking points in their sales peoples hands before the end of the day. ...
Plus, users need an instant & easy way to identify if their version is legit to ease their minds.

Linux Users: You're fine.
Apple Users: You're fine.
BSD Users: You're fine.
Only Windows Users need worry about this attack. Fortunately users of signed software repositories (as on Linux) are assuredly not vulnerable to this type of exploit.

Sounds anti-MS, eh? Well, they could use it to at least push W8 app store as a better model for distributing software -- I'd say a 3rd party software repository system that allows trusting multiple repos like on Linux would be best, but you know, vendor lockin.

Re:This is BIGGER than Filezilla (0)

Anonymous Coward | about 9 months ago | (#46090005)

Windows verifies signed installers from multiple publishers and conspicuously warns you not to install unsigned software. But please, continue spreading your anti-Microsoft propaganda.

*sigh* (-1, Troll)

Anonymous Coward | about 9 months ago | (#46089465)

Thanks Obama. :|

Gayniggers To The RESCUE! (-1)

Anonymous Coward | about 9 months ago | (#46089525)

Perform an Ultra-Swip-Over of the Earth and Upbeam the tainted copies of FileZilla, before the Evil Female Creatures steal every Man's precious passwords!

D'oh!! (3, Insightful)

benjfowler (239527) | about 9 months ago | (#46089493)

Stubbed my toe. NSA's fault!!

Re:D'oh!! (0)

hb253 (764272) | about 9 months ago | (#46089727)

Thanks Obama. >:-(

Two sane ways to install free software. (4, Insightful)

Arancaytar (966377) | about 9 months ago | (#46089497)

1. package manager of your distro (ie. trust someone trustworthy to curate)
2. git clone; make (ie. get it from the developers directly)

Anything else is basically eating candy you found on the street.

Re:Two sane ways to install free software. (0)

Anonymous Coward | about 9 months ago | (#46089533)

But, street candy is so sweet!

Re:Two sane ways to install free software. (0)

Anonymous Coward | about 9 months ago | (#46089881)

Anything else is basically eating candy you found on the street.

King.com lawyers will be sending you a cease and desist letter for using that candy themed car analogy.

Re:Two sane ways to install free software. (1)

fatphil (181876) | about 9 months ago | (#46090155)

"Anything else is basically eating candy you found on the street."

Wow, that's the best description I've heard in a long time. It's 100% bang on. People like candy...

However, downloading the source means that you're trusting the compiler or the virtual machine that's running the code. OK, signed gcc straight from debian, that I trust (but there's no need to follow up with a Thompson Trusting Trust reference, I'm fully aware of the principle). But, to be honest, I don't trust the guys who are trying to push a java VM on me (at least one that will work with a program I was interested in running, but can do without).

Whoever needs a GUI FTP client deserves that. (0)

Anonymous Coward | about 9 months ago | (#46089505)

OK, OK. I've asbestos underwear ;-)

On a more serious note: the problem is of course one of trust and end-user abilities. We need a solution for that. And it ain't easy.

No, walled gardens is not *my* favourite. But whenever I install some random binary on my box and get pwned, I know I (or my trust model) am to blame.

Re:Whoever needs a GUI FTP client deserves that. (-1)

Anonymous Coward | about 9 months ago | (#46089557)

Whoever needs a GUI FTP client is an inbred hick who loves the taste of mom's homemade fish tacos.

Malware installers are to blame (1)

Anonymous Coward | about 9 months ago | (#46089657)

People don't know anymore what a trusted installer is. The right way to install software, if you don't use a package manager, used to be to download the installer from the developer's site and verify its authenticity. Then you could be reasonably sure that it installs the right thing. Now so many legitimate programs use malware-bundled installers that users can't distinguish a good installer from a bad one anymore, because all of them have gone bad.

Update your HOSTS file...yes really. (5, Informative)

Bearhouse (1034238) | about 9 months ago | (#46089669)

From TFA

Stolen data is sent to the IP 144.76.120.243 that belongs [to a] server hosted in Germany.

"We found 3 domains that link to same IP:
go-upload.ru created 2012.09.23
aliserv2013.ru created 2013.09.09
ngusto-uro.ru created 2013.09.19

Unfortunately, domains are registered through the infamous Russian domain registrar Naunet.ru, which is associated with malware and spam activities. This registrar hides client contact info and ignores requests to suspend illegal domains.

Re:Update your HOSTS file...yes really. (0)

Anonymous Coward | about 9 months ago | (#46089991)

Care to share the SHA-256?

Isn't this what Malware/AV tools are for? (2)

Virtucon (127420) | about 9 months ago | (#46089791)

This is why we use AV/Malware tools isn't it? Malware is distributed in a lot of different ways and if you download a corrupted installer or image from a questionable site then you should expect something extra with what you're getting. This is what the AV vendors should be watching out for but also take a few minutes of common sense when downloading, otherwise expect to have your info stolen or your system compromised. While I'm glad the Avast researcher here published the warning, I liken this to stories about the NSA, "One more corrupted installer that installs Malware, read all about it!" Now if he'd found out that the information was being leaked back to Germany for spying then it would have been more interesting.

File under 1001 Bleeding Obvious Things (2)

Demonoid-Penguin (1669014) | about 9 months ago | (#46089831)

Install only from the source. If you install from a third-party source or don't check the md5sum what did you expect?

Tag story as stupid

Hey, I just found a bottle of whisky by the side of the road.... Party! (what could go wrong?)

obvious solution (2)

edxwelch (600979) | about 9 months ago | (#46089859)

I assume the malicious version appeared from an unreliable site. So, the obvious solution is to simply download Filezilla from source forge and not some random file host site.

That's not the only place you'll find these dll's (1)

hyades1 (1149581) | about 9 months ago | (#46089897)

I found both of them in TOR browser software and the pro edition of Easeus Partition Master 9.1.1 (legally obtained, not pirated).

So is there something inherently wrong with dll's bearing that name, or are they OK except when they crop up in Filezilla?

Re:That's not the only place you'll find these dll (2)

ledow (319597) | about 9 months ago | (#46089947)

They are DLL's used by many programs which are compiled with a certain compiler. It's like saying a program comes bundled with msvcrtXX.dll.

The fact that you're even bothering about the names is much more important. What the hell makes you think that the filename is an indicator of its contents? That DLL could be named the same as a harmless file but contain the virus routines. The name is neither here nor there.

The interesting question is "what's the hash?" - is it an official copy of those files, which is innocent but required by the program because of the compiler used? Or is it just something malicious renamed to look like a common harmless file?

Filenames mean nothing. Service names mean nothing. Process names mean nothing. Registry entry names mean nothing. They can all be changed in seconds and have no correspondence to the CONTENT of those files (hell, you can load a DLL that's called fred.jpg, if you really want).

Please (4, Insightful)

ledow (319597) | about 9 months ago | (#46089913)

Stop all this filesize / filename nonsense.

Either publish signed hashes of the good version or don't bother at all. If it takes more than a minute to change the filesize / filenames to something arbitrary of your choice as a malware author, I'll be amazed, especially when you could easily make it be the same size as the official one in this case by just padding with zeroes.

Please stop using these things are identifiers for malware. Same for "check for this registry entry". Any idiot with a copy of the virus can modify the strings in it to use a different reg entry / server / filename / filesize but what they CAN'T do easily is make a file with the same hash as something official.

And given that I couldn't even see a GPG key or hash value on the download page of FileZilla at all, pretty much this kind of thing is to be expected.

Re:Please (0)

Anonymous Coward | about 9 months ago | (#46089985)

FileZilla is a Windows program. The people using it, by definition, are not security-literate.

Re:Please (1)

Shalaska (1964046) | about 9 months ago | (#46090141)

Exactly, the hashes are the best way to tell the two apart and anyone downloading software from the internet should learn how to check them.

For reference you can find FileZilla's hashes at:

http://sourceforge.net/project... [sourceforge.net]

Or to get their yourself go to Download, then click on "Show additional download options" and it will be the last one in the list.

Source Forge is responsible for this (1, Informative)

Khyber (864651) | about 9 months ago | (#46090113)

https://forum.filezilla-projec... [filezilla-project.org]
https://forum.filezilla-projec... [filezilla-project.org]
https://forum.filezilla-projec... [filezilla-project.org]

Anyone using Source Forge should walk the fuck away right now and never go back. They are the ones responsible for this.

Sourceforge download ads (1)

Martin S. (98249) | about 9 months ago | (#46090119)

This one example why Open Source sites need to take the threat of Advertsm mimicking download buttons on their sites.

Instead they are still glossing over the risks.

http://sourceforge.net/blog/ha... [sourceforge.net]

Re:Sourceforge download ads (3, Informative)

Shalaska (1964046) | about 9 months ago | (#46090169)

The number of times I have accidently clicked on an ad Download button instead of the actual download button on sites I am not familiar with is astounding. I always have caught on quickly, stopped the incorrect download and then gone looking for the correct one, but as a Comp Sci PhD candidate and computer security practitioner, the fact that it can fool me even for a minute is astounding. Sites really should remove ads that confuse where you should be clicking to download what you came there for.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?