Open Beta - New Free AV Software
All, Immunet Protect is now in the 4th round of public beta. This is free beta AV software which has been pre-tested extensively by a portion of the Bugtraq community and is now available for general download to the rest of the community. The general idea is that it allows you to build communities of people and collectively share your protections. It's uses a series of methods to convict files, primarily in the cloud. It is meant to be run in conjunction with your current AV to increase your detection rates and is compatible with Norton/AVG/Mcafee/Avira 2009 and greater. It is not yet formally tested with other products but has been reported to work alongside Eset, Gdata, Panda Cloud and MSSE. If you would like to try it in beta we welcome your participation and more importantly, your feedback. Since posting to Bugtraq initially we've gone from 60 pre-beta users to slightly over 10,000 as I write this. Many of them part of this fantastic community, thanks for the support! The download URL is: http://www.immunet.com/user/new/ Best Regards, Al Huger Immunet Corp.
SecurityFocus is turning seven. What's next? - OFFTOPIC - Please excuse the X-Post
Warning - This is a message directed to the SecurityFocus community and not directly related to a running thread on this list - please delete it if you are not interested in this community administrivia. Nearly seven years ago on a long ride home on Interstate 280 in the San Francisco Bay Area, I decided it was time to leave my job. Not because I disliked my current job but because it lacked some of the things I've always loved about the industry. It lacked a broad sense of community and a coordinated, steady stream of new and important information. This realization wasn't an indictment of my then employer, I simply came to recognize that there was an empty space that a company focused strictly on product solutions was unlikely to fill. In my mind there was a need to create a new type of security community, one where information was shared between everyone, not just individuals on scattered lists and bulletin boards. I knew that the creation of this type of community would take a fair amount of work and rather than attempting to do it myself, I enlisted a number of friends who shared the same vision. Our shared goal was to build to build a community in which everyone could take part. After a few months of hard work and long hours, SecurityFocus was born. Our first order of business was to meet the needs of the community and towards that we built SecurityFocus.com, with the Bugtraq mailing list as its centerpiece. When the site went live it originally had a small community of 30,000 email subscribers and a modest web presence that generated 1500 unique visitors per day. It was from this base that we set out to build a vital community driven by new security content, dialogue and interaction between all members of the security community. Fast-forward seven years and I think I can comfortably say we've done pretty well. We now exceed 500,000 subscribers to our lists and our web presence has grown to several million unique visitors a month. SecurityFocus has grown into the site we had originally envisioned and more. Today, careers are found, products and ideas are developed from our forum and list discussions and more importantly, SecurityFocus continues to be the central location for our community to thrive and grow. How do we plan to celebrate our seventh anniversary? The same as the previous six - quietly and with an eye towards the future. After seven years, the question that comes to my mind is where do we go from here? I think that one of the reasons why the SecurityFocus community has done as well as it has is because we've solicited feedback on where you felt it needed to go. On our seventh anniversary, I think it's only fitting that we continue to come back to you - the community, and ask what we need to do to continue to make SecurityFocus the place for discussion, innovation and growth in security. What are the security needs, services and information that we should be providing to the community? Your suggestions and opinions have always been the driving force behind SecurityFocus and on our seventh birthday, I'd like to invite you to contact me directly with your suggestions. Send me some email and let's discuss where you think SecurityFocus should be headed. So, what's next? That's up to you. Sincerely, Al Huger --- http://www.linkedin.com/in/alhuger
Code Red Worm, closing notes
It seems as if the Code Red worm has gone to sleep for now, at least so far as we can tell. It will be interesting to see what happens when it re-awakens. My previous email noted that the ARIS project would be notifying as many IP's as we could about possible infections of the worm. To that end we notified against 172,066 unique IP's within 27,640 unique domains. We owe a special thanks to Vern Paxson of LBL in this regard for supplying a significant amount of data alongside our own ARIS data. Some notes of interest: List of the largest bulk offenders: 923 Level3.net 1159 cnc.net 1251 shawcable.net 1309 att.net 1363 bellatlantic.net 1404 wanadoo.fr 1438 gtei.net 1452 btinternet.com 1705 mindspring.com 1709 swbell.net 1905 bellsouth.net 2358 mediaone.net 2395 uu.net 2496 aol.com 2909 hinet.net 3870 pacbell.net 4148 t-dialin.net 5940 rr.com As I said earlier, the traffic seems to have dropped off. This is a graph showing this attack alongside the rest of the Internet noise( in terms of attacks trending up), the cessation is readily apparent: http://www1.securityfocus.com/data/staff/trended3.pdf Cheers, -al VP Engineering SecurityFocus.com Vae Victis
Code Red Worm, New information
Heya all, By now we are all aware of the serious nature of the Core Red Worm. One of the most powerfull lessons we can all take away from this is how this community is capable of mustering in times of crisis like in order to face and analyze threats. The traffic accross the Incidents, Bugtraq lists among other sources has been outstanding in terms of rallying against this. A number of efforts are underway to address this situation outside of list discussion, I am going to outline what we are doing here at SecurityFocus. This is not intended to detract from anyone elses work, it's all great, we are just bringing you into our contribution. Notification First, we are in the process of notifying all of the infected IP owners that we know of. This data has been taken from the ARIS Analyzer user base as well contributions from individuals in the community (I will post a public thanks to them just as soon as they give me permission to do so). The list of infected hosts that we are now in the process of notifying against is a little over 40,000 hosts. Each host owner that we can indentify will be recieving a mail outlining the fact that they are infected, which IP's are infected and how to address the situation. New Data Reports Second we are posting a series of reports derived from ARIS Predictor, a SecurityFocus system designed to track events such as these. The data is coming from a system wich is pre-production so it will contain some minor inconsistencies, please take this into account. The data we are posting here is derived from 100 IDS sensors accross 6 continents with statistics derived from a 10 day period, the 10th until today. The information available herein is quite interesting and worth a read. We will make a point of making this type of information available whenever we face a problem like this in the community. Now, onto the reports: 1. New Attacks Trend Report This report displays the frequency of attacks which attacks have been viewed (in terms of abnormal compared against a baseline) over the last 10 days. It clearly shows our first contact with the worm on the 11th (earlier than previously thought). Other reports (not listed here) show the first contact happening at 17:00 GMT in the USA on the 11th. http://www.securityfocus.com/data/staff/Trends.pdf 2. Top 10 Destination (Attacked Countries) for the Core Red Worm This report displays the top ten victim countries for which the greatest number of attacks is destined. This pie graph and all of the others only tabulate data from the IDS's which saw the attack, therefore the numbers will not add up to 100%. http://www.securityfocus.com/data/staff/destination.pdf 3. Average Attacks Based On Averaged Time Of Day (10 days) This graph shows the frequency of attacks accross time of day as seen by each continent. Very interesting. http://www.securityfocus.com/data/staff/timeofday.pdf 4. Average Attacks Based On Averaged Time Of Day (1 day) This graph shows the frequency of attacks accross time of day as seen by each continent for the 19th. http://www.securityfocus.com/data/staff/timeofday-1.pdf 5. Attacked Industries Report This report displays the frequency of attacks targeted against specific industry types over our 10 day period. http://www.securityfocus.com/data/staff/industry.pdf 6. Targets As Determined By Revenue This report displays the frequency of attacks targeted against companies of a particular annual revenue range. http://www.securityfocus.com/data/staff/revenue.pdf We could post a large number of other reports with more granular data or against other data points, but this should be sufficient for the time being to help augment the current data available. We will quite possibly post other information in the near future. Cheers, Alfred Huger VP Engineering SecurityFocus Vae Victis
ZoneAlarm Vulnerability
ZoneAlarm has apparently released a tenative fix for the source port 67 problem recently posted to the list. http://www.zonelabs.com/beta_download.htm Alfred Huger VP of Engineering SecurityFocus.com
Re: ZoneAlarm
Additionally, using nmap's -f flag allows you to send traffic past ZoneAlarm without any alerts. I set up a copy on a local machine here and while I found that source port scans from 67 slipped past the firewall -f seemed to be alerted on just fine. Can anyone else comment to this? Alfred Huger VP of Engineering SecurityFocus.com
Local / Remote Exploiteable Buffer Overflow Vulnerability in InterAccess TelnetD (fwd)
-- Forwarded message -- Date: Wed, 23 Feb 2000 10:59:20 -0600 From: Edith Myers [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Local / Remote Exploiteable Buffer Overflow Vulnerability in InterAccess TelnetD Hello -- We have been in current contact with USSR Labs. I have also contacted NTSecurity.net regarding this issue. USSR Labs stated that they had contacted us and we had not contacted them back regarding this issue. In actuality, we had not received any contact from them prior to the release of the information regarding the Telnet Server issue. After we received information from NTSecurity.net stating that they had published this error on their web page, we contacted USSR Labs and they stated that they had tried to contact us from our Tech support web page but kept getting ODBC errors -- therefore, no contact had been received from them and we could not tell them that this is a BUILD 4 issue and we are currently on BUILD 7 (we have not sold build 4 or had it on our web site for download in over a year). We have come to find out that it may be a WinSock issue with older service packs which can be resolved by updating the service pack/WinSock or by downloading the latest version of InterAccess TelnetD Server for Windows NT 4.0 (build7). I informed USSR Labs that they could have directly emailed Pragma (since our email address is listed) or called us regarding this issue. They had presented the information as if we were ignoring their attempts to contact us, whereas in actuality we were not being contacted because of the ODBC error was preventing any contact from getting to Pragma. So I had suggested that they should have found an alternative method for contacting us. (NOTE: we have hence fixed the ODBC error that had be occuring on our Tech Support page and now have a direct MailTo link). (That's what's been going on over the past day -- just to update you to this point) Please let your readers know that this is a BUILD 4 issue (which was released June 1998) and we are now on BUILD 7. The problem can be fixed by updating the service pack/WinSock or by updating to BUILD 7. (FYI-- we emailed USSR Labs our latest build of the product and one of our IP addresses to help them. After giving them this, they are now excessively pinging this computer. They have emailed me asking me if I have found anything interesting on this computer. I found that to be slightly malicious). Please let me know if this information helps your readers. Regards, Edith H. Myers Director of Marketing Operations Tel: 512-219-7270 Pragma Systems, Inc.Fax: 512-219-7110 http://www.pragmasys.com ^ ^ ^ ^ ^ ^ O O === _|_ ===
Y2K bug in Shadow IDS
As taken from the Incidents mailing list at SecurityFocus.com:
To:
Incidents
Subject:
Y2K bug in Shadow IDS
Date:
Sun Jan 02 2000 05:57:58
Author:
Patrick Oonk
Message-ID:
[EMAIL PROTECTED]
Hi,
The shadow IDS contains a programming mistake that breaks
many scripts in the suite. The author assumed at some point
that the output of the year value in Perl's date functions
is a 2 digit number which it isn't. In 2000 the value
of $year is '100'.
I made a small fix which still is not pretty, but going
to a 4 digit year would break many other things in the scripts,
and this fix will work for the next 99 years anyway :)
I changed the top of 'sensor/variables.ph' into
# We need various timestamps all over the place
@T = localtime;
if ($T[5] 99) {
$T[5] -= 100;
}
By the way, the Shadow perl scripts also use /tmp a lot with
predictable file names, so local exploits are possible,
but this is more of a Bugtraq issue I guess.
p.
--
Patrick Oonk - PO1-6BONE - [EMAIL PROTECTED] - www.pine.nl/~patrick
Pine Internet B.V. GOAT666-RIPE PGP key ID BE7497F1
Tel: +31-70-3111010 - Fax: +31-70-3111011 - http://www.pine.nl/
-- Pine Security Digest - http://security.pine.nl/ (Dutch)
Excuse of the day: Your excuse is: it has Intel Inside
Privacy hole in Go Express Search
-- Forwarded message -- Date: 13 Dec 1999 03:23:39 - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Link Suggestion Link Name: Privacy hole in Go Express Search Link URL: http://www.mobileunit.org/advisories/001/ Description: Disney's Go Express Search operates an http server at port 1234 without authentication. Remote users can submit search queries, and view queries and personal links left by other users. It's possible to access the configuration interface, which can reveal the e-mail address of the user who registered it. Configuration settings can be changed remotely to, for instance, add, remove or alter personal links.
Solaris sadmind Buffer Overflow Vulnerability
Certain versions of Solaris ship with a version of sadmind which is vulnerable to a remotely exploitable buffer overflow attack. sadmind is the daemon used by Solstice AdminSuite applications to perform distributed system administration operations such as adding users. The sadmind daemon is started automatically by the inetd daemon whenever a request to invoke an operation is received. Under vulnerable versions of sadmind (2.6 and 7.0 have been tested), if a long buffer is passed to a NETMGT_PROC_SERVICE request (called via clnt_call()), it is possible to overwrite the stack pointer and execute arbitrary code. The actual buffer in questions appears to hold the client's domain name. The overflow in sadmind takes place in the amsl_verify() function. Because sadmind runs as root any code launched as a result will run as with root privileges, therefore resulting in a root compromise. This exploit was reported to the Incidents list on December 9th, 1999 by several parties who had been attacked and compromised with it. We do not have permission to post the vulnerability (SecurityFocus.com) although we would like to. However, given that this code has been floating around for quite some time, and being full disclosure advocates we decided to post as much as possible. The exploit has been sent to Sun and is currently under inspection. When it is publicly available it will be posted to Bugtraq and to the SecurityFocus.com Vuldb. If someone else posts this vulnerability to the list, we will of course allow it. I should note, that I would be *very* surprised if CERT/CC and Sun were not aware of this problem well before it was brought up on the Incidents list. Out of 2000 readers on the list, 3 admitted to being compromised (as early as October 1999) and at least one had full source left behind from the intruder. The actual exploit itself was written by Cheez Whiz [EMAIL PROTECTED] June 24, 1999. Cheez has at least written or contributed to (including reused code) the following exploits: 1. Solaris kcms Buffer Overflow Vulnerability http://www.securityfocus.com/bid/452 2. imapd Buffer Overflow Vulnerability http://www.securityfocus.com/bid/130 3. Solaris /usr/bin/mail -m Local Buffer Overflow Vulnerability http://www.securityfocus.com/bid/672 4. Solaris ufsdump Local Buffer Overflow Vulnerability http://www.securityfocus.com/bid/680 5. SCO UnixWare Xsco Buffer Overflow Vulnerability http://www.securityfocus.com/bid/824 Currently the SecurityFocus staff are not aware of any vendor supplied patches for this issue. If you feel we are in error or are aware of more recent information, please mail us at: [EMAIL PROTECTED] Workaround: Unless you require sadmin (if your using the Solstice AdminSuite you do) we suggest you comment sadmind out from your /etc/inetd.conf entry. By default, the line in /etc/inetd.conf that starts sadmind appears as follows: 100232/10 tli rpc/udp wait root /usr/sbin/sadmind sadmind If you do require this service we suggest you block all access to it from external networks via filtering rulesets on your router(s) or Firewall(s). Alfred Huger VP of Engineering SecurityFocus.com
Clarification needed on the snoop vuln(s)
As you all know, we have recently seen two /usr/sbin/snoop overflows. Posted by both ISS and w00w00. Sun has released patches for the ISS vulnerability, what I am wondering is, does this also solve the w00w00 problem. For referance the patches in question are: Solaris 7 sparc 108482-01 Solaris 7 x86 108483-01 Solaris 5.6 sparc 108492-01 Solaris 5.6 x86 108493-01 Solaris 5.5 sparc 108501-01 Solaris 5.5 x86 108502-01 Solaris 5.4 sparc 108490-01 Solaris 5.4 x86 108491-01 Solaris 5.3 sparc 108489-01 The vulnerabilties in question are: ISS /usr/sbin/snoop: http://www.securityfocus.com/bid/864 w00w00 /usr/sbin/snoop overflow: http://www.securityfocus.com/bid/858 Alfred Huger VP of Engineering SecurityFocus.com
From the SCO Security Page
http://www.sco.com/security/ 3rd December 1999 SSE046 has been released to fix security holes in uidadmin. SSE039 was updated due to an error in the original release. If you have already installed SSE039, please uninstall it and get the current patch.
SCO su patches
=== SCO Security Bulletin 99.19 17th-November-1999 su Security Patch --- I. Description Several security holes were found in the "su" program along with the iaf library. II. Impact Without these patches, unauthorized users may gain privileges. III. Releases This SSE contains binaries for: UnixWare 2.1.3 UnixWare 7.0.0 through 7.1.1 IV. Solution SCO is providing an interim patch to address this issue in the form of a System Security Enhancement (SSE) package. SSE039 contains replacement binaries for each system type, and is available for Internet download via anonymous ftp, and from the SCOFORUM on Compuserve. You can download the SSE package as follows: Anonymous ftp (World Wide Web URL): ftp://ftp.sco.COM/SSE/sse039.ltr(cover letter, ASCII text) ftp://ftp.sco.COM/SSE/sse039.tar.Z (new binaries, compressed tar file) Compuserve: GO SCOFORUM, and search Library 11 (SLS/SSE Files) for these filenames: SSE039.LTR (cover letter, ASCII text) SSE039.TAZ (new binaries, compressed tar file) Checksums (sum -r): 01787 3 sse039.ltr 53627 555 sse039.tar.Z V. Updates This bulletin is available for anonymous ftp download from ftp://ftp.sco.COM/SSE/security_bulletins/SB-99.19a, and will be updated as new information becomes available. The latest information on security vulnerabilities and fixes from SCO is available on the world-wide web at http://www.sco.com/security/ VI. Further Information: If you have further questions, contact your support provider. If you need to contact SCO, please send electronic mail to [EMAIL PROTECTED], or contact SCO as follows. USA/Canada: 6am-5pm Pacific Time (PST/PDT) --- 1-800-347-4381 (voice) 1-408-427-5443 (fax) Pacific Rim, Asia, and Latin American customers: 6am-5pm Pacific Time (PST/PDT) 1-408-425-4726 (voice) 1-408-427-5443 (fax) Europe, Middle East, Africa: 9am-5:30pm UK Time (GMT/BST) +44 (0)1923 816344 (voice) +44 (0)1923 817781 (fax)
Caldera Pine Advisory
-BEGIN PGP SIGNED MESSAGE- __ Caldera Systems, Inc. Security Advisory Subject:remote attack on pine users Advisory number:CSSA-1999-036.0 Issue date: 1999 November, 19 Cross reference: __ 1. Problem Description Versions of pine prior to 4.21 had a security problem when viewing URLs. By sending an email with a specially formatted URL embedded in it, an attacker could cause arbitrary shell code to be executed under the account of the victim user. 2. Vulnerable Versions Systems : up to COL 2.3 Packages: up to pine-4.10-1 3. Solutions Workaround: not known The proper solution is to upgrade to the latest packages rpm -U pine-4.21-1.i386.rpm 4. Location of Fixed Packages The upgrade packages can be found on Caldera's FTP site at: ftp://ftp.calderasystems.com/pub/OpenLinux/updates/2.3/current/RPMS/ The corresponding source code package can be found at: ftp://ftp.calderaystems.com/pub/OpenLinux/updates/2.3/current/SRPMS 5. Installing Fixed Packages Upgrade the affected packages with the following commands: rpm -U pine-4.21-1.i386.rpm 6. Verification 93b2cb3b558735b075392cd639e4edda RPMS/pine-4.21-1.i386.rpm 7f87c9f295c82f65b9412a4c311986c5 SRPMS/pine-4.21-1.src.rpm 7. References This and other Caldera security resources are located at: http://www.calderasystems.com/support/security/index.html This security fix closes Caldera's internal Problem Report 5258 8. Disclaimer Caldera Systems, Inc. is not responsible for the misuse of any of the information we provide on this website and/or through our security advisories. Our advisories are a service to our customers intended to promote secure installation and use of Caldera OpenLinux. __ -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.0 (GNU/Linux) Comment: For info see http://www.gnupg.org iQCVAwUBODVSGen+9R4958LpAQGvjgQAnoDjYlthZ+L0vIeIztvUElydo1GKJb4V i7jSXKnl5bWKUNhhYqSmPKYRYcJ9KolXXFYqEeC+GcSLfW5VGoxXEZ8B82AynXh0 0gIw/pLq6pTguifpORzIMWRn81BawtJd8JH6xvV8cRnopAm0zQy7y2iXw3gX2xRa l7Wz/qxKshc= =jty2 -END PGP SIGNATURE-
DoS with sysklogd, glibc (Caldera)
-BEGIN PGP SIGNED MESSAGE- __ Caldera Systems, Inc. Security Advisory Subject:DoS with sysklogd, glibc Advisory number:CSSA-1999-035.0 Issue date: 1999 November, 17 Cross reference: __ 1. Problem Description On Linux, most services do not log informational or error messages to their own files, but use the system log daemon, syslogd, for this. Unfortunately, the current syslogd has a problem by which any user on the local host can mount a denial of service attack that effectively stops all logging. Since all programs that want to send logging information to syslogd block until they're able to establish a connection to syslogd, this will make programs such as login, su, sendmail, telnetd, etc hang indefinitely. 2. Vulnerable Versions Systems : previous to COL 2.3 Packages: previous to sysklogd-1.3.31-4 3. Solutions Workaround: none The proper solution is to upgrade to the latest packages rpm -U sysklogd-1.3.31-4.i386.rpm ** Make sure to reboot the machine after installing the fixed RPM. ** 4. Location of Fixed Packages The upgrade packages can be found on Caldera's FTP site at: ftp://ftp.calderasystems.com/pub/OpenLinux/updates/2.3/current/RPMS/ The corresponding source code package can be found at: ftp://ftp.calderaystems.com/pub/OpenLinux/updates/2.3/current/SRPMS 5. Installing Fixed Packages Upgrade the affected packages with the following commands: rpm -U sysklogd-1.3.31-4.i386.rpm 6. Verification a3a5aba891db83dbb0e31b01879011ac RPMS/sysklogd-1.3.31-4.i386.rpm 2bdf1431d3a487ee15e2323d61da2366 SRPMS/sysklogd-1.3.31-4.src.rpm 7. References This and other Caldera security resources are located at: http://www.calderasystems.com/support/security/index.html This security fix closes Caldera's internal Problem Report 5074 Caldera wishes to thank Alex Kuznetisov, Alan Cox, and Bill Nottingham (the latter two of RedHat, Inc.) for their cooperation. 8. Disclaimer Caldera Systems, Inc. is not responsible for the misuse of any of the information we provide on this website and/or through our security advisories. Our advisories are a service to our customers intended to promote secure installation and use of Caldera OpenLinux. __ -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.0 (GNU/Linux) Comment: For info see http://www.gnupg.org iQCVAwUBODLqhun+9R4958LpAQGJhAP/QNQN3DZZuDOuJFAsTmZNpQ36L28xhfvm Ki2P3ILnVFKrfsYELP3c0HZmFI3JsLBC0F9HXBAnIbNo+SiMLounIwimT0oXaX62 OeTrqFqBVhCQAfXdD1ab2+Pp+/j1kBtRY8tYag7v6qmXoruj9i1lBcPtG35MiegZ ZDJmuOBgFxg= =b4rp -END PGP SIGNATURE-
From the SCO website
16th November 1999 Security patches for CA-99.14 in UnixWare 2.1.3 and 7.0.0 through 7.1.1 are now available. CA-99.14 is a CERT security advisory that addresses several security holes found in BIND versions earlier than 8.2.2-P3 (SSE033).
Re: FTGate vulnerability. (fwd)
Alfred Huger VP of Operations Security Focus -- Forwarded message -- Date: Thu, 11 Nov 1999 00:21:46 - From: Dom De Vitto [EMAIL PROTECTED] To: Alfred Huger [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: RE: FTGate vulnerability. Dom, I am not sure if anyone has responded to you yet, if not, please let me apologize, we are pretty busy here right now. Yea, I know busy, things fall through cracks all the time at my current contract, but they live with it and it's accepted I will take your notes into the description. Two questions, one do you want me to add your name to the credit list, I like to do this but some people get a little leary of it. Two, can I fwd this to Bugtraq? 1) I'm easy about getting credit, so if you want to credit me, that's fine. 2) I already sent this to _NT_Bugtraq, but I think my new (non list-reg'd address) confused the listbot, so I sent it direct to Russ too - no response as yet :( But feel free to redistribute anything I've written to anywhere. I'm one of the founders and moderators of comp.lang.c++.moderated, so I've had to make sure what I say is "suitable for public consumption", even if it's to private parties - assuming anyone can define 'private' nowadays... :( Thanks, and keep up the good work! Dom - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Dom De Vitto Secure Technologies Ltd. Mob. 07971 589 201 mailto:[EMAIL PROTECTED] Tel. 01202 738 767 http://www.devitto.com Fax. 08700 548 750 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Original Message----- From: Alfred Huger [mailto:[EMAIL PROTECTED]] Sent: Wednesday, November 10, 1999 8:43 PM To: Dom De Vitto Cc: [EMAIL PROTECTED] Subject: Re: FTGate vulnerability. Dom, I am not sure if anyone has responded to you yet, if not, please let me apologize, we are pretty busy here right now. I will take your notes into the description. Two questions, one do you want me to add your name to the credit list, I like to do this but some people get a little leary of it. Two, can I fwd this to Bugtraq? Nov 1999, Dom De Vitto wrote: Ref: http://www.securityfocus.com/level2/?go=vulnerabilitiesid=548 This problem was fixed in the next release v2.2, a long time ago. The SEVENTH v2.2 service release was released over a month ago, so this bug only effects very old FTGate installations. To solve this problem either upgrade your copy of FTGate to the current release (for free), or only bind the web interface to 'trusted' interfaces. I also think the USSR labs have taken unjustified credit for a bug discovered and fixed a long time ago by others - quite possibly by examining the 'bug fixed' list for the v2.2 release The real "impact" of this is that anyone is likely to be able to read anyone email, including incoming/outgoing mail. POP passwords are also available for those with *any* hacking skills at all... Dom PS. I have no relation to FTGate other than being a happy, freeware user - I'm running the "vulnerable" v2.1, but have always only bound the web server to 127.0.0.1... - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Dom De Vitto Secure Technologies Ltd. Mob. 07971 589 201 mailto:[EMAIL PROTECTED] Tel. 01202 738 767 http://www.devitto.com Fax. 08700 548 750 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Alfred Huger VP of Operations Security Focus BEGIN:VCARD VERSION:2.1 N:De Vitto;Domenico FN:Domenico De Vitto NICKNAME:Dom ORG:Secure Technologies Ltd. TITLE:Director TEL;WORK;VOICE:0797 1589 201 TEL;WORK;VOICE:01202 738 767 TEL;HOME;VOICE:01202 738 767 TEL;CELL;VOICE:0797 1589 201 TEL;WORK;FAX:0870 054 87 50 TEL;HOME;FAX:0870 054 87 50 TEL;HOME:0797 1589 201 ADR;WORK:;34 Farwell Road, Poole, Dorset. BH12 4PN. England.;34 Farwell Road,;Poole.;Dorset.;BH12 4PN;United Kingdom LABEL;WORK;ENCODING=QUOTED-PRINTABLE:34 Farwell Road, Poole, Dorset. BH12 4PN. England.=0D=0A34 Farwell Road,=0D= =0APoole., Dorset. BH12 4PN=0D=0AUnited Kingdom ADR;HOME:;;34 Farwell Road,;Poole.;Dorset.;BH12 4PN;United Kingdom LABEL;HOME;ENCODING=QUOTED-PRINTABLE:34 Farwell Road,=0D=0APoole., Dorset. BH12 4PN=0D=0AUnited Kingdom X-WAB-GENDER:2 URL: URL:http://www.devitto.com ROLE:General Technological Mischief BDAY:19721016 EMAIL;PREF;INTERNET:[EMAIL PROTECTED] EMAIL;INTERNET:[EMAIL PROTECTED] EMAIL;INTERNET:[EMAIL PROTECTED] REV:19990904T234548Z END:VCARD
SecurityFocus - reference: bugtraq id 689 (fwd)
-- Forwarded message -- Date: Tue, 5 Oct 1999 10:54:52 -0600 From: Doug Lemaire [EMAIL PROTECTED] To: "'[EMAIL PROTECTED]'" [EMAIL PROTECTED] Subject: SecurityFocus - reference: bugtraq id 689 A customer of ours pointed out that this item was in your database. http://www.securityfocus.com/level2/?go=vulnerabilities%26id=689 We have been aware of this issue for some time, and want to provide more information about it to your for your database. Our evaluation web server is generally used for a short time while customers are evaluating the software. Production systems should use IIS or Netscape Enterprise/FastTrack web servers, as you correctly reference and as we recommend to all our customers. Again, this Web server is installed and set up to be launched when TeamTrack is installed ONLY IF one of the recommended Web servers (IIS or Netscape Enterprise/FastTrack) is not already installed on the target computer, greatly minimizing the risk of the web server being enabled on a production computer. Notwithstanding the above, at TeamShare we take security very seriously. Even though this situation only manifests itself rarely, we have resolved the problem in our TeamTrack 4.0 software, entering beta now. This software version should be generally available during January 2000. In the meantime, customers and evaluators of the TeamTrack software can check to ensure that the TeamTrack Web Server is not running by disabling the TeamTrack Web Server service in Windows NT, and uninstalling the software from any Windows 95 or 98 computers not currently evaluating the software. Evaluations on all platforms can be performed using the Microsoft Personal Web Server, freely downloadable and without risk of this type of attack - instructions can be found in all readme files provided with the TeamTrack software, again, as correctly referenced in your on-line report. Please feel free to have customers contact our support department at mailto:[EMAIL PROTECTED] with any followup. Thank you for the service you provide - and for the prompt update of our information. Sincerely, Doug Lemaire Senior Software Engineer TeamShare, Inc.
Historical Bugtraq Question
Hey Folks, I am doing a little research on Bugtraq, it's history and the impact it's had on the community. I have a question for some of the listers here who have been onboard for a while. So far as I can tell, the first publicly released X86 buffer overflow w/ source code was the splitvt(1) exploit posted on Sun Dec 03 1995 as "Avalon Release". http://www.securityfocus.com/templates/archive.pike?list=1date=1995-11-29[EMAIL PROTECTED] It's my assertion that this code launched the buffer overflow into a commonly used exploit technique. In any event, I am looking for information refuting the 'first out' claim. Keep in mind I am not referring to anything other than X86 overflows (although I do not believe sparc eggs became public till after the splitvt code). Any input would be appreciated, I will post to the list when I have finished the research and compiled it into a paper for public consumption. Please reply directly to me.
I found this today and iam reporting it to you first!!! (fwd)
-- Forwarded message -- Date: Mon, 30 Aug 1999 21:08:14 +0200 From: Hakan Franzen [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: I found this today and iam reporting it to you first!!! Target: TFS mail system 4 (i think its working on earlier version aswell) (TFS just got some award about there security about emails) Company makes the product: www.tenfour.se OS: win95 98 nt Reported by: FableMan Noxidus a member of #HACK on IRCNet a DoS routine: Makes a FAST loop generating lts of emails until its forced to stop by admin. what i did is: TELNET TARGETSYSTEMRUNNING.TFS.MAIL.GATE.XXX 25 typing HELO typing MAIL FROM:FABLEMAN NOXIDUS RCPT TO:FIXYOUR [EMAIL PROTECTED] DATA Fix you system Error found by FableMan Noxidus a #HACK member of IRCNet . QUIT Thats all now the system tries to send to FIXYOUR [EMAIL PROTECTED] but that address is wrong soo then it generates a reporterror and mails to FABLEMAN NOXIDUS but cos i havent included a @ then i will not go out on internet then the loops starts.. its generating a reporterror and the loop is a truh.. I found it when i was playing around with a TFS mail gate system.. The speed of error report generation is about 1 or more email /sec soo if you start the loop and after 1 hr its a loot of email generated... until windows or NT hangs cos of it
SCO Patches
As taken from http://www.sco.com/security/ 4th November 1999 Security patches for CA-99.13 in OpenServer 5.0.0 through 5.0.5 have been released (SSE036). Also, a new OpenServer 5.0.0 through 5.0.5 patch has been released that fixes several security holes (SSE037).
