Is JavaScript packer a security threat?

SecureWorks done a research called “Packer 2.0 threat” where hackers could use JavaScript packing mechanisms to get access to servers: Web 2.0 features rely on JavaScript, the "J" in "AJAX". The popularity of Web 2.0-style sites and applications is driving a dramatic increase in the amount of JavaScript code required to implement features. Many Web 2.0 features are […]

SecureWorks done a research called “Packer 2.0 threat” where hackers could use JavaScript packing mechanisms to get access to servers:

Web 2.0 features rely on JavaScript, the "J" in "AJAX". The popularity of Web 2.0-style sites and applications is driving a dramatic increase in the amount of JavaScript code required to implement features. Many Web 2.0 features are packaged together with a consistent API and distributed as a JavaScript "library". However, these libraries have to be loaded and reinterpreted for every page that uses a feature implemented in the library, and these libraries can be relatively large for web content -- tens or hundreds of kilobytes.

Although other, generally better, methods exist for reducing the number of bytes downloaded, the use of JavaScript "packers" has become accepted and widespread.

Computer hackers have taken advantage of the acceptance of these packers as suboptimal network optimization tactics and are using them as a way to evade and bypass security controls on the gateway and at the host. Consequently, exploits or other malicious code is delivered successfully because of the packer’s ability to bypass anti-virus and IDS/IPS and directly to a user's vulnerable system.

Much of the debate around the use of JavaScript packers is analogous to the debate around the use of Windows PE executable (EXE file) packers used by malware distributors. While lessons can be found there, the information below focuses on the use of JavaScript packers specifically.

The article goes over the different packers in use and lists their problems, here is the summary:

While the use of packers is widespread, all have drawbacks. These include:

  • The inability to easily verify and audit code
  • The administrative overhead of repacking code for each change
  • Suboptimal compression
  • The increased risk of false negatives which may lead to a site being used to spread malicious code
  • The increased risk of false positives, which may lead to a site or some of its functions being blocked by security controls
  • Noticeable negative impact on client-side performance.

Site owners, operators, developers and administrators can achieve intended results -- typically reducing the number of bytes downloaded from the server -- with greater degree of success and fewer side-effects using one or more alternative tactics:

  • Not compressing JavaScript code at all
  • Reliance on increases in average available bandwidth
  • Reliance on local and network caching
  • Not using more JavaScript functions than necessary (smaller library "builds")
  • Using only safe whitespace/comment reduction techniques
  • Automatic application of safe techniques as a last step in the publishing process
  • The use of mod_deflate/mod_gzip for compressing the HTTP response data
  • The use of jar files to package JavaScript (these can be cryptographically signed to further enhance authenticity of code, and hence improve security)

Full Article

Security, JavaScript, JS, Packer, JS Packer, Threat