• (cs) in reply to The real WTF here...
    The real WTF here...:
    The problem this is trying to work around are mail readers which automatically unzip .zip files when you receive them, without telling you what they're doing. ...

    There is another behavior that is not quite as automatic, but is even more dangerous. Novell GroupWise came up with the really bright idea of default opening by single click. As I recall, they had no standard option to change this behavior. That meant that by the time one of my users had highlighted an attachments icon, say to see the full filename, the file was open. This certainly created difficulty in recommending procedures for handling attachments, that were in doubt. I guess Novell gave themselves convenience points for saving the user the effort of a double-click, but confirmed my feeeling that Novell should die and go away.

  • (cs) in reply to some mailer
    some mailer:
    I used to do so, but now my clients have so many different security configs and stuffs, that i just save the file on my web server and send them a link so they can download it the fucking way they want.

    then a cron moves things into backup after a while or a few downloads.

    Insane.

    Use yousendit.com or any of the plethora of similar services out there. Al Queda does.

  • (cs)

    This is what the content checker of my company sais:

    BANNED FILENAME ALERT

    Our content checker found banned name: foo.reg in email presumably from you (<@.>), to the following recipient: -> @.

    Delivery of the email was stopped!

    The message has been blocked because it contains a component (as a MIME part or nested within) with declared name or MIME type or contents type violating our access policy.

    With a little effort it is still possible to send ANY contents (including viruses) using one of the following methods:

    • encrypted using pgp, gpg or other encryption methods;

    • wrapped in a password-protected or scrambled container or archive (e.g.: zip -e, arj -g, arc g, rar -p, or other methods)

    Note that if the contents is not intended to be secret, the encryption key or password may be included in the same message for recipient's convenience.

    We are sorry for inconvenience if the contents was not malicious.

    The purpose of these restrictions is to cut the most common propagation methods used by viruses and other malware. These often exploit automatic mechanisms and security holes in certain mail readers (Microsoft mail readers and browsers are a common and easy target). By requiring an explicit and decisive action from the recipient to decode mail, the dangers of automatic malware propagation is largely reduced.

  • Jens (unregistered) in reply to texdex
    texdex:
    Our system at my last job did something like this. It still delivers the email, but strips it of attachments with certain extensions. I remember getting a support request from somebody who desperately needed us to recover the stripped attachment. We told him there was no way to, because the stripped files are dropped on the floor, and not saved anywhere. We recommended that he ask the sender to re-send the file. His reply was something to the effect of:

    "I am the sender, and no I cannot resend it because it has been erased. I sent it to my own email address to get it off of my old computer before I formatted the hard disk."

    Ouch.

    Yeah I do that all the time as backup... It does tend to tie up the network though.. could that be because I'm sending 20 GB data every day?

    (Americans, please note.. this is not true, I am only kidding.. You should not beleive it)

  • aeternus (unregistered)

    I hate attachment blocking, if someone is stupid enough to open viruses, why should they be not allowed to? It's natural selection.

    Anyway, at my university, they had a really bright idea. The mail system blocks the email, but only informs the RECIPIENT about that. This is an example :

    BANNED CONTENTS ALERT

    Our content checker found banned names: loadSetup/setup.exe, ...

    in an email to you from: [email protected]

    According to the 'Received:' trace, the message originated at: [xxx.xxx.xxx.xxx]

    Our internal reference code for this message is 09949-01. The message has been quarantined as: banned/20070413/002021-09949-01

    Please contact your system administrator for details.

    Needless to say, the message was urgent and important, from the manager at the company where I was going to do my project. And university helpdesk didn't even respond to my requests. So my way of making good first impression was asking the sender to do tricks with attachments, brilliant.

    Another stupidity in blocking email attachments is the cheerful assumption that the sender speaks English. This way my grandma, AFAIK not being an automated mailbomber, will be classified as such. Brilliant^2

    Why isn't there a per-mailbox setting that I don't want ANY attachments blocked?

  • (cs) in reply to Infinity
    Infinity:
    This is what the content checker of my company sais:
    BANNED FILENAME ALERT

    Our content checker found banned name: foo.reg in email presumably from you (<@.>), to the following recipient: -> @.

    Delivery of the email was stopped!

    The message has been blocked because it contains a component (as a MIME part or nested within) with declared name or MIME type or contents type violating our access policy.

    ... BLAHBLAHBLAH

    Wow... I'd call this verbose discouragement of attachment usage to the average user...

  • TheRealFoo (unregistered) in reply to steve

    you mean, like "gzip"? Oh wait, there's bzip ... no, sorry, I forgot: bzip2 has been out since 1996.

    Yep, I think they could.

  • (cs) in reply to Random832
    Random832:
    There is no such call in windows. Windows does the "right thing" based on the file extension, not the contents.

    This is true now (XP/2003/Vista), to a certain extent. It didn't used to be true at all (Win95/98).

    I just did a test on my XP SP2 box. I renamed an executable from .exe to .exo and then, at a command prompt, typed the filename (ftpserve.exo) and hit enter. Windows prompted me saying that certain functionality was being blocked, but the app started. The certain functionality was access to the internet (the app is an ftp server used internally).

    Under earlier versions of Windows, the app would simply have run. I know this for a fact, because I once renamed Solitaire on every machine in a Customer Service Department and wrote a dummy wrapper app that asked for a password; if you supplied the proper password, it then launched Solitaire using the new name. I then gave the password to all but one of the users in Customer Service; the one user didn't get it because they were supposedly on my bad side (a joke).

  • (cs) in reply to bkendig
    bkendig:
    The real WTF here is that the mail server accepted the incoming email, and only THEN did it say "omigosh, there's a non-allowed extension on the attachment!" and then it had to send mail BACK to the original sender to let him know. You'd think that something like this would be fairly easy to spot while the delivery connection is still open, before a status message is sent back - why did the mail server respond to the client with an SMTP OK before bothering to check whether the message was really OK?

    Accept-then-bounce is the scourge of the Internet. Its only useful purpose is to help spammers reach twice as many targets with no additional effort.

    Not here. Excite's server rejected it straight away as you recommend, and the rejection message came from Yahoo (the sender's mail server). Hard to see how you could do better, without Yahoo's server being psychic. (or doing the relay synchronously, which would be very much against how the internet was designed to work)
  • (cs) in reply to KenW
    KenW:
    Random832:
    There is no such call in windows. Windows does the "right thing" based on the file extension, not the contents.

    This is true now (XP/2003/Vista), to a certain extent. It didn't used to be true at all (Win95/98).

    I just did a test on my XP SP2 box. I renamed an executable from .exe to .exo and then, at a command prompt, typed the filename (ftpserve.exo) and hit enter. Windows prompted me saying that certain functionality was being blocked, but the app started. The certain functionality was access to the internet (the app is an ftp server used internally).

    Under earlier versions of Windows, the app would simply have run. I know this for a fact, because I once renamed Solitaire on every machine in a Customer Service Department and wrote a dummy wrapper app that asked for a password; if you supplied the proper password, it then launched Solitaire using the new name. I then gave the password to all but one of the users in Customer Service; the one user didn't get it because they were supposedly on my bad side (a joke).

    You typed it where? If you typed it into a cmd window, maybe that's a feature of the command interpreter (since you can't type in anything directly that's not to be interpreted as a command - typing "foo.zip" on an actual zip file will just result in an error message) rather than the operating system. Though clearly a "Take anything no matter what it is and assume it's an executable" call must exist in the OS, and it may not be less WTFy in general than "Take anything and run it if the contents are executable else pass to handler app" as you assumed it was doing, it is at least less likely to be used by mail clients with the intent that the file gets passed to winzip (or whatever for other file types), since that won't happen even for real zip files

  • Anonymous (unregistered) in reply to DaveK
    DaveK:
    Random832:
    A few clients would go so far as to unzip the file by simply passing it to a call in Windows which would read the first few bytes and automatically "do the right thing." --- Windows which would go "oh, wait--this really is an .exe; I'll run it rather than pass it to WinZip"
    There is no such call in windows. Windows does the "right thing" based on the file extension, not the contents.

    Unfortunately, you're both wrong. The actual truth is that sometimes windows goes by the file extension, and sometimes it sniffs the start of the file to try and deduce the type, and sometimes it goes by the extension of the file but then the viewer it launches sniffs the start of the file, and it varies depending whether you launch something in explorer, or from internet explorer, and what internet explorer does varies according to the mime information and http headers, and .....

    .. in other words, it's an inconsistent and unpredictable mess. And that's dangerous.

    See http://seclists.org/bugtraq/2002/Feb/0327.html for an example. (There are more, but I happen to recall that one off the top of my head!)

    What may be happening in the referenced bugtraq link is that the ID3 tag in MP3 files is able to "contain just about any file you want to include" http://www.id3.org/ID3v2Easy, so the file is probably being opened as an mp3 based on its extension, and the mp3 player is delegating the tag metadata to other reader apps.

  • (cs)

    other options are;

    • embed the zip in a Word document and send it as a .doc
    • if that fails embed it in a Word document and send it as .rtf
  • Anonymous (unregistered) in reply to KenW
    KenW:
    Random832:
    There is no such call in windows. Windows does the "right thing" based on the file extension, not the contents.

    This is true now (XP/2003/Vista), to a certain extent. It didn't used to be true at all (Win95/98).

    I just did a test on my XP SP2 box. I renamed an executable from .exe to .exo and then, at a command prompt, typed the filename (ftpserve.exo) and hit enter. Windows prompted me saying that certain functionality was being blocked, but the app started. The certain functionality was access to the internet (the app is an ftp server used internally).

    Under earlier versions of Windows, the app would simply have run. I know this for a fact, because I once renamed Solitaire on every machine in a Customer Service Department and wrote a dummy wrapper app that asked for a password; if you supplied the proper password, it then launched Solitaire using the new name. I then gave the password to all but one of the users in Customer Service; the one user didn't get it because they were supposedly on my bad side (a joke).

    Tried opening an .exe renamed to .exo both in WinXP SP1 by clicking and using Run... and got a big "Windows cannot open this file" dialog.

  • cellocgw (unregistered)

    Speaking of WTFs, Just TRY to rename a zip archive under OSX 10.3 or 10.4 . Even with "show extenions" selected and all that, if you try to rename archive.zip to archive.foo , the Finder (or something in the OS) cheerfully helps you out by naming it archive.foo.zip . You have to use a Terminal session (bash to you OSX newbies :-) ) to make the change "stick"

  • Zygo (unregistered) in reply to aeternus
    aeternus:
    I hate attachment blocking, if someone is stupid enough to open viruses, why should they be not allowed to? It's natural selection.

    For the same reason why we generally like to keep the feces out of the streets.

    Sure, serious contagious diseases only affect people who are stupid enough to step in the sh*t, but when they get sick they take us all down with them--either by directly propagating the disease itself, or because they get too sick to do their day jobs running the utilities and supply systems that keep the rest of us alive and eating.

  • Random (unregistered) in reply to Zygo
    Zygo:
    aeternus:
    I hate attachment blocking, if someone is stupid enough to open viruses, why should they be not allowed to? It's natural selection.

    For the same reason why we generally like to keep the feces out of the streets.

    Sure, serious contagious diseases only affect people who are stupid enough to step in the sh*t, but when they get sick they take us all down with them--either by directly propagating the disease itself, or because they get too sick to do their day jobs running the utilities and supply systems that keep the rest of us alive and eating.

    "Group accountability" is the real WTF.

  • mh (unregistered)

    The real WTF is that this isn't really yahoo or excite, it's a standard default error message ("cuteness" and all) in their SMTP software.

    Captcha: "Welcome Home..."

  • (cs) in reply to mh

    No, recommending compression when the rejected file was a zip file is still a WTF.

  • (cs) in reply to Anonymous

    And none of this means that actual code (binary code, that you'd find an exe file) will be executed from a file with a .zip extension in any context other than typing the filename as a command at the command prompt [which doesn't let you specify files as anything other than a command at the beginning of the line]

  • Loren Pechtel (unregistered) in reply to Anonymous coward
    Anonymous coward:
    benk:
    Gmail works the same way with .exe files. It's just a simple protection against accidental execution.
    It won't let you send/receive .zips that contain .exe either... Really annoying

    Yup. Long ago I found that one out the hard way. Dial-up in the third world, I finally got the megabyte .zip file uploaded and it rejected it because there was an .exe inside. Fortunately Hotmail doesn't reject those. Web e-mail accounts were the only way to do it--the dial-up didn't come with a mailbox or even an account in the traditional sense--it was run by the phone company and you were simply billed usage on your phone bill. Like a 976- but reasonably priced.

    I do think that requiring executable stuff to be compressed is a good precaution, especially if you use something other than .zip. That means they must have a decompresser installed which sets them above the average user.

  • (cs) in reply to SuperousOxide
    SuperousOxide:
    MichaelWojcik:
    Even better is to generate a random-but-plausible password (selected from a dictionary, say) for each outgoing message, or batch of messages, to prevent email scanners from recognizing the same attachment in multiple emails.

    Wouldn't a real random password be more plausible than one chosen from a dictionary?

    That depends on the audience, but I think for the typical user who might fall for this bit of social engineering, no. The hook I proposed implies a relatively unsophisticated sender - someone who figured out that password-protected zip archives are a side channel, but not that using a side channel to bypass security mechanisms (or encouraging the recipient to do so) might be a bad idea. I wouldn't expect such a person to practice good password hygiene as a matter of habit.

    Also, remember that the password in this case is meant to be exposed - it's in the message in plaintext - so it needn't be difficult to guess. In fact, it makes more sense if it's something that's easy to read and type.

    But we could try it both ways with, say, a thousand random victims, and see which is more successful...

  • Rik (unregistered) in reply to db2

    The real WTF is that they're using qmail. Nobody in their right mind should use qmail on the internet today, with 99% of all email coming from forged senders.

  • NeverYouMind (unregistered) in reply to Critter
    Critter:
    steve:
    webrunner:
    As another layer of insanity: it suggests that you compress your file, but doesn't let through .zip files.

    Someone needs to come up with another way to compress files, maybe those GNU guys could figure something out.

    Erm... .tar.gz?

    or .7z (LZMA)?

  • NeverYouMind (unregistered)

    Hotmail did this for over 6 months, only it was for ANY file type. It denied all attachments as virus infected. (Though still advertising unlimited attachments).

    After a time I began to wonder maybe I really did have a virus in every single file on my computer (however improbable). So I tested from a few other computers - same result all attachments denied as virus infected.

    I then tried several LiveCDs (Knoppix, QNX 6.3) to boot a number of machines and attach plain text files generated after the LiveCD boots... same result - all attachments denied as virus infected.

    I gave up and switched to Lycos and never had a problem with them. I later switched to Gmail, but only after I was able to do so without an invitation. The underhanded social data mining of the invitations system under the guise of a "beta" offends me.

    For all I know Hotmail may still advertise unlimited attachments and then deny all attachments claiming viruses... great way to save on upstream bandwidth!

  • (cs) in reply to Anonymous
    Anonymous:
    DaveK:
    Random832:
    A few clients would go so far as to unzip the file by simply passing it to a call in Windows which would read the first few bytes and automatically "do the right thing." --- Windows which would go "oh, wait--this really is an .exe; I'll run it rather than pass it to WinZip"
    There is no such call in windows. Windows does the "right thing" based on the file extension, not the contents.

    Unfortunately, you're both wrong. The actual truth is that sometimes windows goes by the file extension, and sometimes it sniffs the start of the file to try and deduce the type, and sometimes it goes by the extension of the file but then the viewer it launches sniffs the start of the file, and it varies depending whether you launch something in explorer, or from internet explorer, and what internet explorer does varies according to the mime information and http headers, and .....

    .. in other words, it's an inconsistent and unpredictable mess. And that's dangerous.

    See http://seclists.org/bugtraq/2002/Feb/0327.html for an example. (There are more, but I happen to recall that one off the top of my head!)

    What may be happening in the referenced bugtraq link is that the ID3 tag in MP3 files is able to "contain just about any file you want to include" http://www.id3.org/ID3v2Easy, so the file is probably being opened as an mp3 based on its extension, and the mp3 player is delegating the tag metadata to other reader apps.

    What's even more likely is that it was merely a Windows Media Video. When the MP3 codec failed to read it, WMP would have analysed the file to determine what type of file it really was. Once it determined it was WMV, it would have read the WMF headers to determine the version abd launched the appropriate codec.

  • Dave (unregistered) in reply to Daniel15
    Daniel15:
    Of course, the *real* WTF is the fact that they're running qmail, rather than a modern MTA like Exim or Postfix. qmail is kinda dead at the moment, and is no longer updated (its last official release was in 1998, and its latest unofficial release [netqmail] was in 2004...)
    what makes you think qmail *needs* an update? it's probably still the most secure and efficient MTA out there, and the fact that in over 10 years no one has found a security hole in it despite Bernstein's prize offer speaks for itself.
  • N Morrison (unregistered) in reply to benk
    benk:
    Gmail works the same way with .exe files. It's just a simple protection against accidental execution.
    So I just rename them to ????.xex or ????.piz or similar.
  • (cs) in reply to bkendig

    Scanners often operate after the SMTP session is closed - especially in the qmail world. This is because qmail is a totally "modularized" system, with several different executables doing different tasks on a "queue" of messages. They're probably using qmail-scanner to call clamav and Spamassassin to scan messages, while blocking certain attachments.

    If you use magic-smtpd to replace qmail-smtpd you can implement invalid user rejection at the envelope level and never accept the message, and even drop message after a configurable number of "bad" recipients.

    If you want to be really nasty, configure fail2ban to watch the qmail logs for "too many invalid recipeints" messages and then bang the sending IP into an IPTABLES blacklist.

    I've done a few of these qmail servers...

  • lister (unregistered) in reply to MichaelWojcik
    MichaelWojcik:
    Kokuma:
    Maybe soon enough, our "neighbour gal" will send us a "sexy.abc" file esking us to rename it to "sexy.exe" and run it to see her on her brand new webcam !

    Combining filter-avoidance techniques with social engineering like this is a well-known attack. They were being discussed at some length on the SecurityFocus VULN-DEV mailing list at least as far back as 2000 (the earliest I seem to have archives for).

    Plus, the advice to compress the file first is that often, new (and not so new) mail servers/proxy filter the attachments by looking what's in them (how often I have seen reg, exe and zip files rejected even after changing the extension...). There are even some servers/proxy that decompress archives, but that's less frequent.

    Most of the email virus scanners I'm familiar with decompress archives. There are attacks specifically against decompressing scanners (eg artificially-constructed nested archives, to overflow recursive decompressors, and archives that expand by many orders of magnitude to overflow temporary storage), because they're a prominent target.

    What scanners generally cannot do is decompress encrypted archives, such as password-protected Zip files. (The Zip encryption scheme is relatively easy to break under the right conditions, but it's hard to automate that for the general case.)

    In a 22 May 2000 post to VULN-DEV I suggested distributing malware as password-protected Zip attachments, with the password in the body of the message, and suitable text like:

    S. Kiddy:
    Here's the document I mentioned in my other note. Our email system won't let me send Word files out as attachments, even in a regular zip, so I had to put a password on this. It's just "password".

    Even better is to generate a random-but-plausible password (selected from a dictionary, say) for each outgoing message, or batch of messages, to prevent email scanners from recognizing the same attachment in multiple emails.

    I think I first saw this approach used in the wild about five years later; the script kiddies take a while to adopt new techniques.

  • PANCHO PANCRASIO (unregistered) in reply to lister
    lister:
    MichaelWojcik:
    Kokuma:
    Maybe soon enough, our "neighbour gal" will send us a "sexy.abc" file esking us to rename it to "sexy.exe" and run it to see her on her brand new webcam !

    The proxy avoidance is filter in my work computer is there other way to get to webpages wich are filter?

    Combining filter-avoidance techniques with social engineering like this is a well-known attack. They were being discussed at some length on the SecurityFocus VULN-DEV mailing list at least as far back as 2000 (the earliest I seem to have archives for).

    Plus, the advice to compress the file first is that often, new (and not so new) mail servers/proxy filter the attachments by looking what's in them (how often I have seen reg, exe and zip files rejected even after changing the extension...). There are even some servers/proxy that decompress archives, but that's less frequent.

    Most of the email virus scanners I'm familiar with decompress archives. There are attacks specifically against decompressing scanners (eg artificially-constructed nested archives, to overflow recursive decompressors, and archives that expand by many orders of magnitude to overflow temporary storage), because they're a prominent target.

    What scanners generally cannot do is decompress encrypted archives, such as password-protected Zip files. (The Zip encryption scheme is relatively easy to break under the right conditions, but it's hard to automate that for the general case.)

    In a 22 May 2000 post to VULN-DEV I suggested distributing malware as password-protected Zip attachments, with the password in the body of the message, and suitable text like:

    S. Kiddy:
    Here's the document I mentioned in my other note. Our email system won't let me send Word files out as attachments, even in a regular zip, so I had to put a password on this. It's just "password".

    Even better is to generate a random-but-plausible password (selected from a dictionary, say) for each outgoing message, or batch of messages, to prevent email scanners from recognizing the same attachment in multiple emails.

    I think I first saw this approach used in the wild about five years later; the script kiddies take a while to adopt new techniques.

Leave a comment on “Please Bypass Security ”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article