[VOIPSEC] Blocking PING, and get REGISTER message

[J. Oquendo]

On Sun, 07 Dec 2008, Gilbert Lee wrote:


> I attached capture file gilgil.cap(SIP account: gilgil at optel.org). As you
> see, after registration is completed successfully, SIP client(X-Lite) sends
> only 4 byte(0x0D0A0D0A) packets periodically to SIP proxy to keep
> connection. As I know, Keep Alive methods are different according to SIP
> service(not always accurate).

For starters, there are no "keepalives" for SIP packets. It's
going to be something, sending something else. In most cases
it's a quick REGISTER. This was talked about (keepalives) in
"Guidelines for implementors using connection-oriented
transports in the Session Initiation Protocol" which is now
linked for you.

https://svn.resiprocate.org/viewsvn/ietf-drafts/gurbani/draft-gurbani-sipping-connection-guidelines-01.txt?view=markup&sortby=log

Most implementations of what are considered "KEEPALIVES" will
be based on IP - take your pick: ICMP, UDP, TCP. Most vendor
equipment simply does a re-register which occurs on good links
in ms. With today's speeds, the need for a keepalive is kind
of moot.

> inline.
> I used ARP spoofing skill to be in the middle between SIP client and proxy.
> before attacking : SIP client - Gateway - Internet - SIP Proxy
> after attacking : ARP spoofing: SIP client - Attacker - Gateway - Internet -
> SIP Proxy

Again, you miss some core fundamentals of it all. So what is the
purpose of your attack. Toll fraud? In a properly configured
environment it would not occur. (port-security, VLAN's, etc.) So
let me give you the benefit of the doubt here. Here is your attack
right back at you

You (wire) --> ARP Spoof --> Switch --> Proxy --> Call

However this has to occur for you to make your call and hear the
other party:

Recipient --> Proxy --> Switch --> You
You --> Switch (you're spoofed) --> Proxy --> Recipient

And this has to continue throughout the conversation without a
flaw. Here is how it can fail... 1) You'd have to DoS out the
original device whose MAC you're now "SHARING/Spoofing" because
as IP law dictactes, not two devices can have the same address.
I won't get into IP spoofing much here, if you don't understand
it at the core, I suggest picking up some books on this.

So with your attack you now have two devices on one MAC.

You (spoofed MAC)
Device (stolen MAC)

In a MITM environment you have to perform this:

You --> Device --> Hi I'm really this switch
You --> Switch --> Hi I'm really this device

Remember, the switch is now sending you based off of MAC addresses
information which was destined for elsewhere. However, the device
is going to do something at some point, so how do you stop that
"whatever" from hitting the switch causing a collision?

> PING message which I am saying is not ICMP based packet but Keep Alive
> packet used in SIP. Sorry for my confusing. :)

There is no "bonafide" KEEPALIVE, there are "work arounds" for this
along with a draft for stun:

http://tools.ietf.org/html/draft-holmberg-sip-keep-02

So again, remove SIP and go to the core of it all. How do you
propose to get around common network issues (port-security, etc).
In your scenario it's a horrible designed architecture for the
registrations and proxy servers. So re-sending... I can give you
usernames passwords and any kind of nonce iteration for you to
connect, what's your offense for my network defense? 

> Attacker says, "I want to capture authentication message, but victim(SIP
> client) never sends authentication message. How much time should I wait for
> the packet? I would like to capture authentication packet as soon as
> possible whenever attack(ARP spoofing) starts, so I will block(will not
> relay) PING message to capture the packet what I need."

ICMP carries no SIP information, so let's clarify this. Your best
choice to sniff the wire for any kind of auth would be to send out
a Denial of Service to the SIP client forcing it to resend out
REGISTER packets. Bottom line

> The only question, by contrast with this(for a security reason), is if there
> is good idea how I can detect and protect this attacker's trial(suppose that
> attacker can be in the middle between SIP client and SIP proxy).

You protect your devices not via SIP. Not via blocking ICMP's
but via architectural design. Now you won't always control
both sides of the wire, so you search out to make as best a
design as you can. This consists of layered NETWORK and
physical security. 

Outside of the obvious need for strong knowledge of networking
at its core (forget whether something is SIP, SMTP, HTTP), here
are some things for you to view.

www.utdallas.edu/~ksarac/netsec/PaperPresentations/SIP-Security-Attacks-Prevention.ppt
http://tools.ietf.org/html/draft-ietf-sip-sec-agree-00
http://www.archivum.info/sip@ietf.org/2007-08/msg00112.html
http://www.softarmor.com/wgdb/docs/draft-uusitalo-sipping-algorithm-agreement-00.txt


Sincerely



J. Oquendo


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