Computer crooks and spammers are abusing a little-known encoding method that makes it easy to disguise malicious executable files (.exe) as relatively harmless documents, such as text or Microsoft Word files.
The “right to left override” (RLO) character is a special character within unicode, an encoding system that allows computers to exchange information regardless of the language used. Unicode covers all the characters for all writing systems of the world, modern and ancient. It also includes technical symbols, punctuations, and many other characters used in writing text. For example, a blank space between two letters, numbers or symbols is expressed in unicode as “U+0020”.
The RLO character (U+202e in unicode) is designed to support languages that are written right to left, such as Arabic and Hebrew. The problem is that this override character also can be used to make a malicious file look innocuous.
This threat is not new, and has been known for some time. But an increasing number of email based attacks are taking advantage of the RLO character to trick users who have been trained to be wary of clicking on random .exe files, according to Internet security firm Commtouch.
Take the following file, for example, which is encoded with the RLO character:
Looks like a Microsoft Word document, right? This was the lure used in a recent attack that downloaded Bredolab malware. The malicious file, CORP_INVOICE_08.14.2011_Pr.phyldoc.exe, was made to display as CORP_INVOICE_08.14.2011_Pr.phylexe.doc by placing the unicode command for right to left override just before the “d” in “doc”.
I wanted to see this work on my Windows 7 system, but found that I had to enable a registry tweak to allow the insertion of unicode into file names. After a reboot, I was able to rename any executable by holding the ALT key, then pressing the “+” sign on the keypad and typing “202e” in front of the targeted area while renaming a file.
According to Commtouch, this technique is being used to conceal malicious files in an unusually aggressive series of spam blasts that have been ongoing since mid-August.
“The average outbreak during 2010 occurred every 10-14 days and consisted of 5-10 billion messages sent by botnets,” Commtouch co-founder Amir Lev said. “The outbreak distribution kept enough bots alive to manage [a] certain level of malicious activity.”
In contrast, Lev said, recent malware spam outbreaks have been far more frequent – sometimes three per day. The malware variants embedded in the spam include many password-stealing bots used in high-profile cyber heists, such as SpyEye and Zbot/ZeuS, in addition to Sasfis and fake antivirus. The lures used include UPS package notifications, credit card errors, inter-company invoices, and supposed notifications from NACHA, a not-for-profit group that develops operating rules for organizations that handle electronic payments, from payroll direct deposits to online bill pay services.
Some email applications and services that block executable files from being included in messages also block .exe programs that are obfuscated with this technique, albeit occasionally with interesting results. I copied the program that powers the Windows command prompt (cmd.exe) and successfully renamed it so that it appears as “evilexe.doc” in Windows. When I tried to attach the file to an outgoing Gmail message, Google sent me the usual warning that it doesn’t allow executable files, but the warning message itself was backwards:
Unfortunately, many mail applications don’t or can’t reliably scan archived and zipped documents, and according to Commtouch and others, the malicious files manipulated in this way are indeed being spammed out within zip archives.
This class of attack is a good reminder that there is no substitution for being careful with unbidden documents and attachments sent to you via email. If you receive a message with an attachment you weren’t expecting — even if it appears to come from someone you know — the safest option is to take a second and reply back to the person to verify the contents of the message and that they meant to send it.
I have not had an opportunity to test this on other operating systems or email clients (although my Mac happily displayed the cmd.exe file as evilexe.doc). I’d be interested in comments from readers who have broader experience with this approach in manipulating file types.
Interesting article again. We’ve seen quite a few targeted emails using this recently. These were proper social engineering, like knowing the boss of the target + project they work on. Also fluent English. Another trick is to compile the EXE with a PDF icon, then make the filename very long. So mydogdyfile.pdf…………………………….exe. This seems dumb but when you view it in Windows it can look very convincing. There seems to be a lack of exploits around at the moment so attackers are moving to social engineering tricks like these to infect their targets.
I think email service providers drop files with two extensions (I know Gmail does this). Also some email service providers would recognise this as an application/executable file and drop it.
I couldn’t get the files to display ‘correctly’ (i.e. using right-to-left override) in KDE/Linux. Though I’m not sure if that’s because the files didn’t use unicode correctly (it was more than a month ago during the same campaign, perhaps things weren’t working back then; a colleague couldn’t get it to work in XP either) or because I needed some extra libraries. Tried to install some but without any luck. My KDE menu is still half in Arabic as a reminded of the effort. 🙂
Martijn – I found the following links very useful in helping me figure out how to do this.
Thanks, Bryan. Had a quick look at these and they don’t seem to show how to enable support for viewing ltr-override on Linux. Tried a few other things with a sample from today but still failed.
This is example #49285 of how respecting internet standards keeps you safe.
Do away with HTML email (which also helps spammers track you, btw) and keep to inline messages which are required to be in ascii. No unicode. No problem.
As for Windows, there’s always the age-old old trick of naming your file photo.jpg.exe. Windows hides the extension and the person sees only “photo.jpg” and opens it.
Windows will always have these kinds of problems that don’t exist in more mature operating systems.
This has nothing to do with HTML or non-HTML email. The unicode is in a filename. That file is indide a zip which is attached to the email. In fact the currently ongoing campaign (ACH and wire transfers – they change every 24 hours or so) doesn’t use HTML, just plain text with a .zip attachment.
I doubt the attack will be more successful than the .jpg.exe example you described (or variants thereof), but it’s certainly more clever.
Without input from those who have tested it, how can you make a statement about the exploit applying only to “immature operating systems” ?
Oh, and out of curiosity, about how old does an OS have to be to be a “mature” operating system? Should we stop using “immature” operating systems, get rid of smartphones….Maybe go back to mainframes…now THOSE are mature operating systems!
Nice article Brian. I always look forward to your articles.
This is example #49285 on how the english speaking world completely forgets there’s a whole lot of other languages out there, that simply can’t use ASCII text as the U.S. standards mandate.
Unicode support is necessary if you want the rest of the world to use your software. Bug like these are to be expected, but also unavoidable. The best we can do is research new ways to abuse Unicode and publish the results, watch what the malware authors are doing, and patch everything. It’s no different than any other kind of bug.
Unless you also want to go back to modems and BBS systems, because the world was so much safer back then 🙂
“Windows will always have these kinds of problems that don’t exist in more mature operating systems.”
Whilst I’m certainly no expert your analysis of Windows security issues vs. other operating systems seems highly flawed to me.
Since the vast majority of corporate and home desktop users are running Windows it would seem to make sense that Windows would be targetted over any other OS by a large factor.
It’s hardly surprising that a given OS don’t have as much of a problem if only a small number of criminals are targetting it and a criminal infrastructure hasn’t developed as much around the targetting of the OS is it.
Since I work on a web app that has to display and export (theoretically) text from any code page (but, usually, just English and Arabic), and often mixed, I’ve been playing a lot with \u200E and \uFEFF.
If you’re ever exporting mixed arabic/english text to Excel, make sure the first bytes are \uFEFF.
I found this being frequently used in the wild over a year ago and reported it to Microsoft. I suggested adjusting it so that the extension could not be affected by the RLO character. They said it was working as intended.
It was mentioned by my boss during a unicode speech she gave at DC3 and I’ve brought it up at US-CERT workshops since to help get the information out there. I’m glad to see it getting more exposure.
Also, the character can be added in Windows 7 through the right click menu when renaming a file.
Brian, did you do a responsible disclosure to Google about the apparent unicode RLO issue with the Gmail attachment notice?
It may not be a blatant security flaw, but it could well be indicative of some unicode parsing problems with Gmail.
If you haven’t reported it, I think you should.
“Responsible disclosure” is a bit of a loaded term. I have no idea whether this is a security flaw (I suspect not). The same thing happened when I tried to place a space between the reverse sentence and the rest of the blog text, when editing it in the HTML version in WordPress: It jumbled the rest of the post.
Whether it was responsible or not, this particular….oddity has been disclosed. I sent a note to Google “notifying” them about this. After I pasted the text of the above jumbled Gmail warning message into Gmail, the rest of my text was backwards. 🙂
I guess I take issue with the question of whether I did a responsible disclosure on this, which would seem to suggest that I needed to ask Google’s permission before mentioning this in my blog.
I agree. There was probably no need to delay disclosing the Gmail ROL behavior.
Glad that the issue has been properly reported them.
see this here
People have complained for years about Word:Mac’s lack of RTL language support. I guess Microsoft was just trying to keep its Mac customers safe. Who knew? שנה טובה ומתוקה