[VOIPSEC] Blocking PING, and get REGISTER message

[Gilbert Lee]

Thank you for your response.
Let me introduce some documents to you.

http://gilgil.springnote.com/pages/2250034

I wish it would be helpful.
Thank you.

Regards
Gilbert Lee

On Sat, Dec 6, 2008 at 9:33 AM, J. Oquendo <sil at infiltrated.net> wrote:

> On Sat, 06 Dec 2008, Gilbert Lee wrote:
>
> > Hi, all. I have a just simple question. What do you think about "Blocking
> > PING packet of VoIP client"?Most of VoIP clients adopt keep alive
> algorithm
> > to keep connection with SIP proxy(sending and receiving PING message
> > periodically).
>
> Depends on the environment. Which are you coming from a VoIP
> provider perspective, or a PBX administrator's perspective.
> For example, I work at a VoIP carrier, we do SIP/PSTN
> termination, managed PBX's, etc. I could care less about the
> ping factor blocking it is not security.
>
> > Attacker would like to get VoIP client's SIP message including
> > authentication value(MD5 or plain),
> > but unless VoIP client reboots(REGISTER) or make a call(INVITE), it never
> > sends authentication value through network.
>
> Again, depends on the situation. If I configured the network
> Voice would be separated from VLAN's with port security on
> the switches, so the chances of you sniffing something are
> unlikely. You could come back with "but I can VLAN hop!"
> and I'll counter with my NAC and SIEM noticing and stopping
> you in your tracks while notifying me.
>
> > For attacker to acquire victim's SIP authentication value, suppose the
> > following scenarios.
> >
> > 1. Attacker is in the middle of network between VoIP client VoIP proxy.
> > 2. Attacker blocks only PING packet while other packets are routed in a
> > normal way.
> > 3. If PING packet is blocked, VoIP client should think that network is
> > disconnected, and it trys to recconnect.
> > 4. In reconnect procedures of VoIP client, it send REGISTER message
> again.
> > 5. In this way, attacker can get REGISTER authentication value without
> any
> > touching VoIP client with his hand.
> >
> > I've figured out that most PING message syntax is very simple that I've
> ever
> > tested.
> > Of course, if authentication message is encrypted with MD5 and password
> is
> > long enough, it is hard for attack to hack it's original password.
> >
> > Any way, do you any idea, solution or mechanism that is enable to detect
> > such an attack like this?
>
> You seem to be sort of off track with the networking portion of
> things. So let me ask you this... What is the bottom line of
> your attack? From my point of view, even if I outright gave you
> a username and password for one of my trunks, wouldn't mean
> anything since the majority of the times my accounts are using
> static IP's.
>
> So you now think "aha! IP Spoofing!" and there too you will be
> wasting your time. So you blind spoof, then what? Sure you can
> send whatever you'd like as an attacker doing blind spoofing
> the problem is, you'd never have anything returned to you since
> you're obviously not the true sender.
>
> So what can you with your attack? Toll fraud? Free calls? No.
> Annoy? Maybe. It all depends on who's administrating the system.
> So allowing or disallowing ping means literally nothing to be
> blunt about it. As for your assumption of md5 being difficult,
> there too you're a bit confused. For example, how was the
> md5 checksum obtained? In an improper system is the following
> security:
>
> $ uname -s
> FreeBSD
> $ echo "clientsname" | md5
> 7d6fc4ae7daccd3d94c4db45287b7f8e
>
>
> So now I have a hash, can I look this up with say a rainbow
> table? Can I perform an inference attack? If I'm looking at
> the sip packet and see a hash like this, and I see say:
>
> From: clientsname <clientsname at sipservesomething.com>
>
> What's to stop me from trying to echo "sipservesomething"
> piped to md5 followed by the username or any combination
> of what's in the SIP message.
>
> Username/password combinations for SIP are horrible as is
> but they can be protected. It goes back to the core of it
> all. Forget about VoIP for a second. Think about it on the
> technical level, how would you defend someone from trying
> to connect to say your mail server. Would you also block
> your mail server from responding to ICMP's? That wouldn't
> stop someone scanning with say nmap -P0 -p 25,110,143
> would it.
>
> So what would be the point with VoIP?
>
>
> =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
> 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
>
>