2

I share Dropbox directories with about 20 individuals. Most of them has malware on their PC's. How do I protect myself? I have noticed there is a worm (Brontok.bs) that replicates itself to all the Dropbox folders and then somehow writes itself to my win32 directory.

Dropbox policy of syncing was shocking for me:

Dropbox will sync any files added to it, so if someone syncs a virus or malware file, it will be synced to any computers linked to the account. Other users' accounts and computers may also be affected if the virus or malware is in a shared folder.

0x90
  • 1,402
  • 2
  • 19
  • 27
  • 2
    It shouldn't be able to write itself to your win32 directory, unless you execute it. – CodesInChaos Nov 21 '16 at 08:52
  • Brontok does not copies itself to your win32 directory, it creates a file with the _Folder_ icon and you very probably opened it. – ThoriumBR Nov 21 '16 at 14:11
  • @ThoriumBR I didn't, but I think Dropbox service did. Do you reference about its proliferation? – 0x90 Nov 21 '16 at 14:15
  • You probably did withou noticing. Dropbox service does not runs anything on its own. The reference is the first link on the page you posted: https://www.microsoft.com/security/portal/threat/Encyclopedia/Entry.aspx?Name=Win32/Brontok. The interesting reference is here: "In most cases, Win32/Brontock use the Windows 'new folder' icon for the worm files... can cause the file to appear as if it were a new folder rather than an executable file. An unsuspecting user clicking on the "folder" to view its contents thereby inadvertently runs the worm file." – ThoriumBR Nov 21 '16 at 16:29
  • @ThoriumBR I am doubt this technics still applies for win10 – 0x90 Nov 21 '16 at 16:32

3 Answers3

3

As CodesInChaos notes, it will not be able to write outside of the Dropbox folder unless you execute it. Of course, if there were any directory traversal vulnerabilities in the client then this wouldn't hold true, but of the time of writing none have been discovered.

If you're concerned about running malicious files on a certain machine, then it would be better not to run the Dropbox client at all and simply use the web application to browse your Dropbox and shared folders. That way, Dropbox will not be able to write to your file system. It could be conceivable that an attacker who has the ability to execute files on a system, but not write them, could use Dropbox in order to get the files they need there. However, if this is the case then you're already partially compromised.

Using the web app as a browser will allow you to choose which files to write, although you still need to be careful you don't download and execute anything malicious. Using a virus scanner or end-point protection tools such as Cylance, Webroot or SentinelOne can help.

In case of others running malicious code that infects the shared folders, Dropbox includes a feature where 30 days' worth of changes are backed up, which you could use in order to restore all files to their pre-infected state. You may need to contact them though if there are a large number you wish to restore.

SilverlightFox
  • 33,408
  • 6
  • 67
  • 178
2

You can use a virtual machine (like VirtualBox) to access the files of your dropbox folder. I would recommend a Linux one to reduce the risks of the VM to become infected, but it doesn't matter much. The point is to make sure to never access your dropbox files from outside the VM. You can insert files into your VM, but never transfer files to your host or access them from your host. So don't use a shared folder between your host and the VM. All your work related to the compromised files will need to be done in the VM to avoid contaminating the host. Also, make sure that your VM cannot communicate with your local network: do not give it LAN access.

However, to be sure that your host is not infected, the first step is to wipe it clean and reinstall it, and making sure your network devices are not infected.

Also, note that this solution is not 100% secure, as some malware can escape the VM containment, even though it's unlikely.

A. Hersean
  • 10,046
  • 3
  • 28
  • 42
1

There is little you can simply do. Once you share a dropbox folder with someone, you allow him to write any file there, and if you synchronize a local folder with the dropbox to also write locally in the synchronized folder.

The real solution would be to educate your co-workers so that they use good security practices in order to not to write worms or malware in the dropbox. Depending on which you share your dropbox with, this can be or not reachable. It it is not, or if the risk is still to high, you will have to use worarounds to limit the effects of the unavoidable malwares.

  • Be sure to have a strong anti-virus solution to protect your own machine. At least that should not allow synchronization of the majority of infected files
  • Use a VM as a sas. Either use a Linux or BSD machine that will be immune to most malwares, or take snapshots of the machine before syncing and restore the clean snapshot if something goes wrong. Then only copy files for which you can be sure that they are not infected with malware - clamav can help here to test files in that kind of DMZ - beware if a malware is not detected here and if you copy it on your main disk, you will be infected so it is far from a rock solid solution
  • if possible, use only file formats that cannot carry malwares: simple text files are a good example of that - unfortunately this format is hmm... feature poor, but I do not know attacks on pdf files either - provided script execution if disabled (thanks to @Clockwork-Muse for the comment), more refs here
  • if you have to use office documents (Libre-, Open- or Microsoft-), be sure to disable all macro execution

But as I already said, the problem is the problem of the group, and all members that share the dropbox folder should apply security practices to remove the malwares before copying a file to the dropbox and not after. Then doing controls before syncing would be rather paranoid, but as paranoia is a good rule in security, my advice would be to still do...

Community
  • 1
Serge Ballesta
  • 25,636
  • 4
  • 42
  • 84
  • One nice thing anout the Office Open XML format (like .docx) is that files having their extension ending in x can't have macros (like xlsx, docx), only the m (likely m for macro, but I like to call it m for malware) variant can (like xlsm, docm). So if you make sure to open only .docx, but no .doc and .docm files, you should be safe from macro attacks. Be ware that even docx files may contain exploits for non-macro-relatex security flaws in MS Office or LibreOffice, though. – Michael Karcher Nov 19 '16 at 22:27
  • 3
    There's no such thing as a file format that **can't** carry malware. In most cases, it's the reading programs that have one or more flaws that attackers exploit, not that the files themselves are executable. Text files are difficult to do this with because of the simplicity of the data, but not all bytes are valid characters... and that assumes it handles all valid input flawlessly! And yes, PDFs are exploitable (commonly done, in fact, since the format is so prevalent). – Clockwork-Muse Nov 21 '16 at 08:48
  • @Clockwork-Muse: I really cannot imagine a malware inside a text file... I do know that you can encode any file in a text file via uuencode or base64 and then decode back the original file. But vim can correctly read any byte sequence, and even notepad will certainly have a poor display but won't choke (except for really big sizes). For the PDF part I admit I forgot the script part because I **never** allow scripts in a Page Description Format and treat as malware any pdf file containing one: immediate plonk! But I've edited my post to warn about that. – Serge Ballesta Nov 21 '16 at 13:45
  • 1
    @SergeBallesta: You completely failed to understand what Clockwork said. Even if `vim` can correctly read any byte sequence (which is far from proven) it's possible some other editor, perhaps MS Word, would suffer a buffer overflow in its UTF-8 decoder when presented with certain illegal encodings. Exploits in pure data files definitely tend to be more prevalent in compressed formats, however, since poor validation can easily lead to some implementation of the decompressor writing outside of the memory created as an output buffer. And it won't work on programs using other implementations. – Ben Voigt Nov 21 '16 at 16:02
  • To piggyback on what Ben said, exploits for PDFs don't necessarily rely on scripts. There were multiple exploits relating to how compressed document images were handled (ie, like from a scanner), which I don't believe required JavaScript. For that matter, there were multiple vulnerabilities in Windows (and possibly other OSes) relating to handling of jpgs (and other formats), which of course are not going to contain any JS. – Clockwork-Muse Nov 21 '16 at 19:07