Synopsis:  Blue Box #83: SIP and Asterisk vulnerabilities, voice biometrics, P2PSIP, Aircell blocking Skype, VoIP security news and more…

Welcome to Blue Box: The VoIP Security Podcast #83, a 39-minute podcast  from Dan York and Jonathan Zar covering VoIP security news, comments and opinions.   

Download the show here (MP3, 18MB) or subscribe to the RSS feed to download the show automatically. 

NOTE: This show was recorded on September 4, 2008.

You may also listen to this podcast right now:

Show Content:

• 00:20 - Intro to the show, contact information and how to provide comments.  Welcome to all the new listeners - and to all those listeners who have been here for so long!
• Programming notes:
  • Three-year anniversary of Blue Box coming up on October 24th - any thoughts you'd like to share with us? (Please send them to us by October 23rd.)
• Remote DoS in reSIProcate
• Remote root shell in Trixbox
• Second route of VoIPShield Cisco/Avaya/Nortel vulnerabilities
• AST-2008-010 – IAX2 ‘POKE’ Resource Exhaustion
• AST-2008-011 – IAX2 Firmware Provisioning System
• Saunderslog: Squawk Box – July 10, 2008: Voice biometrics and VoiceVerified.com
• Saunderslog: Squawk Box – July 9, 2008: P2PSIP
• IETF: P2PSIP Security Requirements
• Voice of VOIPSA: “Aircell blocking VoIP on a plane” – part 1 , part 2 and an update
• Voice of VOIPSA: Shawn Merdinger’s series on “Asking The Cisco IPICS Expert” – Questions 1-5 – 6-10 – 11-15 – 16-20 – 21-25
• Voice of VOIPSA: Asterisk ‘hack’ to show blocked Caller-ID points to larger trust issues with SIP (and SpeechTEK speech)
• NetworkWorld: Georgia student arrested for hacking grades, VoIP
• CRN: Analysis: Hacking VoIP as easy as 1-2-3
• Ari Takanen starts blogging at InfoWorld
• InfoWorld: Motivation for VoIP Fuzzing
• TMCnet: How to keep your tech career afloat
• New analyst report: Security Threats Loom Over Unified Communications pointing to Light Reading report and article
• VoIP Companies to Fight For Market Share
• IEEE approves 802.11r standard
• Google Chrome – upgrading the web to be application-centric
• Items on my DisruptiveTelephony blog… Skype 5th birthday, Asterisk future, Digium/Nortel
• No comments this week.
  
• Review of the last week's traffic on the VOIPSEC public mailing list
  
• Wrap-up of the show
  
• 39:08 - End of show 

Comments, suggestions and feedback are welcome either as replies to this post  or via e-mail to blueboxpodcast@gmail.com.  Audio comments sent as attached MP3 files are definitely welcome and will be played in future shows.  You may also call the listener comment line at either +1-415-830-5439 or via SIP to 'bluebox@voipuser.org' to leave a comment there. 

Thank you for listening and please do let us know what you think of the show.

Depending on who you talk to, he is:

a) a hero

b) a disgruntled worker

c) in need of a serious work/life adjustment

d) in need of $5 million and/or a better lawyer

e) all of the above

Surprisingly strong opinions, regardless of what you choose.

We chose to lighten things up a bit and, as we always try to do, figure out how to help our customers be proactive. So here it is, the Top 10 Signs Your Network Admin has Gone Rogue:

10) David Letterman has a Top 10 list called “Top 10 Signs Your Network Admin Has Gone Rogue”

9) Your Admin is the only one with the network device log-ins and refuses to share them with anyone else.

‘8) His presentations about network configuration include the words “Magic” and “Burn after reading”.

7) Instead of email, he forces everyone to use the Suggestion box placed outside of his door…and then places a very obvious nanny-cam hidden in a teddy bear right next to it.

6) He begins to grow out his sideburns and every question directed to him in meetings results in the same response, “Do you feel lucky today, punk?”

5) He has the mayor on speed-dial.

4) He starts wearing very big shoes to the office and accosts random people in the hallways asking if they think they could fill them.

3) He refuses to write router and switch configs to flash citing network security concerns.

2) He calls you and asks for a $5 million salary advance; caller id flashes “Department of Corrections”.

And #1: You’re the City of San Francisco

Enjoy your lock-down free weekend!

ShareThis

Image via Wikipedia

Much has been written lately about annoying sales tactics and how many in the security field try to duck vendor calls.  Believe it or not, I get my share of annoying sales calls as well.  Whether it is the great conference that is being organized with all of the CIOs that I would ever want to speak to or the latest, greatest new product that is going to make my life easier and define the road to riches, I am swamped with spam telephone calls (on my cell phone no less) every day. 

One thing that I have come to see is that many of these unsolicited calls come in with an unknown caller ID. I don't mean no name for entity, but no number either.  Most of these people don't leave a voice mail either, they just keep calling until the get an answer.  My view is that if the caller has to go to the effort of hiding their name and number, than they have something to hide and are not being upfront.  I don't want to do business with anyone like that. I think this just puts two strikes against anyone calling.  Why are you hiding who you are?  Are you ashamed of what you are doing?

So here is my Shimel rule on sales calls. If your caller ID does not identify you, than I don't want to talk to you!

Image via Wikipedia

Much has been written lately about annoying sales tactics and how many in the security field try to duck vendor calls.  Believe it or not, I get my share of annoying sales calls as well.  Whether it is the great conference that is being organized with all of the CIOs that I would ever want to speak to or the latest, greatest new product that is going to make my life easier and define the road to riches, I am swamped with spam telephone calls (on my cell phone no less) every day. 

One thing that I have come to see is that many of these unsolicited calls come in with an unknown caller ID. I don't mean no name for entity, but no number either.  Most of these people don't leave a voice mail either, they just keep calling until the get an answer.  My view is that if the caller has to go to the effort of hiding their name and number, than they have something to hide and are not being upfront.  I don't want to do business with anyone like that. I think this just puts two strikes against anyone calling.  Why are you hiding who you are?  Are you ashamed of what you are doing?

So here is my Shimel rule on sales calls. If your caller ID does not identify you, than I don't want to talk to you!

A dozen pieces of gold jewelry designed by prominent Canadian artist Bill Reid were stolen from the museum sometime on May 23, along with three pieces of gold-plated Mexican jewelry. The pieces that were taken are estimated to be worth close to $2 million.

Of course, it's not the museum's fault:

But museum director Anthony Shelton said that elaborate computer program printouts have determined that the museum's security system did not fail during the heist and that the construction of the building's layout did not compromise security.

Um, isn't having stuff get stolen the very definition of security failing? And does anyone have any idea how "elaborate computer program printouts" can determine that security didn't fail? What in the world is this guy talking about?

A few days later, we learned that security did indeed fail:

Four hours before the break-in on May 23, two or three key surveillance cameras at the Museum of Anthropology mysteriously went off-line.

Around the same time, a caller claiming to be from the alarm company phoned campus security, telling them there was a problem with the system and to ignore any alarms that might go off.

Campus security fell for the ruse and ignored an automated computer alert sent to them, police sources told CBC News.

Meanwhile surveillance cameras that were still operating captured poor pictures of what was going on inside the museum because of a policy to turn the lights off at night.

Then, as the lone guard working overnight in the museum that night left for a smoke break, the thief or thieves broke in, wearing gas masks and spraying bear spray to slow down anyone who might stumble across them.

It's a particular kind of security failure, but it's definitely a failure.

.text:00405C1B mov  esi, [ebp+dwLen]  ; Our value from packet
...
.text:00405C20 push edi
.text:00405C21 test esi, esi          ; Check value != 0
...
.text:00405C31 push esi               ; Alloc with our length
.text:00405C32 mov  [ebp+var_4], 0
.text:00405C39 call operator new(uint); Big values return NULL
.text:00405C3E mov  ecx, esi          ; Memcpy with our length
.text:00405C40 mov  esi, [ebp+pDestionationAddr]
.text:00405C43 mov  [ebx+4], eax      ; new result is used as dest
.text:00405C46 mov  edi, eax          ; address without checks.
.text:00405C48 mov  eax, ecx
.text:00405C4A add  esp, 4
.text:00405C4D shr  ecx, 2
.text:00405C50 rep  movsd             ; AV due to invalid
.text:00405C52 mov  ecx, eax          ; destination pointer.
.text:00405C54 and  ecx, 3

Dave asserts that publishing 16 commented assembly instructions makes this disclosure irresponsible. But look at the code — it’s completely generic, just a textbook example of what it looks like when you forget to check a return value after calling operator new. Sure, Core gives you the exact offsets into the executable, but so what? If I have the binary, then it’s not going to be too hard to find the vulnerability anyway. It’s not like Core is giving away a proof-of-concept exploit that generates the malformed registration packet required to trigger the DoS. What’s more, they provide a detailed timeline going back to January 30th of this year describing exactly how the disclosure process with the vendor transpired. This looks extremely responsible to me; I just can’t understand what is “not cool” here.

There’s another interesting angle to this, completely unrelated to Core’s disclosure process. The vulnerability itself is described in the advisory as follows:

Un-authenticated client programs connecting to the service can send a malformed packet that causes a memory allocation operation (a call to new() operator) to fail returning a NULL pointer. Due to a lack of error-checking for the result of the memory allocation operation, the program later tries to use the pointer as a destination for memory copy operation, triggering an access violation error and terminating the service.

This may bring to mind some recent discussions on whether callers of memory allocation functions should check the return value prior to use. To summarize, one camp says “caller should check”, the other camp says “callee should exit on allocation failure.” This is a gross oversimplification and if you want more detailed arguments, read the other blog posts that I linked to. In this case, if the “exit on failure” approach were taken, the DoS scenario might still happen, whereas if the caller were checking, the error could be handled more gracefully. More fuel for the debate!

• Developing procedures to ensure that access to Stryker's network will be disabled immediately upon an employee's termination;
• Developing a procedure to review service accounts and change passwords;
• Eliminating potential gaps in Stryker's current internal audit system;
• Requiring two-factor authentication for all remote network access;
• Disabling one of Stryker's existing VPNs and moving all users to a single, more secure VPN; and
• Implementing a system of consolidating and monitoring user log files for potential security breaches.