[SecurityRatty] tag: vendors

Blue Box #82: Asterisk & Skype security vulnerabilities, new VoIP security tools, VoIP steganography, VoIP security news and much, much more...

Wed, 27 Aug 2008 15:53:18 +0000

Synopsis: Blue Box #82: Asterisk & Skype security vulnerabilities, new VoIP security tools, VoIP steganography, VoIP security news and much, much more...

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

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

NOTE: This show was originally recorded on June 21, 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:
- Note about the production team – new special editions coming soon.
- Note about URLs for the media files
AST-2008-008 – Remote Crash Vulnerability in SIP channel driver when run in pedantic mode
AST-2008-009 – Remote crash vulnerability in ooh323 channel driver
Skype-SB-2008-003 – Skype File URI Security Bypass Code Execution Vulnerability

New version of SIPvicious

Sipflanker – tool to find SIP devices with web GUIs

Discussion about VoIP Steganography (pointed to by Craig Bowser)

Geeks Are Sexy: New Technology Hides Messages in Internet Phone Calls – and Switched: Spies to Use Skype to Send Secret Messages? – and The Register

FierceVoIP: VoIP Security and the Circle of Trust pointing to Government Computer News: Careful with the call

The Register: ‘Untraceable’ phone fraudsters eye your credit card

SearchUnifiedCommunications: Disaster and recovery in the VoIP/IPT RFP

Secure Computing: Voice tools under enemy fire

VNUnet: A good VoIP application is worth paying for

Ofcom confirms VoIP providers must provide access to 999 and 112

Bogdan Materna’s blog is live

Realtime Community: The Essentials Series:
Messaging and Web Security
Volume III

Global Knowledge: On-Demand Webinar on VoIP Security (hat tip to Thomas Lee )

SearchSecurity: The threats to telcos and how they can repel them

TMCnet: Balancing Issues in World of Telepresence

Network World: VoIP Security Buying Guide

Nortel and SecureLogix Team to Deliver Voice Security and Management Solutions to Worldwide Enterprise Market (see also this analysis )

Sipera Partner Network Arms Resellers With Comprehensive UC and VoIP Security

VIVOphone Deploys Paradial RealTunnel® to Solve NAT Traversal Challenges for VoIP Services

Audiocodes joins the ranks of SBC vendors

SearchSecurity: Securing the new network (interesting because it shows the layers of a defense in depth)

The Hindu Business News: Serious about Security

Shows:
- IP Telephony University – June 23-24, Alexandria, VA
- IPTComm 2008 – July 1-2, Heidelberg, Germany
- The Last H.O.P.E. – July 18-20, New York
- SpeechTek – August 18-20, New York
Call for papers for Hack-in-the-box Malaysia ends June 30th

SchmooCon 2008 videos available – several dealing with VoIP

No comments this week.
Review of the last week's traffic on the VOIPSEC public mailing list

Wrap-up of the show

47:09 - 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.

CEP is Not BPM, BAM, BRE, BRMS or SOA

Wed, 27 Aug 2008 09:37:25 +0000

A post in Technology content of current CEP products? reminds me of why I rarely, if ever, agree with anything that comes out of Aleri’s marketing team. To fair to Jeff, it is not only Aleri but others, who continually misdefine business process management (BPM) as CEP.

Jeff uses the example, “Smart Order Routing” as an example of taking an event and routing the resulting market order match based on some simple rules. Routing a order kicked off by a simple order match against a deep liquidity pool (or other market factor) does not define complex event processing nor detecting a complex event - the core idea behind CEP. Order routing based on simple rules is BPM, plain and simple.

Let’s take another example, fraud. In this example, there is some complex neural network monitoring for credit card fraud and a potential fraud is detected - this is CEP, detecting a complex event based on some sophisticated analytics.

After a possible fraud has been detected, a process looks into a database and the routes the incident to someone in the company who is a (1) specialist in credit card fraud, (2) working at the same time of the discovered threat, and (3) immediately available to act on this type of task. Routing the incident is not CEP, it is BPM.

Jeff makes the argument that it is OK to call an event-driven BPM task CEP because “it fits the EPTS definition” in the CEP glossary. He also avoids the discussion of detection accuracy, and instead insists that latency is a ”very important” factor in a CEP application.

If you read the various post by vendors in the blog-o-sphere, it is obvious that they are continually defining CEP as BAM, BPM, BRE, BRMS, SOA and just about every other related processing activity that is complimentary to the event correlation and analysis required to detect an opportunity or threat to your business.

I’m not picking on Aleri. TIBCO has been doing the same thing recently in their CEP blog, continually attempting to redefine CEP as BRMS. Detecting business opportunities and threats with high confidence requires sophisticated analytics, and their tools have not yet evolved to “real CEP” capabilities. Instead, vendors are attempting to redefine BPM, BRMS, BRE, and even SOA to some degree, as CEP.

CEP is Not BPM, BAM, BRE, BRMS or SOA.

Thoughts on Token Security

Tue, 26 Aug 2008 12:35:23 +0000

RSnake has a piece up on Token Security which raises some good points, but also misses some perspective. Firstly any article that makes a serious attempt at mitigating FUD is most welcome, especially in a space that is as overloaded as identity. That said, I think RSnake is taking too narrow of a view, specifically B2C, on federation and tokens. It is true that works on the web eventually filters into the enterprise, but it is also true that sometimes that things that start out as enterprise technologies later become cost effective on the web. So I would not assume that the current status quo on the web will hold. I don't think it will, the identity problems are too big and there is too much money at stake.

I encourage you to read his article, here are some of my thoughts

"consumers hate tokens."

Except that people use atm cards every day. Consumers will absolutely be inconvenienced, if there is some value created. The problem today is not the token, its the lack of a value proposition to the person you are inconveniencing.

"Everyone wants to be the single federation platform for everyone else."

This will never work. and that's a good thing. i think most companies already realize this though. I think the walled garden model has gone the way of the dodo.

"Federation will never work. It won’t work because the single most important consumer Web applications in the world are scared of it. Banks hate the concept because it becomes a weakest link in the chain problem."

Federation works quite well. have a look at google for one example. The reason banks hate federation is that their infosec people have a mainframe mindset, they are focused only on resource protection. the problem is they dont run mainframes on closed networks, they went and connected it to the web and so now they need to think about subject and claim security not just resource security. its not hatred its a lack of understanding stemming from a legacy mindset.

Linking up identity providers and relying parties into a federation has been a solved problem for quite some time.

"Tokens don’t actually solve most security problems, like man-in-the-middle, phishing, and keystroke-logging malware."

Rule 1. there are no silver bullets in security

Rule 2. dont forget rule 1

but...

...there is a rule 3

rule 3. just because a security mechanism doesnt solve all of our problems doesnt mean its worthless.

I see this with security consultants all the time, they playa hate on static analysis or some scanning tool where they can find hundreds of things the tool doesn't. Fair point except 99.9999% of IT can't and won't find them. Engineering is about solving one incremental problem at a time.

"Oh yes, and finally, consumers are going to have to carry around 13 of them just to make sure they can log into whatever they need to log into since no one will federate."

This misses the point of federation. i carry around one atm card its up to banks, Visa, Cirrus and so on to make sure i get my cash. the funny thing about banks not understanding federation is that they have the bet example right in front of their noses, the problem is its in a different department so they never see it.

"Global federation is nowhere near a solid concept in the consumer space, despite what the vendors will try to sell you."

rule 4. do your own due diligence

Tokens and federation are important building blocks for our digital future. I will leave you with a story that Robert Morris Sr. told at Defcon several years ago:

"This is a long term problem. If you work on it and make any progress against it, you'll find yourself much smarter at the far end, than you were at the near end.

When I was in Norway about 5 years ago, I was there very close to the summer solstice. I was wandering around town at 2 o'clock in the morning and there was plenty of light out. You come to a sign that says New Minsk about 60 km and it points south.

And I ask the lady "what country is this?"

She scratched her head for a bit, and said "well I think its Norway"

I said "well who plows the roads?"

"well Norway does, but he have to pay them."

There is a triple boundary in this town that I was in between Norway, Finland and Russia.

But what I did there, was, I had a card about wallet size, I stuck it into a machine, I punched in four digits, and it gave me about 2,000 krone, whatever the hell that is.

Now there are a lot of participants in that transaction. When I put a card into that machine, punch in a pin, and it gurgles for awhile, and finally gives me, a fairly large amount of money. There are a lot of participants in that transaction. The bank that owned the machine that gave me the money, it gave some money away -- that bank wants it back. The pin is necessary to convince my own bank that I'm me. But I don't want my pin to be broadcast all over the world. My bank in the us, it hasn't really given out or taken in any money, really. But there is a lot of credits involved here. Somebody needs to charge somebody else for having more money available. Even though there was actually no cash transfer.

And the problem that I have in mind is
- who are all the participants in an ATM transaction?
- what do those participants need to satisfy their problems?
- how is that in fact done?

In a general way, does the atm system actually work in some reasonable sense? To which the answer is by the way: yes. The atm system damn well works. With extremely high reliability and accuracy. It surprises me. Its quite a bit different than voting machines.

Magic Quadrant for IT Event Correlation and Analysis, 2007

Tue, 26 Aug 2008 11:04:05 +0000

I often get asked that if the current self-decribed CEP vendors are not doing “real CEP,” in my opinon, who are the vendors in the CEP space?

At the moment, event correlation and event analysis is Gartner’s closest magic quadrant (MQ) that relates directly to complex event processing (and event processing in general).

A number of our friends and colleagues would like to position CEP as BRE, BRMS, BPM, SOA, algo trading and just about every other technology under the sun, except event correlation!

In a nutshell, the state-of-the-state of CEP/EP is that a number of firms in the software industry have found some “uncharted magic quadrant waters” and are positioning themselves to be “chart worthy”. Instead of competing head on with the experienced players (event correlation and analysis) that have been in the event processing field for many years.

As I have mentioned a few times here on The CEP Blog, if the current generation self-described CEP engines were leading the industry in event correlation and analysis (CEP’s core technology domain) they would be either be on Gartner’s Magic Quadrant for IT Event Correlation and Analysis, or possibly acquired by a one of these large giants in event processing to solve complex event processing and event correlation problems that remain, for the most part, still unsolved!

Full Disclosure and the Boston Farecard Hack

Tue, 26 Aug 2008 02:04:49 +0000

In eerily similar cases in the Netherlands and the United States, courts have recently grappled with the computer-security norm of "full disclosure," asking whether researchers should be permitted to disclose details of a fare-card vulnerability that allows people to ride the subway for free.

The "Oyster card" used on the London Tube was at issue in the Dutch case, and a similar fare card used on the Boston "T" was the center of the U.S. case. The Dutch court got it right, and the American court, in Boston, got it wrong from the start -- despite facing an open-and-shut case of First Amendment prior restraint.

The U.S. court has since seen the error of its ways -- but the damage is done. The MIT security researchers who were prepared to discuss their Boston findings at the DefCon security conference were prevented from giving their talk.

The ethics of full disclosure are intimately familiar to those of us in the computer-security field. Before full disclosure became the norm, researchers would quietly disclose vulnerabilities to the vendors -- who would routinely ignore them. Sometimes vendors would even threaten researchers with legal action if they disclosed the vulnerabilities.

Later on, researchers started disclosing the existence of a vulnerability but not the details. Vendors responded by denying the security holes' existence, or calling them just theoretical. It wasn't until full disclosure became the norm that vendors began consistently fixing vulnerabilities quickly. Now that vendors routinely patch vulnerabilities, researchers generally give them advance notice to allow them to patch their systems before the vulnerability is published. But even with this "responsible disclosure" protocol, it's the threat of disclosure that motivates them to patch their systems. Full disclosure is the mechanism (.pdf) by which computer security improves.

Outside of computer security, secrecy is much more the norm. Some security communities, like locksmiths, behave much like medieval guilds, divulging the secrets of their profession only to those within it. These communities hate open research, and have responded with surprising vitriol to researchers who have found serious vulnerabilities in bicycle locks, combination safes (.pdf), master-key systems and many other security devices.

Researchers have received a similar reaction from other communities more used to secrecy than openness. Researchers -- sometimes young students -- who discovered and published flaws in copyright-protection schemes, voting-machine security and now wireless access cards have all suffered recriminations and sometimes lawsuits for not keeping the vulnerabilities secret. When Christopher Soghoian created a website allowing people to print fake airline boarding passes, he got several unpleasant visits from the FBI.

This preference for secrecy comes from confusing a vulnerability with information about that vulnerability. Using secrecy as a security measure is fundamentally fragile. It assumes that the bad guys don't do their own security research. It assumes that no one else will find the same vulnerability. It assumes that information won't leak out even if the research results are suppressed. These assumptions are all incorrect.

The problem isn't the researchers; it's the products themselves. Companies will only design security as good as what their customers know to ask for. Full disclosure helps customers evaluate the security of the products they buy, and educates them in how to ask for better security. The Dutch court got it exactly right when it wrote: "Damage to NXP is not the result of the publication of the article but of the production and sale of a chip that appears to have shortcomings."

In a world of forced secrecy, vendors make inflated claims about their products, vulnerabilities don't get fixed, and customers are no wiser. Security research is stifled, and security technology doesn't improve. The only beneficiaries are the bad guys.

If you'll forgive the analogy, the ethics of full disclosure parallel the ethics of not paying kidnapping ransoms. We all know why we don't pay kidnappers: It encourages more kidnappings. Yet in every kidnapping case, there's someone -- a spouse, a parent, an employer -- with a good reason why, in this one case, we should make an exception.

The reason we want researchers to publish vulnerabilities is because that's how security improves. But in every case there's someone -- the Massachusetts Bay Transit Authority, the locksmiths, an election machine manufacturer -- who argues that, in this one case, we should make an exception.

We shouldn't. The benefits of responsibly publishing attacks greatly outweigh the potential harm. Disclosure encourages companies to build security properly rather than relying on shoddy design and secrecy, and discourages them from promising security based on their ability to threaten researchers. It's how we learn about security, and how we improve future security.

This essay previously appeared on Wired.com.

EDITED TO ADD (8/26): Matt Blaze has a good essay on the topic.

Open Letter to Verizon Wireless

Mon, 25 Aug 2008 11:43:00 +0000

After receiving no support from agents at the Verizon Wireless store or by agents on the phone, I decided to write them and make it an open letter. It’s no secret that Verizon has a great network, but it’s also no secret that their phone selection stinks. I don’t want to leave them and am hoping that whatever little bad press I can cause will encourage them to resolve the issue. If not, I’m tapping out. For 3 years I have hated my phone and loved their network. I’m ready to feel mediocre about both. Here it goes:

I am currently without a phone and would appreciate a speedy reply.

I have been a Verizon Wireless customer for over 5 years and my monthly bill easily averages over $200 during that time frame. While I love your network, I have been completely unsatisfied by your selection of phones. It is a stretch to say that my last phone worked—it had a feature called a battery that allowed me to switch from the car charger to my office charger without dying. And I waited—under duress—until I was allowed to purchase a new phone with the discount.

My current phone has a wonderful battery life, but this is the 4th time the charger has snapped off in the phone. The phone is fine, but I keep paying $30 for new chargers. I refuse to purchase another or wait until February when I will be eligible for a new phone. You sold a phone with a design flaw, and I’m not even asking for a refund or a free phone. Just allow me to take a chance on a new one at the 2 year contract renewal rate.

If not, I will gladly pay the early termination fee and leave Verizon. On general principle, I will spend more money canceling my account with you than I would likely receive as a discount on a new phone. As a customer, I consider it unacceptable that you sell inferior phones and leave me with no recourse.

The first time I waited haplessly to become eligible for a new phone. I will not suffer a second time. If you don’t like the fact that you will end up losing money by allowing me to purchase a new phone early, I suggest you take it up your vendors who supply you with awful products. I can promise you that we will both lose more money if you don’t.

Sincerely,

Eric Marvets

Hansei-Kaizen & Risk Management Practices

Mon, 25 Aug 2008 11:13:10 +0000

You might consider this a follow on to the Deming in Risk Management series I did this spring.

Recently, Thinking Problem Management wrote on the concept of Hansei-Kaizen. That started me thinking about Information Risk Management, Information Security, the role of the security group and the analytical function. The following isn’t necessarily a revelation, but as I’ve a friend interviewing for a CISO-type job at a Fortune 20 this week and they are focused on a not dissimilar business management philosophy, I thought I’d write a little about the subject.

Hansei-Kaizen is the process of relentless reflection (Hansei) and continuous improvement (Kaizen). It might be thought of as part of the Deming Plan, Do, Check, Act cycle. In fact, Taiichi Ohno, father of Toyota’s production system (Lean Manufacturing) is quoted as saying: “Check (in PDCA) is Hansei”.

image from the awesome Panta Rei weblog

Now those who have had exposure to Six Sigma and management theory are already probably very well acquainted with the concept of Kaizen. I think anyone who has held a security management position would argue that continuous improvement is a very admirable goal. And I don’t think we need to talk necessarily about what improvement is and why it needs to be continuous.

But what is usually not given a great deal of consideration in our profession is this concept of “relentless reflection”, the “Hansei” bit. And a lack of Hansei can be a source of frustration to those we work with and report to. In fact, there’s a great presentation by Dr. Hwang Chi Hong available via search engines that explains:

Hansei (reflection) alone only generates staff unhappiness. Kaizen (continuous improvement) alone only wastes creativity.

Cool huh?

So what’s this got to do with Risk Analysis?

If we can agree that continuous improvement is an admirable goal for security management, security departments, and even security vendors, then in light of the quote above we have some questions to ask ourselves;

what is this relentless reflection (Hansei),
what should we be relentlessly reflecting about, and
how much work is being put into, and how good are we at, Hansei?

I’d like to focus on that for the next few blog posts this week, because I think that adding structure around this concept may be a “pragmatic” (Hi Mike!) compliment to many of the CISO “self-help” books I’ve been seeing.

The importance of key management

Fri, 22 Aug 2008 08:56:00 +0000

As encryption and data protection becomes more prevalent, dont forget the equal importance of managing those keys. This seems to be the message from Jerome Wendt.

I think there are two sides to the story here - while I agree that managing keys is important, I think this is something users SHOULD NOT be concerned about. This is something the vendors should be focused on solving and not leave it to end users to stumble over.

Key management is hard and it makes sense to solve it at the product level rather than leaving it to implementation variances.

And the attacks keep coming...

Thu, 21 Aug 2008 16:29:00 +0000

Seems like the intensity and frequency breaches have just started to warm up! Even as we pat ourselves about the recent indictment of criminals we see reports of increased activity. Millions of cards stolen and more loss...

Brings us back to a hard question we have to ask ourselves - are we ready to tackle this seriously? Vendors, retailers, banks, government and consumers all have a huge stake in this (and don't forget, so does organized crime). However, it seems like organized crime is living up to its name - they seem a bit more organized about this. Not having looked at the numbers, but is feels like we are being pushed back and they currently have the upper hand...

Not a very PC thing to say, I know. However, we have to wake up to the reality and get more serious about this.

Boston Court's Meddling With 'Full Disclosure' Is Unwelcome

Thu, 21 Aug 2008 00:00:00 +0000

---

Bruce Schneier is Chief Security Technology Officer of BT Global Services and author of Beyond Fear: Thinking Sensibly About Security in an Uncertain World. You can read more of his writings on his website.