>From - Sat Mar 02 00:57:18 2024
Received: by 10.115.93.18 with SMTP id v18mr913796wal.13.1234218214282;
Mon, 09 Feb 2009 14:23:34 -0800 (PST)
Return-Path: <lyn..._at_gmail.com>
Received: from wa-out-1112.google.com ([172.21.189.16])
by mx.google.com with ESMTP id k19si9195408waf.0.2009.02.09.14.23.33;
Mon, 09 Feb 2009 14:23:33 -0800 (PST)
Received-SPF: neutral (google.com: 172.21.189.16 is neither permitted nor denied by domain of lyn..._at_gmail.com) client-ip=172.21.189.16;
Authentication-Results: mx.google.com; spf=neutral (google.com: 172.21.189.16 is neither permitted nor denied by domain of lyn..._at_gmail.com) smtp.mail=lyn..._at_gmail.com; dkim=pass (test mode) head..._at_gmail.com
Received: by wa-out-1112.google.com with SMTP id m16so1685061waf.31
for <TSCM-..._at_googlegroups.com>; Mon, 09 Feb 2009 14:23:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=gamma;
h=domainkey-signature:mime-version:received:in-reply-to:references
:date:message-id:subject:from:to:content-type;
bh=v2tetNdXOsgAAz70INU5zvlwx/nFxKvt+1T6EPwrM5A=;
b=fPWPb9WHCNhklnooDLKyvnSyvOVY7GUpwUxXwo54LIkeNNazmdsCuqZfJ/mDVoFIrH
VBuNqCtCEG9ytDhEEw5ArRFz6pajWWt6lN2G1FWm9o+g5kH3dDO68H+uMxNgWtNHFMbJ
CJyRpx/BtWuTIHq5tXPjeTG+SE1NMnGRQR7eU=
DomainKey-Signature: a=rsa-sha1; c=nofws;
d=gmail.com; s=gamma;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:content-type;
b=mNH4Kz5yWKN5w6hqC1KDN+ijZNF+0yFyoZz40DFdqZHrJaEFQug3s3gVBEUGtEA8cy
ZsEUfQ1auIV7fVST/ohdoyG/OUjzAW6jxQek99hA5anSvDXcqUUK2mo0NUa5hAY+NMNh
y6R6oGJrQvSitfdVuILbTauM3PeUUS/8paA0A=
Mime-Version: 1.0
Content-Type: multipart/alternative;
boundary="0016363ba8682c8f45046283d217"
Received: by 10.114.158.1 with SMTP id g1mr4000327wae.126.1234218213215; Mon,
09 Feb 2009 14:23:33 -0800 (PST)
In-Reply-To: <898CA1FD-F797-4403-8BD6-2AC50F2ABA7C_at_bigpond.net.au>
References: <898CA1FD-F797-4403-8BD6-2AC50F2ABA7C_at_bigpond.net.au>
Date: Mon, 9 Feb 2009 14:23:33 -0800
Message-ID: <f0acdbaa0902091423u776a3701w2ebd309bea3e4016_at_mail.gmail.com>
Subject: Re: [TSCM-L] {3326} VOIP
From: Adam Stenseth <lyn..._at_gmail.com>
To: TSCM-L2006_at_googlegroups.com
--0016363ba8682c8f45046283d217
Content-Type: text/plain; charset=ISO-8859-1
There aren't really any good catch-all technical methods that can be used
with VOIP systems, since there are so many different options available.
You can do the same sort of physical-integrity checking you'd do on the
lines for a POTS, but since the core of the system is, in most cases, a
generic multipurpose computer optimized & running specialized software
engineered to handle a large amount of low-instance-volume,
low-latency-tolerance data traffic (packetized voice), it becomes alot more
exploitable than the more typically black-box brainy core of a traditional
POTS.
Auditing the core of a VOIP system is alot more akin to auditing a data
system than a POTS, since that's exactly what it is. Like in data system
security, the specifics depend on the specific system; if, for example, your
client is running an open-source VOIP system (like Asterisk) and you have
some good devs laying around (you can get them cheaper by the dozen these
days, economies being what they are, though good code auditors still aren't
cheap) you can audit the code, compile the binaries, hash them, and hash
against the binaries they're running to see if they've been modified; this
is basically what a number of IDSs do (ie, Tripwire). Then of course you'd
have to audit their access-control configuration, see who has access, and
from there you get more into general counterintel practice than technical
specifics. At that point, you might as well do a general security audit on
the box it's running on as well, and load it up with IDSs, like snort or
tripwire.
Of course, that's all alot of effort and alot of money, and in most cases,
not an option anyway, since most deployed VOIP systems are closed-source,
and face the same array of security problems as any other closed-source
software product. The best you can do at that point is keep up on
system-specific vulnerabilities as they're published (which you can bet most
are not; Avaya in particular is notorious in both the voice & data worlds
for leaving themselves little backdoors to disable functionality for
leverage in license contract negotiations, tho it's unlikely they're unique
in that practice, probably just more hamfisted) and audit for & patch them
as you detect them. Like most publicised software vulnerabilities, major
VOIP vendors' vulns show up either on their own errata lists or bugtraq, or
both, and notices often weave their way through the tubes to many other
lists (such as this one, if they're major enough).
Doing it really well, though, may be farther than you want to expand your
scope as a TSCM professional. It's really a compsec issue, and will draw
enough of your time & resources if you pursue it fully that it may dilute
upkeep in other areas. Computer security, like TechSec, is a constant arms
race; the additional downside is that in compsec the barrier to entry is
alot lower (you don't even need to buy so much as a spool of solder to write
a new software exploit; just use the ubiquitous computer you built the last
one on), the risk tends to be lower, and there exists alot more interaction
& cooperation on both sides of the curtain, which means that sophistication
grows exponentially.
-adam
On Fri, Feb 6, 2009 at 7:49 PM, Michael Dever <d..._at_bigpond.net.au> wrote:
> A question to all you learned people.....
> What tests/checks do you perform to provide clients with an assurance that
> their VOIP system has not been hacked and handsfree handsets remotely turned
> into room listening devices?
>
> Regards
> Mike
>
>
> Michael J. Dever CPP PSP
>
> *Dever Clark + Associates*
> GPO Box 1163
> Canberra ACT 2601
> Australia
>
> Email: d..._at_bigpond.net.au
>
> This message is sent in strict confidence for the addressee(s) only.
> It may contain legally privileged information. The contents are not to be
> disclosed to anyone other than the addressee.
> Unauthorised recipients are requested to preserve this confidentiality and
> to advise the sender immediately of any error in transmission.
>
>
>
>
>
>
>
> >
>
--0016363ba8682c8f45046283d217
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
There aren't really any good catch-all technical methods that can be us=
ed with VOIP systems, since there are so many different options available.&=
nbsp; You can do the same sort of physical-integrity checking y=
ou'd do on the lines for a POTS, but since the core of the system is, i=
n most cases, a generic multipurpose computer optimized & running speci=
alized software engineered to handle a large amount of low-instance-volume,=
low-latency-tolerance data traffic (packetized voice), it becomes alot mor=
e exploitable than the more typically black-box brainy core of a traditiona=
l POTS. <br>
<br>Auditing the core of a VOIP system is alot more akin to auditing a data=
system than a POTS, since that's exactly what it is. Like =
in data system security, the specifics depend on the specific system; if, f=
or example, your client is running an open-source VOIP system (like Asteris=
k) and you have some good devs laying around (you can get them cheaper by t=
he dozen these days, economies being what they are, though good code audito=
rs still aren't cheap) you can audit the code, compile the binari=
es, hash them, and hash against the binaries they're running to see if =
they've been modified; this is basically what a number of IDSs do (ie, =
Tripwire). Then of course you'd have to audit their access-contro=
l configuration, see who has access, and from there you get more into gener=
al counterintel practice than technical specifics. At that poin=
t, you might as well do a general security audit on the box it's runnin=
g on as well, and load it up with IDSs, like snort or tripwire. <br>
<br>Of course, that's all alot of effort and alot of money, and in most=
cases, not an option anyway, since most deployed VOIP systems are closed-s=
ource, and face the same array of security problems as any other closed-sou=
rce software product. The best you can do at that point i=
s keep up on system-specific vulnerabilities as they're published (whic=
h you can bet most are not; Avaya in particular is notorious in both the vo=
ice & data worlds for leaving themselves little backdoors to disable fu=
nctionality for leverage in license contract negotiations, tho it's unl=
ikely they're unique in that practice, probably just more hamfisted) an=
d audit for & patch them as you detect them. Like most publ=
icised software vulnerabilities, major VOIP vendors' vulns show up eith=
er on their own errata lists or bugtraq, or both, and notices often weave t=
heir way through the tubes to many other lists (such as this one, if they&#=
39;re major enough). <br>
<br>Doing it really well, though, may be farther than you want to expand yo=
ur scope as a TSCM professional. It's really a compsec issu=
e, and will draw enough of your time & resources if you pursue it fully=
that it may dilute upkeep in other areas. Computer security, l=
ike TechSec, is a constant arms race; the additional downside is that in co=
mpsec the barrier to entry is alot lower (you don't even need to buy so=
much as a spool of solder to write a new software exploit; just use the ub=
iquitous computer you built the last one on), the risk tends to be lower, a=
nd there exists alot more interaction & cooperation on both sides of th=
e curtain, which means that sophistication grows exponentially.<br>
<br>-adam<br><br><div class=3D"gmail_quote">On Fri, Feb 6, 2009 at 7:49 PM,=
Michael Dever <span dir=3D"ltr"><<a href=3D"mailto:d..._at_bigpond.net.au"=
>d..._at_bigpond.net.au</a>></span> wrote:<br><blockquote class=3D"gmail_qu=
ote" style=3D"border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0p=
t 0.8ex; padding-left: 1ex;">
<div style=3D"">A question to all you learned people.....<div><br></div><di=
v>What tests/checks do you perform to provide clients with an assurance tha=
t their VOIP system has not been hacked and handsfree handsets remotely tur=
ned into room listening devices?</div>
<div><br></div><div>Regards</div><div>Mike</div><br><br><div> <span style=
=3D"border-collapse: separate; color: rgb(0, 0, 0); font-family: Arial; fon=
t-size: 12px; font-style: normal; font-variant: normal; font-weight: normal=
; letter-spacing: normal; line-height: normal; text-indent: 0px; text-trans=
form: none; white-space: normal; word-spacing: 0px;"><div style=3D"">
<span style=3D"border-collapse: separate; color: rgb(0, 0, 0); font-family:=
Arial; font-size: 12px; font-style: normal; font-variant: normal; font-wei=
ght: normal; letter-spacing: normal; line-height: normal; text-indent: 0px;=
text-transform: none; white-space: normal; word-spacing: 0px;"><div style=
=3D"">
<span style=3D"border-collapse: separate; color: rgb(0, 0, 0); font-family:=
Arial; font-size: 12px; font-style: normal; font-variant: normal; font-wei=
ght: normal; letter-spacing: normal; line-height: normal; text-indent: 0px;=
text-transform: none; white-space: normal; word-spacing: 0px;"><div style=
=3D"">
<span style=3D"border-collapse: separate; color: rgb(0, 0, 0); font-family:=
Arial; font-size: 13px; font-style: normal; font-variant: normal; font-wei=
ght: normal; letter-spacing: normal; line-height: normal; text-indent: 0px;=
text-transform: none; white-space: normal; word-spacing: 0px;"><div style=
=3D"">
<div style=3D"margin: 0px;"><font size=3D"3"><span style=3D"font-size: 12px=
;"><span style=3D"font-size: 12px;"><span style=3D"font-family: 'Brush =
Script MT'; font-size: 18px; font-style: italic;">Michael J. Dever</spa=
n> CPP PSP</span></span></font></div>
<div style=3D"margin: 0px;"><font size=3D"3"><span style=3D"font-size: 12px=
;"><br></span></font></div><div style=3D"margin: 0px;"><font size=3D"3"><sp=
an style=3D"font-size: 12px;"><b><span style=3D"font-weight: normal;"><b><f=
ont color=3D"#0000ff">Dever</font></b><b> <font color=3D"#996633">Clar=
k</font> <font color=3D"#0000ff">+ Associates</font></b></span></b></s=
pan></font></div>
<div style=3D"margin: 0px;"><font size=3D"3"><span style=3D"font-size: 12px=
;"><span style=3D"font-size: 12px;">GPO Box 1163</span></span></font></div>=
<div style=3D"margin: 0px;"><font size=3D"3"><span style=3D"font-size: 12px=
;"><span style=3D"font-size: 12px;">Canberra ACT 2601</span></span></font><=
/div>
<div style=3D"margin: 0px;"><font size=3D"3"><span style=3D"font-size: 12px=
;"><span style=3D"font-size: 12px;">Australia</span></span></font></div><di=
v style=3D"margin: 0px;"><br></div><div style=3D"margin: 0px;"><font size=
=3D"3"><span style=3D"font-size: 12px;"><span style=3D"font-size: 12px;">Em=
ail: <a href=3D"mailto:d..._at_bigpond.net.au" target=3D"_blank">d..._at_bigpond.=
net.au</a></span></span></font></div>
<div style=3D"margin: 0px; min-height: 14px; font-size: 12px;"><br style=3D=
"font-size: 12px;"></div><div style=3D"margin: 0px;"><font size=3D"3"><span=
style=3D"font-size: 12px;"><span style=3D"font-size: 12px;">This message i=
s sent in strict confidence for the addressee(s) only.<span> </span></=
span></span></font><font size=3D"3"><span style=3D"font-size: 12px;"><span =
style=3D"font-size: 12px;"> </span></span></font></div>
<div style=3D"margin: 0px;"><font size=3D"3"><span style=3D"font-size: 12px=
;"><span style=3D"font-size: 12px;">It may contain legally privileged infor=
mation. The contents are not to be disclosed to anyone other than the addre=
ssee.</span></span></font><font size=3D"3"><span style=3D"font-size: 12px;"=
><span style=3D"font-size: 12px;"> </span></span></font></div>
<div style=3D"margin: 0px;"><font size=3D"3"><span style=3D"font-size: 12px=
;"><span style=3D"font-size: 12px;">Unauthorised recipients are requested t=
o preserve this confidentiality and to advise the sender immediately of any=
error in transmission.</span></span></font></div>
<div style=3D"margin: 0px;"><br></div></div><br></span></div></span><br></d=
iv></span><br></div></span><br> </div><br><br>
</p></div><br>
</blockquote></div><br>
--0016363ba8682c8f45046283d217--
Received on Sat Mar 02 2024 - 00:57:18 CST