[VOIPSEC] Blocking PING, and get REGISTER message

Sat Dec 6 17:09:17 CST 2008

On Sun, 07 Dec 2008, Gilbert Lee wrote:

Comments inline, separated for clarity.

> First of all, I would like to say why I am interesting in this theme. In
> Korea where I live in now, there are many places(air port, subway station,
> coffee shop, department store, home, etc) where I can use wireless internet
> for free(REALLY FREE!!! I do not need to input WEB-key to use other wireless
> internet), and moreover, nowadays, so many people use VoIP services based on
> SIP protocol.

So getting back to the provider, as a carrier, most of the
trunks I do are IP based. Remember, this is a trunk to an
SBC. Getting more granular to the PBX level, there are a
few tricks up my/my company's sleeve, which I won't point
out on a public mailing list. For our "home based" VoIP
client's, most are using a mixture of Tigernetcom, Sipura,
Linksys ATA's. The authentication used is not as great as
I would want it to be, but this is because we have to keep
things simple for the home based users who can barely tell
you the difference between Windows and Mac.

>From my perspective, as a VoIP carrier concerned with the
potential for toll fraud, what are my options... Vigilance ;)
Vigilance, curiousity and a thorough knowledge of designing
strong networks even if I can't control them.

In comes an IPS on steroids gone bizarrely wrong or right
depending on your view. My coworker hates it since he often
has to flush firewall rules, but I will give you a taster
of how it works...

Log files are monitored a-la Snort if you will. Clients
(SIP agents) log in and their IP is thrown somewhere:

client - IP - Time

If client logs in from another address with another Client
logged in from another it gets flagged, we're notified. This
process is going to be carried out for some time to associate
common IP addresses to a client... So supposed client X has
always logged in from say 10.10.10.2 and he is not in an
altogether different subnet, a flag is sent, we watch the
second address for sometime. Remember our presumption is that
the ATA's are static. Redflag block? Someone in ARIN all of
the sudden registering from RIPE or APNIC. Instamagic block.

Any combination of errors for X amount of times? The address
is blocked as well. Now because of the structure of the way
we do things at work, I decided to make this kind of in
distributed fashion. Meaning, you get your address blocked
on one machine, you're blocked on all PBX's period. When I
made my IPS my notion was, if I needed to block you from
connecting to one address, I might as well warn all of the
other machines in my network...

> It means that SIP packets are easy to be exposed to attacker
> on client side. Of course, port-security or VLAN(separating voice from data)
> is a good policy for secure, but it is hard for all home users to be asked
> to configure their own VLAN network configuration(wireless access point).
> ARP spoofing is old-fashioned hacking technique, but it is not hard to
> protect it in ethernet and IPv4 network environment. ARP spoofing is still
> available in many other places. To conclude, VoIP service provider knows
> that "Packets can be sniffed by attacker in many ways", and solutions
> against attacking are (1) Secure SIP and RTP.

Any packet can be exposed period. So the attack vector via
something tunneled is moot unless someone did something
really dumb like made an aggressive mode tunnel - and anyone
looking to shave milliseconds off their IPSEC with aggressive
mode should not be making tunnels nor playing with security.

>From the provider perspective, our main goal is to provide
as transparent a service as possible. If you've never worked
at a provider, ISP, or something similar, you can never
truly appreciate the need for practicing patience. I've
had to deal with "walking" other engineers (I should start
saying this loosely at some point) - walking them through
simple things like identifying their own gateways.

The more complex things become for both ends, the more
difficult it becomes to troubleshoot when something out
of the ordinary occurs. Personally I prefer building out
trunks and managing PBX's on the carrier level than I
prefer dealing with home users a-la Vonage. For me it is
a waste of money at the end of the road.

> (2) Use a long password even if authentication message is exposed.

Would never work. In the instance of say one of my clients
on the home end, its difficult enough for my customer
service department to get them to type ipconfig let alone
spending time walking them through anything over a 12 char
password.

> (1) is for VoIP service provider while
> (2) is for customer(user). There are still many users who use not a long but
> a short password, so attacker would like to sniff SIP based authentication
> message to acquire victim's SIP account.

The concept of password and breaking them is lost with
many security engineers. I think - from my personal
experience in this industry - too many people focus so
much wasted breath on this. I mean coming from a pentester
perspective now... I rarely waste my time with targeting
a password when I want in. I can find dozens of other ways
in without the need to even remotely worry about "zOMFG!!
What rainbow table am I gonna use!" or "zMOFG!! What salt
and wordlist should I use!"

When it DOES come to password cracking rehashing, here is
where you wasted your time... You stated you were on the
wire performing ARP spoofing... If the network is that
cruddy, and you even stated its a home based network, I
bet you that you could log right into their ATA and just
retrieve the password without dealing with any nonces, any
kind of hashing, any kind of "uber hacking".

Anyhow, the attack(s) you wrote of, for crappy home
networks, sure. On an enterprise level, I would like to
say it won't happen but I know of many an unclued and
unstructured network which it would likely work on.

However in a "true" enterprise environment, 1) the PBX
administrators and or security engineers should be able
to flag it. I do it sometimes just by having monitoring
on screen in realtime. 2) From the carrier level, I would
like to hope they take security serious enough to go back
to the basics of pure networking, common sense and a bit
of security experience. I can't see a reason why this
would be possible from a carrier.

Lastly, because I can be weird like that ;) I STILL wonder
what happen to that *one* VoIP Security company which one
day released - what was it - a million advisories... Maybe
they can make a fix for it. Alright it wasn't a million
advisories, I believe it was about 100 and coincidentally
it was April Fools.

Happy holidays all... P.S. If anyone is in or around the
Dulles VA area this week and cares to have an even beer
or slice of pizza or something send me a message.

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
J. Oquendo
SGFA, SGFE, C|EH, CNDA, CHFI, OSCP

"Each player must accept the cards life deals him
or her: but once they are in hand, he or she alone
must decide how to play the cards in order to win
the game." Voltaire

227C 5D35 7DCB 0893 95AA  4771 1DCE 1FD1 5CCD 6B5E
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x5CCD6B5E