[VOIPSEC] RE: Voipsec Digest, Vol 2, Issue 36

Mon Feb 28 13:59:53 CST 2005

If the switched network does not protect against arp poisoning,
eavesdropping is quite easy.  I'm in the process of writing a GCIH
practical on that very subject.  There are several tools that allow
session hijacking on switched networks, among them dsniff
http://www.monkey.org/~dugsong/dsniff/ and ettercap
http://ettercap.sourceforge.net/.  I'm working on a Cisco skinny station
protocol network because that's what I have experience with, but it
hasn't been hard.  Ethereal has very good dissectors for skinny so you
can see how the control flow works, and the audio data is carried in
unencrypted rtp packets.  So far the hardest part has been writing my
tools to accommodate 802.1q vlans, since Cisco recommends the use of a
voice vlan.  Any corporate voice network (Cisco anyway, don't know about
SIP) that does not use either some form of protection against arp
poisoning or aggressive measures to keep pc's off the voice network is
exposed to attack.
Thanks
John

John York
Network Engineer
Blue Ridge Community College
One College Lane, Weyers Cave VA 24486
540.453.2255 

> -----Original Message-----
> From: Voipsec-bounces at voipsa.org 
> [mailto:Voipsec-bounces at voipsa.org] On Behalf Of 
> Voipsec-request at voipsa.org
> Sent: Saturday, February 26, 2005 7:05 PM
> To: Voipsec at voipsa.org
> Subject: Voipsec Digest, Vol 2, Issue 36
> 
> Send Voipsec mailing list submissions to
> 	Voipsec at voipsa.org
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> 	http://voipsa.org/mailman/listinfo/voipsec_voipsa.org
> or, via email, send a message with subject or body 'help' to
> 	Voipsec-request at voipsa.org
> 
> You can reach the person managing the list at
> 	Voipsec-owner at voipsa.org
> 
> When replying, please edit your Subject line so it is more 
> specific than "Re: Contents of Voipsec digest..."
> 
> 
> Today's Topics:
> 
>    1. Re: [SPAM] RE: [VOIPSEC] Actual Attacks (Geir Harris Hedemark)
>    2. Re: Actual Attacks (Simon Horne)
>    3. Re: Voipsec Digest, Vol 2, Issue 33 (Gerald Maguire)
>    4. RE: Actual Attacks (Brian Rosen)
>    5. RE: SNMP support	
> forEventCorrelation/NetworkManagementSystems
>       (Brian Rosen)
>    6. RE: VoIP and Fraud (Brian Rosen)
>    7. RE: Re: Voipsec Digest, Vol 2, Issue 33 (Brian Rosen)
>    8. RE: Actual Attacks (Stauffer Michael)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: 26 Feb 2005 14:57:10 +0100
> From: Geir Harris Hedemark <geir at dod.no>
> Subject: Re: [SPAM] RE: [VOIPSEC] Actual Attacks
> To: <voipsec at voipsa.org>
> Message-ID: <xq3y8dbctl5.fsf at kuusi.ifi.uio.no>
> Content-Type: text/plain; charset=us-ascii
> 
> "Christopher A. Martin" <chris at infravast.com> writes:
> > One other side note to this topic...
> > One of the funny things about existing attacks against VoIP 
> > services...to date the big ones that I have seen and 
> mitigated involve 
> > the application being implemented with either default values or the 
> > OS/Hardware not being properly hardened or secured by 
> firewalls/IPSec.
> 
> The one really big vulnerability I have seen in VOIP services 
> viewed at the system level was the web front-end created by a 
> VOIP provider. Admittedly, I haven't seen very many.
> 
> Who cares if you spend half a year securing your VOIP backend 
> if you are trusting the web browser of your users to proxy 
> the SQL statements you are using to handle your configuration 
> database?
> 
> Security is a weakest-link problem. I think that many VOIP 
> providers based on old telco knowledge may find themselves 
> with a cultural problem in the future. All of a sudden, 
> integration with a web presence may be a make or break for 
> the company as a whole. I have worked in both areas, and I 
> have no problem imagining a VOIP company controlled by telco 
> throughbreds with blinkers on where a couple of junior people 
> are hired to cobble together a web presence in a couple of hours.
> 
> If that happens, expect to have sql injection vulnerabilities 
> and other trivial web-based exploits en masse.
> 
> People trying to find a weak link will try to find your weak 
> link. If your weak link is not being interested in a certain 
> kind of technology, then that is where the attack will most 
> likely appear.
> 
> Geir
> 
> 
> 
> ------------------------------
> 
> Message: 2
> Date: Sat, 26 Feb 2005 16:31:55 +0800
> From: Simon Horne <security at isvo.net>
> Subject: Re: [VOIPSEC] Actual Attacks
> To: David Vincent <support at sleepdeprived.ca>,voipsec at voipsa.org
> Message-ID: <6.0.0.22.2.20050226163146.02d1e868 at mail.isvo.net>
> Content-Type: text/plain; charset="us-ascii"; format=flowed
> 
> At 02:02 PM 26/02/2005, David Vincent wrote:
> >Brian Rosen wrote:
> >
> >>Are you aware of this actually happening, or is this all theoretic?
> >>
> >>I've never heard of actual incidents of any of this.
> >>
> >>The latter (eavesdropping) is actually the reverse; when we do 
> >>testing, we have to go through all kinds of grief to allow the 
> >>sniffers to get at the packets.  Someone has to actually 
> bring a hub 
> >>(not a switch) so we can sniff the packets.  You can, of 
> course, run 
> >>Etherreal on some of the actual devices.  It's amazingly 
> hard to sniff 
> >>packets in a typical switched architecture.  When we 
> implement CALEA 
> >>(legal wiretap), it takes a special box that we force all 
> the traffic 
> >>to go through so we can copy the packets to the LEA.
> >
> >speaking of eavesdropping, i'd love to hear the community's opinion 
> >about this project:
> >
> >http://www.enderunix.org/voipong/
> 
> With reference to the above product, more than ever vendors 
> have to seriously consider Media Encryption with a Handshake 
> technique which foils these types of "wire taps". Methods 
> such as Single Use Diffie Hellman generated half key pairs 
> (with 1 half encrypted) as used in TLS on a seperate secure 
> channel is an excellent method to stop the "Man in the 
> Middle" from being able to decrypt the voice traffic. They 
> may be able to capture to .wav the contents of the 
> conversation but it would be complete garbage. Each 
> conversation or part of conversations are encrypted 
> differently so the 'tapper' has to use repeated blunt force 
> attacks to access the entire conversation. If a large Diffie 
> Hellman "Prime" length is used (> 1536bits) and a high 
> quality cipher (say AES256), makes it almost impossible for 
> all but the the most serious 'tapper' to access.
> 
> Simon  
> 
> 
> 
> 
> ------------------------------
> 
> Message: 3
> Date: Sat, 26 Feb 2005 15:56:41 +0100 (MET)
> From: Gerald Maguire <maguire at it.kth.se>
> Subject: [VOIPSEC] Re: Voipsec Digest, Vol 2, Issue 33
> To: Voipsec at voipsa.org
> Message-ID: <200502261456.PAA12531 at dumburken.it.kth.se>
> 
> Regarding
>     Date: Fri, 25 Feb 2005 17:31:51 -0500
>     From: "Brian Rosen" <br at brianrosen.net>
>     Subject: RE: [VOIPSEC] Actual Attacks
>     To: "'Mark Teicher'" <mht3 at earthlink.net>,	
> <voipsec at voipsa.org>
>     Message-ID: 
> <mailman.2.1109398021.4428.voipsec_voipsa.org at voipsa.org>
>     Content-Type: text/plain;	charset="us-ascii"
> 
>     Are you aware of this actually happening, or is this all 
> theoretic?
> 
>     I've never heard of actual incidents of any of this.
> 
>     The latter (eavesdropping) is actually the reverse; when 
> we do testing, we
>     have to go through all kinds of grief to allow the 
> sniffers to get at the
>     packets.  Someone has to actually bring a hub (not a 
> switch) so we can sniff
>     the packets.  You can, of course, run Etherreal on some 
> of the actual
>     devices.  It's amazingly hard to sniff packets in a 
> typical switched
>     architecture.  When we implement CALEA (legal wiretap), 
> it takes a special
>     box that we force all the traffic to go through so we can 
> copy the packets
>     to the LEA. 
> 
>     WiFi and your neighbor's cable modem excepted, of course.
> 
>     Brian
> 
> Many switches support the ability to replicate all the 
> traffic to another port, see for example "port mirroring" for 
> HP, Cisco, Foundry Networks, ... switches.
> 
> Regards,
> G. Q. Maguire Jr.
> 
> 
> 
> ------------------------------
> 
> Message: 4
> Date: Sat, 26 Feb 2005 13:35:24 -0500
> From: "Brian Rosen" <br at brianrosen.net>
> Subject: RE: [VOIPSEC] Actual Attacks
> To: <Chris at sip1.com>, "'Geoff Devine'" <gdevine at cedarpointcom.com>,
> 	<Voipsec at voipsa.org>
> Message-ID: <mailman.0.1109462593.31042.voipsec_voipsa.org at voipsa.org>
> Content-Type: text/plain;	charset="us-ascii"
> 
> > How about call diversion or splitting of media to listen to the 
> > conversation? It is a valid feature of SIP to add more endpoints to 
> > the media session (such as conferencing). If a security 
> mechanism is 
> > not in place to prevent the unauthorized form of this it is another 
> > valid (maybe not existing, but there are many bright minds 
> out there) risk.
> Endpoints can tell if a conforming device is connecting them 
> to a conference bridge (the "isFocus" parameter will be 
> present), but of course a non conforming implementation could 
> lie about that.  Of course, this is not really any different 
> from any other telephony system in that you don't really know 
> what the other end is doing with your media.
> 
> Security mechanisms can't help you here.  You can 
> authenticate the endpoint, but if it authenticates, that's 
> it, whether it's keeping the conversation confidential, or 
> podcasting it from some website.  There is no way to cause 
> you to send you media to multiple places at once (well, there 
> are "end system mixed" conference mechanisms, but when those 
> are used, you KNOW that your audio is being sent multiple places).
> 
> > 
> > Or theft of service from the telco... VoIP PSTN gateways 
> for instance 
> > do not require authentication today...unless the carrier implements 
> > concurrent call limiting they could attempt to deploy more VoIP 
> > services bypassing the carrier...Tom wrote some good 
> examples of this.
> Hmmm.  Moat carriers I know control access to the gateway.
> Only calls that arrive via their call server are accepted.  I 
> don't like that answer; I really do want authentication at 
> the gateway, but that particular hole has been plugged on 
> most networks.
> 
> Brian
> 
> 
> 
> 
> 
> 
> ------------------------------
> 
> Message: 5
> Date: Sat, 26 Feb 2005 13:35:24 -0500
> From: "Brian Rosen" <br at brianrosen.net>
> Subject: RE: [VOIPSEC] SNMP support
> 	forEventCorrelation/NetworkManagementSystems
> To: "'Simon Horne'" <security at isvo.net>,	<Voipsec at voipsa.org>
> Message-ID: <mailman.1.1109462593.31042.voipsec_voipsa.org at voipsa.org>
> Content-Type: text/plain;	charset="us-ascii"
> 
> Haha
> "go scream at them for being ... non-compliant"?!
> You can scream all you want, vendors only do things customers ask for.
> RFC3261 requires all things claiming to be SIP to implement TLS.
> Only about 25% do.  They all claim to be compliant.
> 
> If the CUSTOMER demanded security, eventually they get it.
> So far, no demand.
> 
> It's not entirely clear to me that SNMP is really the right thing.
> For one thing, having lots of new elements for the network 
> management system to manage is problematic. Consider for 
> example, that every PC could have SNMP management, but it's 
> really rare to see it used.  The number of elements would 
> probably overwhelm the available management tools.
> 
> I also think that it's too easy to misconfigure SNMP such 
> that it's an easy attack.  And, as we are discovering, USM is 
> hard to deploy.
> 
> There is a SIP MIB.  Deployment is not mandatory.
> 
> Brian
> 
> 
> > -----Original Message-----
> > From: Voipsec-bounces at voipsa.org 
> [mailto:Voipsec-bounces at voipsa.org] 
> > On Behalf Of Simon Horne
> > Sent: Friday, February 25, 2005 10:56 PM
> > To: Voipsec at voipsa.org
> > Subject: RE: [VOIPSEC] SNMP support
> > forEventCorrelation/NetworkManagementSystems
> > 
> > At 05:25 AM 26/02/2005, Mark Teicher wrote:
> > >The end point may incorporate it, then the .mib file will 
> have either 
> > >adhere to ASN.1 standards or not.  After that, the various 
> NMS/Event 
> > >Management systems have to incorporate it into their basic 
> package or
> > have
> > >a 3rd party SNMP compiler that allows for errors that vendors may 
> > >insert into their .mib.  I ran into this problem a few 
> weeks ago with 
> > >a vendor adhering to the SNMP standard but the .mib still 
> had errors 
> > >during compilation for a common NMS system.
> > >
> > >The last I pinged either, there has been finger pointing in the 
> > >various directions and the VOIP vendor has stated, "hey we 
> don't have 
> > >time to fix it, we are to busy working on our next release "
> > 
> > For H323 (due to the language I assume so) there is a 
> standard H.341 
> > for SNMP support. In fact a range of standard .mib files 
> for H.341 are 
> > available for free from the ITU website. If they're not 
> using them (or 
> > can't read them) then they are technically non-compliant 
> for H323. You 
> > can go scream at them for being H323 SNMP non-compliant and 
> watch them 
> > jump :)
> > 
> > Simon
> > 
> > 
> > _______________________________________________
> > Voipsec mailing list
> > Voipsec at voipsa.org
> > http://voipsa.org/mailman/listinfo/voipsec_voipsa.org
> > 
> 
> 
> 
> 
> 
> 
> ------------------------------
> 
> Message: 6
> Date: Sat, 26 Feb 2005 13:35:24 -0500
> From: "Brian Rosen" <br at brianrosen.net>
> Subject: RE: [VOIPSEC] VoIP and Fraud
> To: <Chris at sip1.com>, "'Mark Fletcher'" <fletch at nortel.com>,	"'Mahesh
> 	Thakkar'" <maheshthakkar at gmail.com>, <Voipsec at voipsa.org>
> Message-ID: <mailman.2.1109462593.31042.voipsec_voipsa.org at voipsa.org>
> Content-Type: text/plain;	charset="us-ascii"
> 
> For calls within a domain, such as those within one carrier, 
> there is P-Asserted-Identity, that allows the carrier to 
> assert the CallerId.  The general answer is Jon Peterson's 
> Identity draft, which works on the Internet.
> 
> Non repudiation is another story.  No work on that yet.
> 
> Brian
> 
> > -----Original Message-----
> > From: Voipsec-bounces at voipsa.org 
> [mailto:Voipsec-bounces at voipsa.org] 
> > On Behalf Of Christopher A. Martin
> > Sent: Friday, February 25, 2005 7:31 PM
> > To: 'Mark Fletcher'; 'Mahesh Thakkar'; Voipsec at voipsa.org
> > Subject: RE: [VOIPSEC] VoIP and Fraud
> > 
> > The caller id spoof thread here is one that I missed... 
> Carriers can 
> > prevent this, but the end to end potential of VoIP makes it 
> hard, this 
> > is definitely an area to look into. It still boils down to 
> needing a 
> > method for non-repudiation for VoIP.
> > 
> > Christopher A. Martin
> > P.O. Box 1264
> > Cedar Hill, Texas 75106
> > Chris at InfraVAST.com
> > 
> > > -----Original Message-----
> > > From: Voipsec-bounces at voipsa.org 
> [mailto:Voipsec-bounces at voipsa.org] 
> > > On Behalf Of Mark Fletcher
> > > Sent: Monday, February 14, 2005 7:28 PM
> > > To: 'Mahesh Thakkar'; 'Voipsec at voipsa.org'
> > > Subject: RE: [VOIPSEC] VoIP and Fraud
> > >
> > > Mahesh,
> > >
> > > There are many potential areas, but one that concerns me is the 
> > > ability for a user to easily spoof their Caller ID. 
> Typically this 
> > > has only been available to administrators of a PBX with PRI 
> > > circuits. Many call this 'security via obscurity'. By 
> spoofing CLID, 
> > > a caller could raise havoc with Emergency Services and 
> the national 
> > > E9-1-1 system, or use a spoofed CLID to socially engineer people 
> > > into giving up personal information.
> > >
> > > Mark J. Fletcher
> > > Sr. Systems Engineer
> > >
> > > Office: 973-285-5745 (ESN 287-5745)
> > > Mobile: 973-919-6144
> > > SIP/Email: fletch at nortel.com <mailto:fletch at nortel.com> 
> Visit Nortel 
> > > on the web at http://nortel.com <http://nortel.com/>
> > >
> > > PLEASE NOTE NEW EMAIL ADDRESS:  <mailto:Fletch at Nortel.com> 
> > > Fletch at Nortel.com
> > >
> > >
> > >
> > >
> > >
> > > "This e-mail and any files transmitted with it are the property of
> > Nortel
> > > Networks Inc., are confidential, and are intended solely 
> for the use 
> > > of the individual or entity to whom this e-mail is 
> addressed. If you 
> > > are not
> > one
> > > of
> > > the named recipient(s) or otherwise have reason to 
> believe that you 
> > > have received this message in error, please notify the sender at 
> > > 973.285.5745 and delete this message immediately from 
> your computer. 
> > > Any other use, retention, dissemination, forwarding, printing, or 
> > > copying of this e-
> > mail
> > > is
> > > strictly prohibited."
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: Voipsec-bounces at voipsa.org 
> [mailto:Voipsec-bounces at voipsa.org
> > > <mailto:Voipsec-bounces at voipsa.org> ] On Behalf Of Mahesh Thakkar
> > > Sent: Sunday, February 13, 2005 3:33 AM
> > > To: Voipsec at voipsa.org
> > > Subject: [VOIPSEC] VoIP and Fraud
> > >
> > >
> > > Dear All,
> > >
> > > I am new to VoIP, but not to communication. I am in 
> telecom for the 
> > > last
> > 7
> > > years (GSM) and looking after Revenue Assurance and 
> Fraud. I would 
> > > like
> > to
> > > know what are the vulnerabilities of VoIP and loop holes 
> for fraud 
> > > in practical day to day business and how one can protect or be 
> > > prepared to act against VoIP fraud.
> > >
> > > Responses are highly appreciated
> > >
> > > --
> > > Mahesh Thakkar
> > >
> > > _______________________________________________
> > > Voipsec mailing list
> > > Voipsec at voipsa.org 
> > > http://voipsa.org/mailman/listinfo/voipsec_voipsa.org
> > > <http://voipsa.org/mailman/listinfo/voipsec_voipsa.org>
> > >
> > >
> > 
> > 
> > 
> > _______________________________________________
> > Voipsec mailing list
> > Voipsec at voipsa.org
> > http://voipsa.org/mailman/listinfo/voipsec_voipsa.org
> > 
> 
> 
> 
> 
> 
> 
> ------------------------------
> 
> Message: 7
> Date: Sat, 26 Feb 2005 13:44:22 -0500
> From: "Brian Rosen" <br at brianrosen.net>
> Subject: RE: [VOIPSEC] Re: Voipsec Digest, Vol 2, Issue 33
> To: "'Gerald Maguire'" <maguire at it.kth.se>,	<Voipsec at voipsa.org>
> Message-ID: <mailman.3.1109462593.31042.voipsec_voipsa.org at voipsa.org>
> Content-Type: text/plain;	charset="us-ascii"
> 
> I think we can all agree that if you have access to the 
> switch management system, you can eavesdrop.  If you have 
> physical access to the switch, you can eavesdrop.  In 
> general, these are characteristics of all networks.
> The former can be improved by following good practice on 
> control of passwords.  ACL use, in particular, if deployed, 
> can avoid the "all network admins know the common management 
> password" problem.
> Of course, this doesn't have anything specifically to do with 
> VoIP, but as many of us know, it's one of the most common 
> internal security issues.
> 
> Brian
> 
> > -----Original Message-----
> > From: Voipsec-bounces at voipsa.org 
> [mailto:Voipsec-bounces at voipsa.org] 
> > On Behalf Of Gerald Maguire
> > Sent: Saturday, February 26, 2005 9:57 AM
> > To: Voipsec at voipsa.org
> > Subject: [VOIPSEC] Re: Voipsec Digest, Vol 2, Issue 33
> > 
> > Regarding
> >     Date: Fri, 25 Feb 2005 17:31:51 -0500
> >     From: "Brian Rosen" <br at brianrosen.net>
> >     Subject: RE: [VOIPSEC] Actual Attacks
> >     To: "'Mark Teicher'" <mht3 at earthlink.net>,	
> <voipsec at voipsa.org>
> >     Message-ID: 
> <mailman.2.1109398021.4428.voipsec_voipsa.org at voipsa.org>
> >     Content-Type: text/plain;	charset="us-ascii"
> > 
> >     Are you aware of this actually happening, or is this 
> all theoretic?
> > 
> >     I've never heard of actual incidents of any of this.
> > 
> >     The latter (eavesdropping) is actually the reverse; when we do 
> > testing, we
> >     have to go through all kinds of grief to allow the 
> sniffers to get 
> > at the
> >     packets.  Someone has to actually bring a hub (not a 
> switch) so we 
> > can sniff
> >     the packets.  You can, of course, run Etherreal on some 
> of the actual
> >     devices.  It's amazingly hard to sniff packets in a 
> typical switched
> >     architecture.  When we implement CALEA (legal wiretap), 
> it takes a 
> > special
> >     box that we force all the traffic to go through so we 
> can copy the 
> > packets
> >     to the LEA.
> > 
> >     WiFi and your neighbor's cable modem excepted, of course.
> > 
> >     Brian
> > 
> > Many switches support the ability to replicate all the traffic to 
> > another port, see for example "port mirroring" for HP, 
> Cisco, Foundry 
> > Networks, ... switches.
> > 
> > Regards,
> > G. Q. Maguire Jr.
> > 
> > _______________________________________________
> > Voipsec mailing list
> > Voipsec at voipsa.org
> > http://voipsa.org/mailman/listinfo/voipsec_voipsa.org
> > 
> 
> 
> 
> 
> 
> 
> ------------------------------
> 
> Message: 8
> Date: Sat, 26 Feb 2005 17:02:57 -0500
> From: "Stauffer Michael" <stauffer_michael at bah.com>
> Subject: RE: [VOIPSEC] Actual Attacks
> To: <voipsec at voipsa.org>
> Message-ID:
> 	
> <D45FDF40523EAB4FB089C71067A4BBEA173D69 at MCLNEXVS04.resource.ds
> .bah.com>
> 	
> Content-Type: text/plain;	charset="iso-8859-1"
> 
> Many switches support the ability to replicate all the 
> traffic to another port, see for example "port mirroring" for 
> HP, Cisco, Foundry Networks, ... switches.
> 
>  
> This is true, but this "port spanning" "port mirroring" 
> functionality has to be specifically configured.  In an 
> infrastructure where switch components are at least password 
> protected at the priveleged level, sniffing other 
> conversations is not that simple.  There used to be 
> gratuitous ARP tricks, and flooding with thousands of fake 
> MACs to get the switch to basically "fail open", but switch 
> manufacturers have added security mechanisms to thwart most 
> of these.  Now whether they are utilized or not, that's 
> another matter, but in an infrastructure where at least basic 
> layer 2 security mechanisms are in place, and where the 
> components are password protected, etc, etc, it's really a 
> pain to sniff switced traffic.   In the lab, where I have 
> control over the switches, it's really quite easy.
>  
> Mike Stauffer
> 
> 
> ------------------------------
> 
> _______________________________________________
> Voipsec mailing list
> Voipsec at voipsa.org
> http://voipsa.org/mailman/listinfo/voipsec_voipsa.org
> 
> 
> End of Voipsec Digest, Vol 2, Issue 36
> **************************************
> 