[VOIPSEC] Blocking PING, and get REGISTER message

Sat Dec 6 18:27:39 GMT 2008

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. 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. (2) Use a long password even
if authentication message is exposed. (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. For example, attacker goes out of
his home, arrives somewhere where free internet is available, scans hosts to
detect VoIP client with his notebook, begins to attack the host(using ARP
spoofing), and, at last, waits for SIP authentication message(REGISTER,
INVITE, BYE, etc) from the host for a long time. Attacker is impatient to
wait for the packet which contains SIP authentication packet, and he
complains "How can I sniff authentication message so rapidly?". By the way,
does quick REGISTER message contain authentication message? Devices those I
have do not send REGISTER message to keep connection. In fact, I am not an
expert of SIP protocol. I've got many information from you those I haven't
known. Anyway, thank you, Oquendo. I will see those you suggested to me.
Sincerely Gilbert Lee.

ps: I'm not an attacker but a programmer. Call me just a coder. :)

On Sun, Dec 7, 2008 at 1:21 AM, J. Oquendo <sil at infiltrated.net> wrote:

>
> 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
>
>
> _______________________________________________
> Voipsec mailing list
> Voipsec at voipsa.org
> http://voipsa.org/mailman/listinfo/voipsec_voipsa.org
>