Those Pesky Hiding Viruses


  • ♿ (Parody)

    So I had a bit of an issue sending a ZIP file containing a few harmless font files (ttf, afm, pfb, pfm, etc). The response from my email provider:

    Mr. Papadimoulis ,

    Thank you for your recent call to Client Support Services.  We have looked into the issue that you are having with sending a file attachment.  It appears that the problem may be with the fact that it is a zipped file.  Compressed files can hide virus much better than uncompressed files.  This could explain why the system is blocking the attachment.  Try unzipping the files and send them individually.  Also, FTP is another potential option.   If you have any questions about this action, please feel free to call Client Support Services , and please reference the ticket number when calling.

    Thank you,

    R------ L-----
    Client Support Services

    Fun additional fact: while their email scanner recursively scans Zipped Zip files, it will crash when a Zip file contains a password-protected Zip file.



  • send as rar, 7zip or tar.gz/bz?

    We have a customer of ours whom have the same kind of system, it won't accept zip or rar files, but doesn't care about tar.gz.  



  • Or just send your zips as ".notazip" because the inspection software only goes by extension.



  • While I do realize that MIME types are not to be trusted, wouldn't the system at least take it into consideration?

    If it finds a unknown/unscannable extension, it should check the MIME type and then do some simple heuristics to ensure that the MIME type was set correctly. Then, it could simply ignore the .notazip extension and do a zip scan on the file.

    At least that's how I'd do it..



  • This is why recursively scanning zipped zip files is a bad idea.



  • @dasluq said:

    This is why recursively scanning zipped zip files is a bad idea.

    The result is that now, most email virus scanners reject all large zip files, claiming that they are variants of 42.zip. Life in the world of code-blacklist security is very, very stupid. The whole concept sucks.



  • @archivator said:

    While I do realize that MIME types are not to be trusted, wouldn't the system at least take it into consideration?

    If it finds a unknown/unscannable extension, it should check the MIME type and then do some simple heuristics to ensure that the MIME type was set correctly. Then, it could simply ignore the .notazip extension and do a zip scan on the file.

    At least that's how I'd do it..

    Some do this. Most are just too crap to care. 



  • I rename .ZIP to .XIP on the basis the .XIP is a registered file extension for WinZIP on Windows (& other platforms don't give a hoot what the file extension is anyway). Blocking .ZIP files is very irritating though. SourceForge have been doing it for years now, and it still occasionally trips me up when I forget to rename something before I send it.



  • @Alex Papadimoulis said:

    Fun additional fact: while their email scanner recursively scans Zipped Zip files, it will crash when a Zip file contains a password-protected Zip file.

     

    Awesome!!!!

    So let me get this straight... you cannot send .zip files BUT you can send the executable files which are potentially more harmful? Cool!

    Also their virus scanner can SCAN the files, BUT it cannot determine that there are no viruses?

    BEST ISP EVER!

     

    So what is the domain? I want to try sending a few encrypted empty zip files. 



  • @archivator said:

    While I do realize that MIME types are not to be trusted, wouldn't the system at least take it into consideration?

    If it finds a unknown/unscannable extension, it should check the MIME type and then do some simple heuristics to ensure that the MIME type was set correctly. Then, it could simply ignore the .notazip extension and do a zip scan on the file.

    At least that's how I'd do it..

    I think scanning extensions is fine. ZIP files are not hard to detect (first 4 bytes are 50 4B 03 04, a.k.a. "PK\003\004"), so if they were going to do it they would. Fortunately for Windows users, though, an emailed file depends entirely on the extension for it to be opened with the right application. So the trojan sent to Johnny Luser with an extension of ".NOTAVIRUS" to bypass these sorts of filters is harmless, because he'd have NO CLUE what to do with it. If he did actually rename it to an extension that Windows would know how to open, then good for him... he's a moron.

    Actually, now that I think about it, there is a problem. Johnny Luser will eventually learn to trust instructions to rename files because his coworkers and friends are sending them ALL THE TIME thanks to these moronic email filters. Now a trojan can send a file with an unknown extension along with (the now commonplace) instructions on how to rename and use the file, and blammo, a new kind of trojan is born.

    I find it humorous that with the march of time trojans have not really become any more sophisticated. They just rely on the victims themselves to do more to bypass security, and the victims willingly comply...



  • @djork said:

    Actually, now that I think about it, there is a problem. Johnny Luser will eventually learn to trust instructions to rename files because his coworkers and friends are sending them ALL THE TIME thanks to these moronic email filters. Now a trojan can send a file with an unknown extension along with (the now commonplace) instructions on how to rename and use the file, and blammo, a new kind of trojan is born.

    I find it humorous that with the march of time trojans have not really become any more sophisticated. They just rely on the victims themselves to do more to bypass security, and the victims willingly comply...

    Trojans of this form first appeared over five years ago, and are now prevalent on the internet. What rock have you been hiding under? 



  • @asuffield said:

    @djork said:

    Actually, now that I think about it, there is a problem. Johnny Luser will eventually learn to trust instructions to rename files because his coworkers and friends are sending them ALL THE TIME thanks to these moronic email filters. Now a trojan can send a file with an unknown extension along with (the now commonplace) instructions on how to rename and use the file, and blammo, a new kind of trojan is born.

    I find it humorous that with the march of time trojans have not really become any more sophisticated. They just rely on the victims themselves to do more to bypass security, and the victims willingly comply...

    Trojans of this form first appeared over five years ago, and are now prevalent on the internet. What rock have you been hiding under? 

    I have to say I've never seen one like this. I don't really see much spam or malicious mail, though. I'm not sure what I'm doing wrong :)



  • @dasluq said:

    This is why recursively scanning zipped zip files is a bad idea.

    Cool.  Do you know where I can get one of those in gzip format?



  • @Carnildo said:

    @dasluq said:
    This is why recursively scanning zipped zip files is a bad idea.

    Cool. Do you know where I can get one of those in gzip format?

    Just download the Zip version, unpack it and repack it using "tar xjvf" ...

    Well, you might want to buy a truckload of new harddisks first. 



  • In Linux/Unix:

    dd if=/dev/zero of=page0.dat bsize=4096 count=1048576
    gzip page0.dat
    cp page0.gz page1.gz
    cp page0.gz page2.gz
    ...
    tar -czf chapter0.tar.gz page*.gz
    cp chapter0.tar.gz chapter1.tar.gz
    cp chapter0.tar.gz chapter2.tar.gz
    ...
    tar -czf book0.tar.gz chapter*.tar.gz
    cp book0.tar.gz book1.tar.gz
    ......

    And so on.  The dd line writes 4 GB of nulls into page0.dat, then gzip zips it to a few K because you might not have 128 GB to throw at these temps. Then copy it over and over, zip those up and copy the archive over and over, zip those ones up and so forth.

    Or dd from /dev/random to watch your 4 GB of random data gzip to about 3.9 GB.



  • @joemck said:

    dd if=/dev/zero of=page0.dat bsize=4096 count=1048576

    Even better is

    dd if=/dev/zero of=page0.dat bs=4096 seek=1048576 count=0

    if your filesystem supports sparse files, because it doesn't allocate any disk space (other than the inode and directory entry).   (GNU dd didn't recognise bsize so I used bs instead.)



  • (double post, grr)



  • Or dd from /dev/random to watch your 4 GB of random data gzip to about 3.9 GB.

    That would defeat the shock & awe purpose of having a simulation of the inflationary cosmology model. :)


Log in to reply