Skip to main content

How to protect your WebRTC app code?

I have spent some time analyzing which could be the best way to protect a privative version of a webphone based on QoffeeSIP that we are developing now at Quobis. I have seen this same question on different sites with quite confusing responses. So I'm going to share what I learned just in case it could help to anybody.

Well, I'm not going to define what is WebRTC because Internet is full of it this year (only overtaken by cats ;). For our purposes we have to consider that our app is a Javascript library. Really there is also HTML/CSS code but what I think that is important is Javascript, but HTML/CSS can also be protected in the same way but with other tools.

First of all I want to remark that protect your code in the sense of anybody could copy/modify and redistribute it is impossible since Javascript is only text. If anybody had enough time (or money) this code could be reversed. But, as always, we can do things trying to avoid it as far as possible.

In general, I found that there is a bit confusion between minimize and obfuscate terms so we're going to speak a bit about these techniques.

Minimization

The target is to get the code as small as possible. Obviously generated code is more difficult to understand, but it could be easily reversed with tools like JSbeautifier. (really not as easy depending of the minimizing tool)

Some common possible options at this point are:

  • UglifyJS: The coolest thing right now xD. It is a Node.js package so it's easy to include. Some days ago version 2 was published. We will see that it's fast, really fast.
  • Google Closure Compiler which uses Google to its apps. It is availiable a Java command line tool but there are node modules which use the online API.
  • YUI Compressor from Yahoo, it was the facto standard but now last alternatives are beating it.
A little comparison: I can't find original link, sorry :(
  • Average time: (lower is better)
    • UglifyJS: 0.11554 seconds
    • Closure: 1.41037 seconds
  • Average reducction: (higher is better)
    •  UglifyJS: 45.6%
    • Closure: 51.5%
NOTE: Another one (more complete) with YUI included too.

In my experience Google Closure generated code is better because besides minimization tasks it includes code checking too. It provides warnings for dangerous or illegal Javascript. Moreover I like that you can use this online service to check your code while developing.



Obfuscation

It is defined as "the hiding of intended meaning in communication, making communication confusing, wilfully ambiguous, and harder to interpret." (Wikipedia).

We have some options here when we are working with a web app:
  • Encrypt the transport layer: needed to avoid sniffing to another users of the same LAN. So using HTTPS to serving the application is a must.
  • Encryption: Encrypt application data and decrypt it on the fly via your own javascript enccryption library.
  • Move functions to the server side, which it's not possible in the case of WebRTC because we want end to end media.
  • Use a browser plugin, it has no sense since one of the advantages of WebRTC is that the user doesn't have to install anything.
  • Implement the code in native client for Chrome browser. The advantaje is that common C code protections can be used and the app runs sandboxed. But it is not our case because we need multi-platform support.
  • To avoid legal issues you should incude a note (a Javascript comment) referencing the copyright in each copy of the .js library. Something similar to Free Software Foundation recommendations for free Javascript code. An example could be:
NOTE: Really @source tag is proposed by FSF to include a link to source code of the app. But I think that it could be a good idea to use it because browser plugins that follow the recommendations should "understand" it.

// @source: https://qoffeesip.quobis.com
// Copyright (C) Quobis
// Licensed under Quobis Commercial license
// (http://www.quobis.com/licenses/commercial-1.0.html)

I also want to point out some common obfuscation/encryption problems:
  • Performance decrement, specially speed.
  • Increase troubleshooting difficult.
  • Compatibility problems (IE!!).
  • Size increase.
  • As it was said, a skilled expert could always reverse it and get a code equivalent to ours.
All these problems are more important on the case of encryption, except the last one logically. So at this point we have some options, but I've reduced them to these ones:
  • A paid option like JsCrambler: This is the reference tool, generated code seems to be really dificult to recover and it supports an important number of encryption algorithms.
  • A free solution provided by my colleague DamiánHorrible.js. It implements obfuscation and a kind of simple (so light) optional (through "factor" parameter) encryption. Next picture shows an example using it with the three different factors.

Finally, if you don't like the ugly generated code you can always use Nice.js to get something like this example: xD



In conclusion, I like Horrible.js with factor 3. In my opinion, it has no sense to paid for mitigating a risk impossible to solve completely.

Popular posts from this blog

ISO 27001: Inventario de los activos de información

Uno de los primeros pasos que debe seguir la entidad para adaptarse a la norma ISO 27001 es realizar el inventario de activos que contendrá todos aquellos activos de información que tienen algún valor para la organización y que quedan dentro del alcance del SGSI . En un principio puede parecer un poco abrumador para un principiante(como yo) por la enorme cantidad de activos que se te van ocurriendo por eso decidí empezar por clasificarlos de alguna forma, de entre las múltiples maneras que me encontré elijo la definida por los expertos del foro ISO27k ya que me parece la más completa, mostrando ejemplos de cada tipo y es válida para entidades de muy distinta naturaleza. Éste podría ser un buen punto para comenzar siempre teniendo en cuenta lo que nos aconsejan también en ese foro: "Debido a que los activos son algo cambiante, incluso si pudieras cubrir absolutamente todo lo que hay hoy, mañana la situación sería un poco diferente y más en unas semanas, meses o años. Así que

SIP extension enumeration in Bluebox-ng

There are some well known SIP extension enumeration vulnerabilities in different VoIP servers, specially in Asterisk. This brute-force vector is based on the study of the authentication responses of the target server. Sometimes its replies are different in the case that the client uses a valid extension, so it's easy to discover them. This vector is normally classified as a low security risk. Moreover we're moving towards a federated SIP environment , in which the extension is the public email address of the user. But it's still important in some cases: To guide next steps during a penetration test. In example, you can use the discovered extension to reduce the number of attempts in the phase of SIP extensión brute-force. Some RCE (Remote Code Execution) exploits need a valid extension to work. After a little research, these are the known vulns: CVE-2009-3727 : It's quite old and it's practically not present in real environments. It's still not imple

SIP INVITE attack with Metasploit

Some days ago my friend  @pepeluxx  wrote  another post  about INVITE attacks. He spoke about a  @sinologic   project  which allows to everybody passing some security tests to SIP servers. Furthermore he also published a perl script to do the same task. So I implemented it on Metasploit because I think It could be really useful during a pentesting. It’s interesting because these attacks are really dangerous, normally, attackers try to call to expensive locations. This target numbers often have special charges and they make money with this. Here there are two well known examples: http://blog.sipvicious.org/2010/12/11-million-euro-loss-in-voip-fraud-and.html http://snapvoip.blogspot.com.es/2009/02/calls-to-cuba-and-voip-attacks.html I’m not going to deep in this vector because of being a well known (and old!!) one. Basically the attacker tries to make a call using a misconfigured PBX. This is allowed because  SIP RFC  says that an extension has not to be registered to be abl