Gmail will stop allowing JavaScript (.js) file attachments starting February 13, 2017

Pierluigi Paganini January 26, 2017

Google announced Gmail will soon stop allowing users to attach JavaScript (.js) files to emails for obvious security reason.

Google announced Gmail will soon stop allowing users to attach JavaScript (.js) files to emails for obvious security reason. JavaScripts files, like many other file types (i,e, .exe, .jar, .sys, .scr, .bat, .com, .vbs and .cmd) could represent an insidious threat for the recipient, for this reason starting with February 13, 2017, .js files will no more be allowed.

“Gmail currently restricts certain file attachments (e.g. .exe, .msc, and .bat) for security reasons, and starting on February 13, 2017, we will not allow .js file attachments as well. Similar to other restricted file attachments, you will not be able to attach a .js file and an in-product warning will appear, explaining the reason why.” states Google.

It will be not possible to attach such kind of files, if users will try to attach a .js file the Google will display a warning message while blocking the potentially dangerous file.

Google suggests users share such kind of potentially harmful files through Google Drive, Cloud Storage or similar online storage services.

“If you still need to send .js files for legitimate reasons, you can use Google Drive, Google Cloud Storage, or other storage solutions to share or send your files.”

JavaScript Google

JavaScript files have been exploited in several malicious campaigns recently, crooks leveraged on this kind of file to spread download and install various malware such as the dreaded Locky Locky were embedding the Locky binary in JavaScript files attached to spam emails.

The analysis of the JavaScript revealed the existence of numerous variables that contain chunks of strings that are concatenated at runtime to compose the malicious code.ealed

“Loading the JavaScript into an editor shows the same familiar obfuscation found in the previous Locky downloader script variants.” continues the analysis.

“It also shows the use of numerous variables containing chunks of strings, which are concatenated at runtime to build needed strings like ActiveXObject names and methods.”

The encrypted Locky ransomware binary was stored in a set of large arrays, at runtime it was decrypted and saved to disk. When the ransomware binary is decrypted it is possible to notice a significant surge in CPU usage from wscript.exe.

In previous campaigns, the experts only noticed the use of scripts as a container for the downloader, instead of the malicious code itself.downloader, instead of the malicious code itself.downloader, instead of the malicious code itself.downloader, instead of the malicious code itself.

Recently security experts spotted a new ransomware, Ransom32, that is the first ransomware variant that has been developed in the JavaScript scripting language.

Do you need another proof to consider JavaScript attachments potentially dangerous?

[adrotate banner=”9″]adrotate banner=”9″]

Pierluigi Paganini

(Security Affairs – JavaScript File Attachments, hacking)



you might also like

leave a comment