Logo Planet Security

September 25, 2013

Jesús Pérez

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 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. :)

posted by Jesús Pérez (noreply@blogger.com) at September 25, 2013 03:58 PM

September 16, 2013

Jesús Pérez

More brute-force modules in Bluebox-ng

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.
  • TFTP: Widely used in VoIP to auto-provisioning the softphones of an organization.
  • 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. ;)

posted by Jesús Pérez (noreply@blogger.com) at September 16, 2013 11:23 AM

September 06, 2013

Jesús Pérez

Bluebox-ng beta released

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:

  • IPv6 support. I would like to thank Olle E. Johansson (@oej) because of his research in SIP and IPv6, it did my work really easy.
  • Exploitsearch.net API support.
  • DNS module finished.
  • Nicer outputs.
  • Simpler setup process.
  • A network host/port scanner (Evilscan).
  • Dirscan-node upgraded to version 0.5.
  • Added some numerical lists (with different paddings) to use with brute-force modules.
  • Host list files and port ranges support included in SipScan module.
  • Solved SipBrutePass module problem with too much asyncronous requests.
  • A lot of refinements in the whole code.



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, NiktoW3af, 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. ;)

posted by Jesús Pérez (noreply@blogger.com) at September 06, 2013 10:21 AM

June 10, 2013

Jesús Pérez

Bluebox-ng Alpha release

Finally I've pushed the first Alpha version of Bluebox-ng to my GitHub repo: https://github.com/jesusprubio/bluebox-ng

Features
  • RFC compliant
  • TLS and IPv6 support
  • SIP over websockets (and WSS) support (draft-ietf-sipcore-sip-websocket-08)
  • SHODAN and Google Dorks
  • SIP common security tools (scan, extension/password bruteforce, etc.)
  • REGISTER, OPTIONS, INVITE, MESSAGE, SUBSCRIBE, PUBLISH, OK, ACK, CANCEL, BYE and Ringing requests support
  • Authentication through different types of requests.
  • SIP denial of service (DoS) testing
  • SRV and NAPTR discovery
  • Dumb fuzzing
  • Common VoIP servers web management panels discovery
  • Automatic exploit searching (Exploit DB, PacketStorm, Metasploit)
  • Automatic vulnerability searching (CVE, OSVDB)
  • Geolocation
  • Colored output
  • Command completion
  • GNU/Linux, Mac OS X and Windows
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.


posted by Jesús Pérez (noreply@blogger.com) at June 10, 2013 06:05 PM

April 08, 2013

Carlos López

How to connect to .onion Tor domains with Firefox on Linux

So you are looking for an easy way of surfing the hidden network of .onion domains?. Many people probably will use some of the proxies available to reach the .onion domains. Unfortunately this is not a good idea for your privacy since the proxy owner can spy all your communications.

So, I’m going to explain in 3 easy steps how to configure Firefox to access .onion domains directly through your local Tor daemon. This way, we ensure all traffic goes directly to the tor network.

  1. Install Tor daemon.
  2. On Debian/Ubuntu Linux distributions this is as easy as:


    • sudo apt-get install tor
  3. Configure Firefox to tunnel requests to .onion domains via the Tor network
  4. This is the tricky part, because we only want Firefox to tunnel requests to .onion domains via the Tor network, but we don’t want Firefox tu tunnel all the other requests via the Tor network. To achieve this we are going to use a proxy configuration file.

    • Save the following content in a file (for example as ~/.proxy_pac)
      function FindProxyForURL(url, host) {
          isp = "PROXY ip_address:port; DIRECT";
          tor = "SOCKS 127.0.0.1:9050";
          if (shExpMatch(host,"*.onion")) {
              return tor;
          }
          return "DIRECT";
      }
      
    • And configure Firefox to use that file as a proxy configuration file (Edit->Preferences->Advanced->Network->Settings->Automatic proxy configuration URL).
      • You have to use the following syntax: file://absolute-path-to-the-file
      • If you are not sure, just open a new firefox window, and type on the browser location bar (the place where you type web addresses) the following URL file://. Now just browse your HDD to where you saved that file, right click on it and select Copy Link Location. Now paste such link location on the Automatic proxy configuration URL settings.
  5. Configure Firefox to tunnel DNS queries via a SOCKS5 proxy
  6. The last step is to tell Firefox that it should tunnel the DNS lookups via the Tor SOCKS5 proxy when we want to access a .onion domain. By default firefox will try to resolve .onion domains using our local DNS resolver, therefore it will fail to do that.
    To fix this, we should enable network.proxy.socks_remote_dns on the advanced configuration page:

    • In the browser location bar (the place where you type web addresses), type about:config and press Enter. This opens a different set of Firefox preferences. Where it says Search: at the top, type network.proxy.socks. The list of preferences will automatically change to show your proxy preferences.
      Highlight network.proxy.socks_remote_dns by clicking it only once. Then, right-click it. This opens a small pull-down menu. Select Toggle from the menu to change its value to true.

    This will make Firefox to tunnel all the queries to .onion domains via our local Tor daemon. This also adds privacy by preventing DNS queries to .onion domains from leaking.

Now restart Firefox and you should be able to surf .onion domains directly.

posted by clopez at April 08, 2013 09:52 PM

March 27, 2013

Jesús Pérez

My new toy: Bluebox-ng

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.

Install deps

  •  cd bluebox-ng
  • npm install

Run

  • npm start

Features

  • Automatic pentesting process (VoIP, web and service vulns)
  • SIP (RFC 3261) and extensions compliant
  • TLS and IPv6 support
  • VoIP DNS SRV register support
  • SIP over websockets (and WSS) support (draft-ietf-sipcore-sip-websocket-08)
  • REGISTER, OPTIONS, INVITE, MESSAGE, SUBSCRIBE, PUBLISH, OK, ACK, CANCEL, BYE, Ringing and Busy Here requests support
  • Extension and password brute-force through different methods (REGISTER, INVITE, SUBSCRIBE, PUBLISH, etc.)
  • DNS SRV registers discovery
  • SHODAN and Google Dorks
  • SIP common vulns modules: scan, extension brute-force, Asterisk extension brute-force (CVE-2011-4597), invite attack, call all LAN endpoints, invite spoofing, registering hijacking, unregistering, bye teardown
  • SIP DoS/DDoS audit
  • SIP dumb fuzzer
  • Common VoIP servers web management panels discovery and brute-force
  • Automatic exploit searching (Exploit DB, PacketStorm, Metasploit)
  • Automatic vulnerability searching (CVE, OSVDB)
  • Geolocalization using WPS (Wifi Positioning System) or IP address (Maxmind database)
  • Colored output
  • Command completion

Roadmap

  •  Tor support
  • More SIP modules 
  • SIP Smart fuzzing (SIP Torture RFC)
  • Eavesdropping
  • CouchDB support (sessions)
  • H.323 support
  • IAX support
  • Web common panels post-explotation (Pepelux research)
  • A bit of command Kung Fu post-explotation
  • RTP fuzzing
  • Advanced SIP fuzzing with Peach
  • Reports generation
  • Graphical user interface
  • Windows support
  • Include in Debian GNU/Linux
  • Include in Kali GNU/Linux
  • Team/multi-user support
  • Documentation
  • ...
  • Any suggestion/piece of code ;) is appreciated.

Author

Jesús Pérez

Contributors

Damián Franco
Jose Luis Verdeguer

Thanks to ...

  • Quobis, some hours of work through personal projects program
  • Antón Román (@AntonRoman), he speaks SIP and I'm starting to speak it thanks to him
  • Sandro Gauci (@sandrogauci), SIPVicious was our inspiration
  • Kamailio community (@kamailioproject]), my favourite SIP Server
  • David Endler and Mark Collier (@markcollier46), authors of "Hacking VoIP Exposed" book
  • John Matherly (@achillean) for SHODAN API and GHDB
  • All VoIP, free software and security hackers that we read everyday
  • 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 .

posted by Jesús Pérez (noreply@blogger.com) at March 27, 2013 12:52 AM

February 26, 2013

Jesús Pérez

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.

posted by Jesús Pérez (noreply@blogger.com) at February 26, 2013 12:06 PM

January 16, 2013

Jesús Pérez

Playing with QoffeeSIP: SIP over websocket scanner

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.


script.coffee
##
# Copyright (C) Quobis
# Project site: https://github.com/Quobis/QoffeeSIP
#
# Licensed under GNU-LGPL-3.0-or-later (http://www.gnu.org/licenses/lgpl-3.0.html)
##


# On document ready...
$ ->
# Avoid page "reloading" on submit.
$("form").submit (e) ->
e.preventDefault()
false

# Declaration of api.
api = null

$("#init").submit =>
options =
server: {ip: $("#server-ip").val(), port: $("#server-port").val()}
onopen: =>
api.register "qoffeesip", "anonymous"
api = new API options
api.on "new-state", (state, message) ->
switch state
when 2,3
userAgentRE = /User-Agent:(.*)/i
serverRE = /Server:(.*)/i
organizationRE = /Organization:(.*)/i

matchUa = userAgentRE.exec message.frame
matchServer = serverRE.exec message.frame
matchOrganization = organizationRE.exec message.frame

output = matchUa or matchServer or matchOrganization
$("#output").text(output[0])

index.jade
//-
//- @source: https://github.com/Quobis/QoffeeSIP
//- Copyright (C) Quobis
//- Licensed under GNU-LGPL-3.0-or-later (http://www.gnu.org/licenses/lgpl-3.0.html)
//-


!!!
head
title SIP over websockets scanner
script(src="lib/jquery-1.8.0.min.js")
script(src="lib/spine.js")
script(src="lib/underscore.js")
script(src="lib/qoffeesip.js")
script(src="script.js")

body
form(id="init")
input(id="server-ip", type="text", placeholder="Server IP", required)
input(id="server-port", type="number", placeholder="Port", required)
input(type="submit", value="Scan")

div(id="output")


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").

- Download the examples using git.
git clone https://github.com/Quobis/QoffeeSIP.git
cd qoffeesip/examples/sipwebsockets-scanner

- Generate the files to distribute it.

make

- Copy them to your Apache server:

sudo cp -R dist/* /var/www

Here 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.


QoffeeSIP demo

posted by Jesús Pérez (noreply@blogger.com) at January 16, 2013 09:15 AM

October 08, 2012

Jesús Pérez

Fixing some SIP related Metasploit modules

Hi again, while I was checking some demos for our class at Vigo University representing Quobis I noticed that Metasploit options.rb module (SIP scanning) wasn't working ok. I mean, it was unable to recognize a Kamailio server. Next two pictures show the difference with SIPVicious output:



Some time ago, I wrote a post about this module and I remember being a bit surprised because the code doesn't respect SIP protocol at all (but It worked with Asterisk). After a quick view to Kamailio logs my suspects were confirmed, Sanity module was doing right its job dropping these packets. :)


Next function defines how requests are created in actual module, If you are familiar with SIP RFC you probably will notice what I'm talking about. If not, I suggest you to compare it with my create_request function of sipflood.rb module.


    def create_probe(ip)
        suser = Rex::Text.rand_text_alphanumeric(rand(8)+1)
        shost = Rex::Socket.source_address(ip)
        src   = "#{shost}:#{datastore['CPORT']}"

        data  = "OPTIONS sip:#{datastore['TO']}@#{ip} SIP/2.0\r\n"
        data << "Via: SIP/2.0/UDP #{src};branch=z9hG4bK.#{"%.8x" % rand(0x100000000)};rport;alias\r\n"
        #data << "From: sip:#{suser}@#{src};tag=70c00e8c\r\n"
        data << "From: sip:#{suser}@#{src};tag=70c00e8c\r\n"
        #data << "To: sip:#{datastore['TO']}@#{ip}\r\n"
        data << "To: sip:#{suser}@#{ip}\r\n"
        data << "Call-ID: #{rand(0x100000000)}@#{shost}\r\n"
        data << "CSeq: 1 OPTIONS\r\n"
        data << "Contact:  sip:#{suser}@#{src}\r\n"
        data << "Content-Length: 0\r\n"
        data << "Max-Forwards: 20\r\n"
        data << "User-Agent: #{suser}\r\n"
        data << "Accept: text/plain\r\n"
    end 


Once some changes were done in order to use my function (with OPTIONS packets), we can see that we have a correct response now.


This issue often appears working with Session Border Controllers so I coded our own version of these modules. Nothing else, here there are the links to the new version of the modules. I also added this feature to enumeration.rb module, needed to brute-force valid extensions. 

Anyway, If you try to enumerate Kamailio extensions you will fail because its default configuration avoid this. Asterisk also has an option to do it but it can be bypassed. And FreeSWITCH? We will play with all this stuff another day. ;)

posted by Jesús Pérez (noreply@blogger.com) at October 08, 2012 02:03 PM