In Soviet America, TV SPIES ON YOU!
June 13, 2006
taken from the vopsecurity list today...
Google is in the early R&D stages of developing a scheme that would enable a
laptop PC to capture TV sound and immediately deliver personalized Internet
content to the computer. Two researchers from the company presented a
research paper on the use of ambient-audio identification technology in such
a manner last week at the interactive television conference EURO ITV in
Athens, Greece. "We showed how to sample the ambient sound emitted from a TV
and automatically determine what is being watched from a small signature of
the sound--all with complete privacy and minuscule effort," Michele Covell
and Shumeet Baluja wrote on the Google Research Blog.http://www.informationweek.com/software/showArticle.jhtml?articleID=188702619
And the link to the paper:
http://www.mangolassi.org/covell/pubs/euroITV-2006.pdf"For our system, the main challenge is accurately matching an audio query to
a large database of audio snippets, in real-time and with low latency. High accuracy requires
discriminative audio representations that are resistant to the expected distortions introduced by
compression, broadcasting and client recording. This paper adapts the music-identification system proposed by (Ke et al., 2005) to handle TV audio data and queries."
Wiretapping? Here we come! (Sorta)…
June 13, 2006
Well, as it appears the FCC has ruled that all Internet Phone services are now
legally required to allow for wiretapping. The vote, held by law enforcement
officials on Friday, in a U.S. Court of Appeals, ended at 2-1. This, upholded an
FCC ruling that Web Based phone service providers have to follow the same
rules and regulations as the traditional public switched telephone network (PSTN).
The court also ruled, interestingly enough, that P2P Systems (Instant Messaging, etc) are exempt
from the ruling because they are beyond the law's reach.
I wonder if this will create some weird grey area with SIP messaging etc. Who knows.
Of course none of this really affects us canucks, but it will soon with CALEA and all.
Check the article here: The Washington Post
MYSQL connectivity patch for asterisk – spooling support!
June 11, 2006
Please see the bug:
http://bugs.digium.com/view.php?id=7274
And the older bug:
http://bugs.digium.com/view.php?id=4953
I have posted a patch to 7274 that adds spooling support for current svn. In a nutshell, cdr_addon_mysql.c will lose records due to database connectivity issues, wait_timeout values, etc. This patch adds spooling support such that if any query cannot be successfully executed against the database server, it will be spooled until it can successfully be executed.
Comments, suggestions, ideas welcomed.
-Joe
Thralling Penguin LLC
Asterisk PBX truncated video miniframe vulnerability Announce
June 10, 2006
Core Security Technologies - Corelabs Advisory
http://www.coresecurity.com/corelabs/
Asterisk PBX truncated video miniframe vulnerability
Date Published: 2006-06-09
Last Update: 2006-06-09
Advisory ID: CORE-2006-0330
Bugtraq ID: 18295
CVE Name: CVE-2006-2898
Title: Asterisk PBX truncated video frame vulnerability
Class: Input Validation Error
Remotely Exploitable: Yes
Locally Exploitable: Yes
Advisory URL:
http://www.coresecurity.com/common/showdoc.php?idx=547&idxseccion=10
Vendors contacted:
2006-06-02: Initial notification to vendor
2006-06-02: Vendor response acknowledging notification
2006-06-05: Draft advisory and technical details provided to vendor
2006-06-05: Fixed versions of Asterisk released by vendor
2006-06-06: Asterisk 1.2.9 and 1.0.11 release announcement
Release Mode: COORDINATED RELEASE
*Vulnerability Description:*
Asterisk (http://www.asterisk.org) is an open source software PBX that
supports a wide range of VoIP protocols and equipment. It provides many
IP telephony features including voicemail, interactive voice response,
call queuing, three-way calling, caller ID services, ADSI and more using
SIP, H.323 (as both client and gateway), MGCP, Skinny and the
Asterisk-specific IAX2 protocol.
IAX2 protocol includes support for transmission of video between IAX2
clients that implement such a feature.
A vulnerability found in the Asterisk's handling of IAX2 video frames
could lead to remote compromise of the system running vulnerable
versions of the PBX software through execution of arbitrary code of the
attacker's choosing with the privileges of the Asterisk daemon.
*Vulnerable Packages:*
- Asterisk PBX up to and including v1.2.8
- Asterisk PBX up to and including v1.0.10
Third-party PBX systems that use vulnerable versions of Asterisk such as
Fonality, Asterisk@Home, Switchbox, etc.
*Solution/Vendor Information:*
The following versions of Asterisk PBX are NOT vulnerable to the bug
reported in this advisory
- Asterisk 1.2.9 and above
- Asterisk 1.0.11 and above
These bugfixed versions of Asterisk PBX can be downloaded from
http://www.asterisk.org Users of third-party PBX systems based on
Asterisk should contact their vendor to determine if they are vulnerable
and to obtain a bug fix if necessary.
*Credits:*
Damian Saura, Alejandro Lozanoff, Eduardo Koch, Norberto Kueffner and
Ivan Arce from Core Security Technologies discovered and tested these
vulnerabilities.
We would like to thank Asterisk maintainers Mark Spencer and Kevin
Flemming at Digium.com for responding to our bug report diligently and
for their quickness in addressing the issue and releasing a fix.
*Technical Description - Exploit/Concept Code:*
The Inter-Asterisk Exchange (IAX) protocol provides control and
transmission of streaming media over IP networks. IAX can be used with
any type of streaming media including video and still images but is
targeted primarily at the control of VoIP calls.
The IAX protocol relies on a single UDP port for all communications
(4569/udp). The protocol uses a 15-bit identification number ("call
number") to multiplex several IAX2 streams over the same UDP port. IAX2
messages are called frames. Several basic frame types are described in
the protocol specification draft[1] and defined in the iax2.h header
file of the Asterisk source code package.
An IAX2 full frame uses the 12-byte header described below:
struct ast_iax2_full_hdr {
unsigned short scallno; /*Source call number -- high bit must be 1*/
unsigned short dcallno; /*Destination call number -- high bit is 1 if
retransmission */
unsigned int ts; /* 32-bit timestamp in milliseconds (from 1st
transmission) */
unsigned char oseqno; /* Packet number (outgoing) */
unsigned char iseqno; /* Packet number (next incoming expected) */
unsigned char type; /* Frame type */
unsigned char csub; /* Compressed subclass */
unsigned char iedata[0];
} __attribute__ ((__packed__));
An IAX2 mini-frame, used on established sessions for voice
transmissions, has a 4-byte header:
struct ast_iax2_mini_hdr {
unsigned short callno; /* Source call number -- high bit must be 0,
rest must be non-zero */
unsigned short ts; /* 16-bit Timestamp (high 16 bits from last
ast_iax2_full_hdr) */
/* Frametype implicitly VOICE_FRAME */
/* subclass implicit from last
ast_iax2_full_hdr */
unsigned char data[0];
} __attribute__ ((__packed__));
Video frames are supported using the following 6-byte packet header:
struct ast_iax2_video_hdr {
unsigned short zeros; /* Zeros field -- must be zero */
unsigned short callno; /* Video call number */
unsigned short ts; /* Timestamp and mark if present */
unsigned char data[0];
} __attribute__ ((__packed__));
Asterisk reads IAX2 packets from the network in the socket_read()
function implemented in channels/chan_iax2.c.
The following excerpts are from revision 29849 of the file (included in
the Asterisk 1.2.8 package)
static int socket_read(int *id, int fd, short events, void *cbdata)
{
struct sockaddr_in sin;
int res;
int updatehistory=1;
int new = NEW_PREVENT;
unsigned char buf[4096];
void *ptr;
socklen_t len = sizeof(sin);
...
res = recvfrom(fd, buf, sizeof(buf), 0,(struct sockaddr *) &sin,
&len);
if (res < 0) {
if (errno != ECONNREFUSED)
ast_log(LOG_WARNING, "Error: %s\n",
strerror(errno));
handle_error();
return 1;
}
if(test_losspct) { /* simulate random loss condition */
if( (100.0*rand()/(RAND_MAX+1.0)) < test_losspct)
return 1;
}
[A] if (res < sizeof(struct ast_iax2_mini_hdr)) {
ast_log(LOG_WARNING,
"midget packet received (%d of %d min)\n", res,
(int)sizeof(struct ast_iax2_mini_hdr));
return 1;
}
if ((vh->zeros == 0) && (ntohs(vh->callno) & 0x8000)) {
/* This is a video frame, get call number */
fr->callno = find_callno(ntohs(vh->callno) & ~0x8000,
dcallno, &sin, new,1, fd);
[B] minivid = 1;
} else if (meta->zeros == 0) {
....
At [A] a length check is performed to make sure that the number of bytes
read from the network is not less than those required for a complete a
mini frame header, if that check is passed the packet is further
inspected to determine if it belongs to video-enabled session in [B].
Since the required header length of a IAX2 mini-frame is less than the
header length of a video frame, Asterisk will not reject truncated video
frames of length equal to or greater than 4 bytes (but less than 6-bytes).
Processing of video frames is later done further down the execution flow:
...
} else if (minivid) {
f.frametype = AST_FRAME_VIDEO;
if (iaxs[fr->callno]->videoformat > 0)
f.subclass = iaxs[fr->callno]->videoformat
| (ntohs(vh->ts) & 0x8000 ? 1: 0);
else {
ast_log(LOG_WARNING,
"Received mini frame before first full video frame\n ");
iax2_vnak(fr->callno);
ast_mutex_unlock(&iaxsl[fr->callno]);
return 1;
}
[C] f.datalen = res - sizeof(struct ast_iax2_video_hdr);
if (f.datalen)
f.data = buf + sizeof(struct ast_iax2_video_hdr);
else
f.data = NULL;
...
}
...
[D] iax_frame_wrap(fr, &f)
In [C] the length of video payload is calculated subtracting the size of
video header (number of bytes required in a video header) from the
number of bytes read from the network (return code of the recvfrom()
call). Naturally if a truncated video frame was received the result of
this subtraction will be a negative number and will end up stored in
f.datalen, additionally f.data will end up pointing to memory outside
the boundaries of the packet received.
Later at [D] the iax_frame_wrap() function, implemented in iax2-parser.c
is called:
void iax_frame_wrap(struct iax_frame *fr, struct ast_frame *f)
{
fr->af.frametype = f->frametype;
fr->af.subclass = f->subclass;
fr->af.mallocd = 0; /* Our frame is static relative to the
container */
fr->af.datalen = f->datalen;
fr->af.samples = f->samples;
fr->af.offset = AST_FRIENDLY_OFFSET;
fr->af.src = f->src;
fr->af.delivery.tv_sec = 0;
fr->af.delivery.tv_usec = 0;
fr->af.data = fr->afdata;
if (fr->af.datalen) {
#if __BYTE_ORDER == __LITTLE_ENDIAN
/* We need to byte-swap slinear samples from network
byte order */
if ((fr->af.frametype == AST_FRAME_VOICE) &&
(fr->af.subclass ==AST_FORMAT_SLINEAR)) {
ast_swapcopy_samples(fr->af.data, f->data,
fr->af.samples);
} else
#endif
[E] memcpy(fr->af.data, f->data, fr->af.datalen);
}
}
The memcpy() at [E] will receive a pointer to memory outside of the
packet read from the network as second argument and a negative value as
third argument resulting in an exploitable buffer overflow condition
that could be used by an attacker to execute arbitrary code on the
system running Asterisk.
*Workaround:*
Block inbound packets to port 4569/udp at the perimeter.This workaround
will prevent inter operation of IAX-based VoIP solutions with VoIP
services outside the boundaries of the filtered network. Also, the the
PBX will remain vulnerable to internal attacks from host within the
protected network.
*Additional information and References*
[1] Inter-Asterisk Exchange (IAX) version 2 protocol
(draft-mspencer-iax2-01) http://www.cornfed.com/iax.pdf
*About CoreLabs*
CoreLabs, the research center of Core Security Technologies, is charged
with anticipating the future needs and requirements for information
security technologies. We conduct our research in several important
areas of computer security including system vulnerabilities, cyber
attack planning and simulation, source code auditing, and cryptography.
Our results include problem formalization, identification of
vulnerabilities, novel solutions and prototypes for new technologies.
CoreLabs regularly publishes security advisories, technical papers,
project information and shared software tools for public use at:
http://www.coresecurity.com/corelabs/
*About Core Security Technologies*
Core Security Technologies develops strategic solutions that help
security-conscious organizations worldwide. The company?s flagship
product, CORE IMPACT, is the first automated penetration testing product
for assessing specific information security threats to an organization.
Penetration testing evaluates overall network security and identifies
what resources are exposed. It enables organizations to determine if
current security investments are detecting and preventing attacks. Core
augments its leading technology solution with world-class security
consulting services, including penetration testing, software security
auditing and related training.
Based in Boston, MA. and Buenos Aires, Argentina, Core Security
Technologies can be reached at 617-399-6980 or on the Web at
http://www.coresecurity.com.
*DISCLAIMER:*
The contents of this advisory are copyright (c) 2006 CORE Security
Technologies and (c) 2006 Corelabs, and may be distributed freely
provided that no fee is charged for this distribution and proper credit
is given.
$Id: Asterisk-minivid-advisory.txt,v 1.4 2006/06/09 20:12:00 iarce Exp $
IAXclient truncated frames vulnerabilities Announce
June 10, 2006
Core Security Technologies - Corelabs Advisory
http://www.coresecurity.com/corelabs/
IAXclient truncated frames vulnerabilities
Date Published: 2006-06-09
Last Update: 2006-06-09
Advisory ID: CORE-2006-0327
Bugtraq ID: 18307
CVE Name: N/A
Title: IAXclient truncated frames vulnerabilities
Class: Input Validation Error
Remotely Exploitable: Yes
Locally Exploitable: Yes
Advisory URL:
http://www.coresecurity.com/common/showdoc.php?idx=548&idxseccion=10
Vendors contacted:
2006-06-05: Initial notification to vendor
2006-06-05: Vendor acknowledgment received
2006-06-05: Draft advisory and technical details provided to vendor
2006-06-05: Fixes committed to IAXclient source tree repository
2006-06-06: Notified third-party vendors that use the IAXclient library
Release Mode: COORDINATED RELEASE
*Vulnerability Description:*
IAXclient is an open source library that implements the IAX2 VoIP
protocol used by the Asterisk IP PBX and several VoIP software phones.
Two vulnerabilities have been found in the library that may grant
attackers remote execution of arbitrary code on systems using software
packages that rely on it to implement the IAX2 protocol support.
*Vulnerable Packages:*
Although this vulnerability was discovered and tested in the IDE FISK
software phone other software packages that use the IAXclient library
may be vulnerable. Software phones that implement the IAX2 protocol
using the IAXclient library:
- IDE FISK (confirmed vulnerable)
versions <= 1.35
- IaxComm (confirmed vulnerable)
versions < 1.2.0
- KIAX (confirmed vulnerable)
versions <= 0.8.5
- LoudHush
versions <= 1.3.6
- DIAX
- Ziaxphone, a softphone for the Zaurus PDA
- IAX Phone
- X-lite
- MediaX
- Extreme Networks ePhone
The Asterisk open source PBX is NOT VULNERABLE to these flaws because it
uses a different function to read and process IAX packets received form
the network that properly discards truncated packets.
*Solution/Vendor Information:*
Software packages using an IAXclient library built from source code
dated June 6th, 2006 or newer are not vulnerable.
A fix was committed to the IAXclient SVN source tree on June 5th, 2006.
To fix your client package obtain a current version of IAXclient from
the source repository an recompile the library.
Software phones not vulnerable
- IDE FISK 1.37
- LoudHush 1.3.7
- IaxComm 1.2.0
- KIAX 0.8.51
*Credits:*
Damian Saura, Alejandro Lozanoff, Eduardo Koch, Norberto Kueffner and
Ivan Arce from Core Security Technologies discovered and tested these
vulnerabilities.
We would like to thank IAXclient maintainer Steve K for responding to
our bug report diligently and for his quickness in addressing the issue
and releasing a fix.
*Technical Description - Exploit/Concept Code:*
The Inter-Asterisk Exchange (IAX) protocol provides control and
transmission of streaming media over IP networks. IAX can be used with
any type of streaming media including video and still images but is
targeted primarily at the control of VoIP calls. [1]
The IAX protocol relies on a single UDP port for all its communications
(4569/udp). The protocol uses a 15-bit identification number (call
number) to multiplex several streams over the same UDP port.
IAX messages are called frames. Several basic frame types are described
in the protocol specification draft[1]. Two types of IAX frames are of
interest in this case: the IAX full frame and the IAX mini-frame which
are defined in file iaxclient/lib/libiax2/src/iax2.h
/* Full frames are always delivered reliably */
struct ast_iax2_full_hdr {
unsigned short scallno; /* Source call number -- high bit must be 1 */
unsigned short dcallno; /* Destination call number -- high bit is 1 if
retransmission */
unsigned int ts; /* 32-bit timestamp in milliseconds (from 1st
transmission) */
unsigned char oseqno; /* Packet number (outgoing) */
unsigned char iseqno; /* Packet number (next incoming expected) */
char type; /* Frame type */
unsigned char csub; /* Compressed subclass */
unsigned char iedata[0];
} __PACKED;
/* Mini header is used only for voice frames -- delivered unreliably */
struct ast_iax2_mini_hdr {
unsigned short callno; /* Source call number -- high bit must be 0, rest
must be non-zero */
unsigned short ts; /* 16-bit Timestamp (high 16 bits from last
ast_iax2_full_hdr) */
/* Frametype implicitly VOICE_FRAME */
/* subclass implicit from last ast_iax2_full_hdr */
unsigned char data[0];
} __PACKED;
Parsing of IAX packets received over the network is done in
iax_net_process() function implemented in
iaxclient/lib/libiax2/src/iax.c. The following excerpts are from
revision 536 of the file.
struct iax_event *iax_net_process(unsigned char *buf, int len, struct
sockaddr_in *sin)
{
struct ast_iax2_full_hdr *fh = (struct ast_iax2_full_hdr *)buf;
struct ast_iax2_mini_hdr *mh = (struct ast_iax2_mini_hdr *)buf;
struct iax_session *session;
if (ntohs(fh->scallno) & IAX_FLAG_FULL) {
/* Full size header */
[A] if (len < sizeof(struct ast_iax2_full_hdr)) {
DEBU(G "Short header received from %s\n", inet_ntoa(sin->sin_addr));
IAXERROR "Short header received from %s\n", inet_ntoa(sin->sin_addr));
}
/* We have a full header, process appropriately */
session = iax_find_session(sin, ntohs(fh->scallno) & ~IAX_FLAG_FULL,
ntohs(fh->dcallno) & ~IAX_FLAG_RETRANS, 1);
if (!session)
session = iax_txcnt_session(fh, len-sizeof(struct ast_iax2_full_hdr),
sin, ntohs(fh->scallno) & ~IAX_FLAG_FULL, ntohs(fh->dcallno) &
~IAX_FLAG_RETRANS);
if (session)
return iax_header_to_event(session, fh, len - sizeof(struct
ast_iax2_full_hdr), sin);
DEBU(G "No session?\n");
return NULL;
} else {
[B] if (len < sizeof(struct ast_iax2_mini_hdr)) {
DEBU(G "Short header received from %s\n", inet_ntoa(sin->sin_addr));
IAXERROR "Short header received from %s\n", inet_ntoa(sin->sin_addr));
}
/* Miniature, voice frame */
session = iax_find_session(sin, ntohs(fh->scallno), 0, 0);
if (session)
return iax_miniheader_to_event(session, mh, len - sizeof(struct
ast_iax2_mini_hdr));
DEBU(G "No session?\n");
return NULL;
}
}
The 'len' argument is received from the iax_net_read() function
implemented in the same file. Its value is set to the return value of a
call to the recvfrom(2) function -the number of bytes read from the
network. The 'buf' argument is a pointer to a fixed-size buffer
allocated in the stack with the data read in the iax_net_read() function.
The function performs length checks at [A] and [B] to make sure that the
received packet is not a truncated full-frame or mini-frame
respectively, but processing of possibly undersized packets continues
after output of error messages. This will provide two exploitable
security flaws further down the execution flow.
IAX2 truncated full-frame vulnerability
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In the case of [A] a full-frame packet is processed with the following
execution flow:
iax_net_read()
iax_net_process()
iax_find_session()
iax_txcnt_session()
iax_header_to_event()
The iax_txcnt_session is implemented in the same file:
static struct iax_session *iax_txcnt_session(struct ast_iax2_full_hdr
*fh, int datalen,
struct sockaddr_in *sin, short callno, short dcallno)
{
int subclass = uncompress_subclass(fh->csub);
unsigned char buf[ 65536 ]; /* allocated on stack with same size as
iax_net_read() */
struct iax_ies ies;
struct iax_session *cur;
if ((fh->type != AST_FRAME_IAX) || (subclass != IAX_COMMAND_TXCNT) ||
(!datalen)) {
return NULL; /* special handling for TXCNT only */
}
[C] memcpy(buf, fh->iedata, datalen); /* prepare local buf for
iax_parse_ies() */
if (iax_parse_ies(&ies, buf, datalen)) {
return NULL; /* Unable to parse IE's */
}
...
The 'datalen' argument receives the value passed by iax_net_process()
calculated as datalen = len-sizeof(struct ast_iax2_full_hdr) which will
be become less than 0 if a truncated full frame packet was read from the
network.
Later in [C] the memcpy using a possibly negative value of 'datalen'
will trigger a buffer overflow on the fixed-sized buffer 'buf' in the
stack. A 11-byte UDP packet can be crafted to to trigger the
vulnerability and execute arbitrary code on vulnerable systems.
The iax_header_to_event() function suffers from a similar problem (in
this case a heap overflow) due to its use of a combination of malloc(2),
memset(2) and memcpy(2) using a possibly negative length argument
IAX2 truncated mini-frame vulnerability
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Similarly, in the case of [B], mini-frame packets are processed
following this execution flow:
iax_net_read()
iax_net_process()
iax_find_session()
iax_miniheader_to_event()
An excerpt from the iax_miniheader_to_event() funtion, implemente in the
same file is shown below:
static struct iax_event *iax_miniheader_to_event(struct iax_session
*session,
struct ast_iax2_mini_hdr *mh,
int datalen)
{
struct iax_event *e;
unsigned int ts;
int updatehistory = 1;
e = (struct iax_event *)malloc(sizeof(struct iax_event) + datalen);
if (e) {
if (session->voiceformat > 0) {
e->etype = IAX_EVENT_VOICE;
e->session = session;
e->subclass = session->voiceformat;
e->datalen = datalen;
if (datalen) {
#ifdef EXTREME_DEBUG
DEBU(G "%d bytes of voice\n", datalen);
#endif
[D] memcpy(e->data, mh->data, datalen);
}
ts = (session->last_ts & 0xFFFF0000) | ntohs(mh->ts);
return schedule_delivery(e, ts, updatehistory);
The memcpy in [D] will trigger buffer overflow of heap-allocated data if
the 'datalen' argument has a value of less than 0. A 3-byte UDP packet
(1-byte shorter than a mini-frame packet) can be crafted to trigger the
overflow and execute arbitrary code on vulnerable systems.
*Workaround:*
Block inbound packets to port 4569/udp at the perimeter. This workaround
will prevent IAX-based VoIP solutions from working with VoIP services
outside the boundaries of the filtered network. Particularly, IAX
software phones will be unable to communicate with IAX2 PBXs or
termination services across the network perimeter.
*Additional information and References*
[1] Inter-Asterisk Exchange (IAX) version 2 protocol
(draft-mspencer-iax2-01) http://www.cornfed.com/iax.pdf
*About CoreLabs*
CoreLabs, the research center of Core Security Technologies, is charged
with anticipating the future needs and requirements for information
security technologies. We conduct our research in several important
areas of computer security including system vulnerabilities, cyber
attack planning and simulation, source code auditing, and cryptography.
Our results include problem formalization, identification of
vulnerabilities, novel solutions and prototypes for new technologies.
CoreLabs regularly publishes security advisories, technical papers,
project information and shared software tools for public use at:
http://www.coresecurity.com/corelabs/
*About Core Security Technologies*
Core Security Technologies develops strategic solutions that help
security-conscious organizations worldwide. The company?s flagship
product, CORE IMPACT, is the first automated penetration testing product
for assessing specific information security threats to an organization.
Penetration testing evaluates overall network security and identifies
what resources are exposed. It enables organizations to determine if
current security investments are detecting and preventing attacks.
Core augments its leading technology solution with world-class security
consulting services, including penetration testing, software security
auditing and related training.
Based in Boston, MA. and Buenos Aires, Argentina, Core Security
Technologies can be reached at 617-399-6980 or on the Web at
http://www.coresecurity.com
*DISCLAIMER:*
The contents of this advisory are copyright (c) 2006 CORE Security
Technologies and (c) 2006 Corelabs, and may be distributed freely
provided that no fee is charged for this distribution and proper credit
is given.
$Id: IAXclient-advisory.txt,v 1.3 2006/05/18 21:46:58 iarce Exp $
Asterisk and MYSQL CDR? If so check this out
June 9, 2006
Probably not news to most of you, but I just learned about this today.
It's a system for Asterisk mysql CDR records, so if the MYSQL server is down
asterisk itself doesn't die. I wish I would have known about this a few
months ago when this happened to me.
Oh well, lifes a bitch then you die i guess :)
Check it out : here
It was only a matter of time..
June 7, 2006
taken from: The New York Times
Hacker Said to Resell Internet Phone Service
By KEN BELSON and TOM ZELLER Jr.
Published: June 7, 2006
Federal authorities arrested a Miami resident today in what they said was a hacking scheme involving the resale of Internet telephone service.
The suspect, working with at least one confederate, was said to have illegally tapped into the lines of legitimate Internet phone companies, saddling them with the expense of extra traffic, while he collected more than $1 million in connection fees.
The case, one of the first involving Internet phone hacking, illustrated how Internet-based communications may be criminally exploited, and raises fresh questions about the security of phone traffic over largely unregulated networks.
Prosecutors said that starting in November 2004, Edwin Andres Pena, 23, a Venezuelan who has permanent residency in the United States and lives in Miami, used two companies he started to offer wholesale phone connections at discounted rates to small Internet phone companies.
Instead of buying access to other networks to connect his clients' calls, Mr. Pena is said to have worked with other hackers to create "what amounted to 'free' routes by surreptitiously hacking into the computer networks" of unwitting Internet phone providers, and then routing his customers' calls over those providers' systems, the federal complaint says.
To evade detection, Mr. Pena is said to have hacked into computers run by an unsuspecting investment company in Rye Brook, N.Y., commandeered its unprotected servers, and re-routed his phone traffic through them. These steps made it appear as if that company was sending calls to more than 15 Internet phone companies.
In one three-week period, for instance, prosecutors say that one of the victimized Internet phone providers, based in Newark, received about 500,000 calls that were made to look as if they came from the company in Rye Brook. The Newark company was left having to pay $300,000 in connection fees for routing the phone traffic to other carriers, without receiving any revenue for the calls, prosecutors said.
The companies in Newark and Rye Brook and others said to have been victimized were not identified by name in the complaint, which was filed with the United States District Court in Newark.
Mr. Pena, the government said, used more than $1 million he received from his customers to go on a spending spree, buying real estate in south Florida, a 40-foot Sea Ray Mercruiser motor boat, and luxury cars including a BMW and a Cadillac Escalade.
To date, most of the concern about the safety of Internet-based communications has focused on the ability of criminals to eavesdrop on calls, to fake caller ID's and to steal long-distance phone service.
In this case, Mr. Pena is said to have mimicked legitimate telecommunications brokers, who typically help connect long distance calls by buying minutes from large carriers and reselling them for a profit to smaller phone companies.
But instead of buying those minutes, he manipulated voice-over-Internet services that break conversations into data packets and route them over the Internet. Each packet carries a prefix that identifies the carrier handling the call, and its origin and destination.
Mr. Pena appended stolen prefixes to his customers' calls, allowing them to piggyback on other phone company networks.
At its core, industry experts say the scheme was not technologically complex, particularly in a budding industry still trying close its many security loopholes.
"The technical side of this a 14-year-old can do," said Tom Kershaw, the vice president for voice-over-Internet services at Verisign, an Internet security company. "There are many vulnerabilities."
Mr. Kershaw said that, for instance, a vast majority of voice packets sent by Internet phone companies are still unencrypted, making it relatively easy for outsiders to re-route them by installing new prefixes. He added that the prefixes used by Internet phones companies to identify their voice calls are also relatively easy to discover.
