9/25/2013

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.

CVE-2009-3727: It's quite old and it's practically not present in real environments. It's still not implemented in Bluebox-ng, waiting for the complete re-write of the SIP stack in which is working Damián.

CVE-2011-2536: It's much more common than the last one. The option "alwaysauthreject", which the CVE speaks about, is disabled by default in old versions of Asterisk and a common bad practice in actual ones. Bluebox-ng implements it in the "sip-brute-ext" module. In this old post I deep a bit more in the used method.

(There is no CVE): This technique uses INVITE packets, there are some situations in which Asterisk allows the same goal even with the parameter "alwaysauthreject" enabled. They were discovered by Francesco Tornieri and published in packet storm. Now, the same Bluebox-ng module implements it. So @dvirus, you can now use it against your Busy Tone VulnPBX virtual machine ;).

CVE-2011-4597: It's similar to the other ones, but this time the server (Asterisk) answer to a different port when a valid extension exists due to an specific NAT related setup. This technique is supported through "sip-brute-ext-nat" module.

Finally I've also solved an important problem with the asynchrony in "sip-brute-pass" module which was very annoying to deploy a serious penetration test. :)

9/16/2013

The last day I said that now we're going to automate all VoIP tasks trying to build a VoIP/UC vulnerability scanner. But I realized that there are some other tasks which I need in each penetration test that we could add too. This way we could avoid to use another tools for an important part of the work.

Normally, we're hired to deploy a VoIP specific penetration test, but we also like to check (in a minimal way) the rest of implied services. So I've added next modules brute-force modules:

Asterisk AMI: It was a must because this is a very common scenario.

MySQL: The most common DB engine among VoIP servers.

MongoDB: It's not used in VoIP, but I've been playing lately with this system and I really like it. So I decided also to add a module.

SSH / (S)FTP: More common protocols.

HTTP(S): Useful when we find a web management panel for a VoIP server.

LDAP: Sometimes the VoIP servers perform the authentication against an existent LDAP instance (Microsoft Active Directory is also included here).

Finally I would like remark that, in my oppinion, we should solve next issues to build a professional tool:

Network scanner: For now we're using Evilscan, but it only supports full TCP scan (neither SYN nor UDP) and the project seems stopped.

Web vulnerability scanner: I don't know any tool for this written in Node.js. The most similar thing I found is Dirscan-node, useful to make directory brute-force but it's not a complete web vuln scanner.

In fact, I'm using Nmap and Skipfish to achieve these goals for now. So if you're thinking in a new security project (in Node.js) these ideas could be a good one. ;)

9/06/2013

I've just pushed the last changes to Bluebox-ng repo to get what we consider a beta version. It's not yet finished but it's much more stable than the previous release. Here there is a resume of the changelog:

I want to say that we've decided to re-define the project like a "VoIP/UC vulnerability scanner", this way we can work more focused. Our idea is to write a tool to test in an automatic way our deployments. There are several options when we think in other environments such as the web (Skipfish, Nikto, W3af, etc), but we've not anything similar in VoIP.

For now we have a bunch of tools (modules) that do the job in a comfortable (but indepentent) way. So, it's time to join all of them to automate the different tasks needed when we deploy an specific VoIP penetration test.

Finally we hope to present the first stable version at GSICKMINDS (A Coruña, 24-25-26 October), a great security event which I recommend to everyone. We're going to have here some security pr0n stars and we're in one of best places in the world to enjoy a few days. ;)

I'm sorry but we still do not have documentation about the tool. For now, we have the README file included in the source code (which shows the steps to start the tool) and this another post in Security by Default blog which includes some more shoots of this first version.

3/27/2013

Hi again guys, here there is my new personal project. I think that README file is complete enough so I paste it on this post.

Next month I'll be with my colleague Antón at Kamalio World Conference showing a bit more about it. If you are there and want to talk a bit about VoIP security (or WebRTC) get in contact with us please. :)

Finally, we would like to publish the first version in one ore two months, sorry but we're developing it mostly in our free time :(. I've promised Yago to do it on Security by Default blog so stay tuned.

Moreover this tool was included in Quobis personal project plan so you can always follow Quobis planet in which we publish all our experiments.

Nothing else, I hope you like it and all kind of suggestions (and coders) are welcomed :).

Bluebox-ng

Bluebox-ng is a next generation UC/VoIP security tool. It has been written in CoffeeScript using Node.js powers. This project is "our 2 cents" to help to improve information security practices in VoIP/UC environments.

Loopsize, a music hacker (and a friend) creator of the themes included in demos

License

This program is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation, either version 3 of the License, or
(at your option) any later version.

This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.

You should have received a copy of the GNU General Public License
along with this program. If not, see .

2/26/2013

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.

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.

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án: Horrible.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.

1/19/2013

Some days ago my friend @pepeluxx wrote another post about INVITE attacks. He spoke about a @sinologicproject 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:

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 able to make a call, only to receive it. Really most SIP servers implement authentication both in registering and calling process (and even to hang up a call), this is useful in eavesdropping scenarios in order to avoid SIP Teardown (BYE) attacks. But only a few systems have this configuration enabled by default, most of them use authentication only to register. In example, for Asterisk we should change “allowguest=no” in "sip.conf" file to ask for authentication in each call (INVITE). Apart from this, sysadmins should be also very carefully defining the dialplan to be secure. A common example of what not to do is the next one, in where outbound (to PSTN) calls context is included in default one:

(sip.conf file)

[general]

context=default

(extensions.conf file)

[default]

include => outbound

I committed the module to my Github project, it only implements a SIP INVITE request where the user can provide next parameters:

Module parameters

You should try to call to a common phone number (you can see it in last picture) and with an extension because servers normally work in a different way. The code simply sends an INVITE request with provided options and then it parses the response. If it is a “Trying” you could be in a problem man. ;)

Possible insecure system

Possible insecure system

Secure system to this vector

These are the links to both UDP and TCP version of the tool. I would like to remember that Metasploit modules which support TCP also support TLS. You can change the version of the protocol and another optional parameters with command “show advanced”.

Finally I want to say that last days I was reviewing my SIP Metasploit modules trying to add some more features (like SIP proxy support) and I found that they are a mess. There is a lot of repeated code and they are complex to maintain. So, after speaking with some Metasploit guys on irc channel, I’m going to write a new SIP Proto ("lib/rex/proto/sip.rb") class and a Mixin ("lib/msf/core/auxiliary/sip.rb") which uses it. Once solved this I’m going to add all SIP modules I have developed to official Metasploit distribution.

1/16/2013

Some weeks ago we published QoffeeSIP, the Javascript SIP over websockets stack which we use to develop our WebRTC products in Quobis. An example is IdentityCall, a system designed to provide call authentication in traditional VoIP and IMS environments. Now it achieves the same goal in WebRTC ones, interconnecting them at the same time with PSTN network.Today I’m showing a different case of use that those proposed in examples (the "simplest-example" and a "webphone"). I’m going to write a simple (but for sure the first one in the world ;) SIP over websockets server scanner. It should send a valid SIP (over websockets) petition, parse the interesting info from the response ( i.e. "User-Agent") and print it. I’m using the simplest example as basis, here there are the description of the changes I made on the code:- In this case no HTML video tags are provided to the constructor. The reason is that we are only using websocket features of the stack, not WebRTC ones.- Some stuff deleted from the interface in order to ask only for needed parameters (ip address, port and optionally the extension used to made the registration).- Media parts were also deleted from script.coffee file, which defines the logic of the app.- Obviously we need to change this logic so I added some code at the end. In this case we are saying that when states 2 (Registering after challenge) or 3 (Registered) are reached, received message is going to be parsed.- Then strings "User-Agent", "Server" and "Organization" are parsed from this response and printed. Really we are getting it from an object with the property "frame".- Finally, makefile is modified in order to generate the output with the correct name.

I have committed this example to QoffeeSIP examples of use, so you can download and use it as explained is QuickStart guide of the project. The command "make build" (or simply "make") is going to put the output files in "dist" folder. Then you only have to move them to an HTTP server, like Apache. You could follow next steps:

- Confirm you have installed coffeeScript and Jade in your system, if not you can use npm to install them ("coffee-script" and "jade").

- Copy them to your Apache server:sudo cp -R dist/* /var/wwwHere there are a few shoots:

Scanner setup

Scanning IdentityCall server

Scanning Kamailio

In a real tool, for best results, we should make some improvements like these:

- Use OPTIONS packets because of being more accurate for this target.

- Add support to ranges of ip addresses.- Avoid asking for approval to use webcam and/or micro. Really it is not used but it’s a limitation of the stack. We decided to do this request during registering instead of during a call because of usability issues.- Use Bootstrap to get a more friendly interface.But this is only a proof of concept so I think it is good enough for now. The target of this post is to show a different way of playing with the stack. Anyway I’m going to add support for websockets to my SIP Metasploit modules in any moment if you are interested in more professional tools.In the same way, if you were interested in a more complex application you can visit the online demo which implements "webphone" example of use. So you can play with it too, if you need help you can always open an issue on Github repository.