Re: [Full-disclosure] Remote log injection on DenyHosts, Fail2ban and BlockHosts
On Wed, Jun 06, 2007 at 05:13:54PM -0300, Daniel Cid wrote: DenyHosts, Fail2ban and BlockHosts are vulnerable to remote log injection that can lead to arbitrarily injection of IP addresses in /etc/hosts.deny. To make it more interesting, not only IP addresses can be added, but also the wild card all, causing it to block the whole Internet out of the box (bypassing white lists) -- see DenyHosts exploit example. These aren't exactly 0-day, I discussed several of these attacks last year, such as CVE-2006-6301, and informed the authors that there were undoubtedly more attacks against these tools. This topic is a favourite rant of mine, as the software itself is simply fundamentally flawed. Even unprivileged local users are usually permitted to create arbitrary log entries (eg, using logger), which will match any regex you can create. Even if that wasnt the case, obtaining data from untrusted sources, where remote unauthenticated attackers can manipulate the content with few restrictions, is clearly not a great idea. There are better options, such as just ignoring the log noise from these weak password scans. If you're concerned your users may select passwords that can be easily guessed, use cracklib, jtr, passwordqc, etc. This is a far superior solution. * No additional privileged code is exposed to remote attackers. * No risk of false positive banning legitimate users. * No number of bad logins need to be permitted before action. If you really do insist on parsing log entries created by remote unauthenticated users as root, and realise how dangerous that is, the only sane solution is to parse btmp (documented in utmp(5)). Thanks, Tavis. -- - [EMAIL PROTECTED] | finger me for my pgp key. --- ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] RUS-CERT 2007-06:01 (1380): Insecure Defaults in A-L OmniPCX 7.0
Dear all, for your information. RUS-CERT Security Announcement 2007-06:01 (1380) The built-in Mini Switch in Alcatel-Lucent's IP-Touch Telephones under OmniPCX Enterprise 7.0 and later Allows Un-Authenticated Access to the Voice VLAN in IEEE 802.1x-Authenticated Environments URL === This announcement is available at: http://cert.uni-stuttgart.de/advisories/al-ip-touch-vlan-filtering.php Synopsis Insecure default configurations in Alcatel-Lucent's Voice-over-IP Telephone System OmniPCX Enterprise Release 7.0 and later can be exploited to gain un-authenticated access to the voice VLAN through daisy chained computer systems. By default the mini switch built into the IP Touch telephone is enabled in a configuration vulnerable to the issue described in this document. Changing the configuration in a specific way remediates the problem. The scope of this document is limited to 802.1x- and 801.1q-enabled infrastructures. In scenarios not using 802.1x authentication, access to the voice VLAN is trivial. Extract === Affected: Alcatel-Lucent OmniPCX Enterprise Release 7.0 and later Impact: un-authenticated access to the Voice-VLAN Vector Class: mediately remote (see 'Attack Requirements' for details) Problem Class: insecure defaults Technical Risk: high Threat: medium CVSS: 6.2 CVE-Name: CVE-2007-2512 Vendor Status = Alcatel-Lucent was contacted in 02-2007 and the publication of this announcement was co-ordinated with A-L's PSIRT[7] and development department. Who Should Read this Document = * Users of Alcatel-Lucent OmniPCX Enterprise Release 7.0 and later operating Alcatel-Lucent IP Touch telephones in a network configuration that uses IEEE 802.1q (VLAN)[1] technology to separate voice and data traffic (VLAN segmentation) and IEEE 802.1x[4] authentication for IP Touch telephones. Affected Systems * Alcatel-Lucent OmniPCX Enterprise Release 7.0 and later with IEEE 802.1x authentication enabled and default configuration for the PC port of the mini switch integrated in IP Touch telephones. Not Affected Systems * Alcatel-Lucent OmniPCX Enterprise Release 7.0 and later when the PC port of the IP Touch telepone's mini switch either is configured to - 'disabled port' with no daisy-chained computer system or - 'filtering port' with a computer system is daisy-chained. Note: IEEE 802.1x is not implemented in earlier versions of OmniPCX Enterprise nor on OmniPCX Office. Attack Vector = * Mini switch in Alcatel-Lucent IP Touch telephone when daisy-chaining a IEEE 802.1q capable computer system Attack Requirements === * Physical access to the built-in mini switch in an Alcatel-Lucent IP Touch telephone; In a typical configuration this will be provided by a daisy-chained computer system. If this system is compromised, the attack can be performed remotely. * Improper configuration of the PC port state on the IP Touch's mini switch; This is the default. To successfully attack an infrastructure the following extra requirements must be met: * IEEE 801.1q VLAN segmentation must be used to separate the voice network from other networks * IEEE 802.1x authentication must be enabled to authenticate telephones and control their access to the voice VLAN Both technologies are recommended and commonly used in VoIP environments. Impact == * Un-authenticated access to the VLAN defined to separate voice traffic from data traffic Vulnerability Type == * insecure defaults Technical Risk == * high Threat == * medium Only installations featuring IEEE 802.1q and IEEE 802.1x to separate the voice infrastructure from other networks and IP-Touch telephones with an improperly configured built-in mini switch are affected. See http://cert.uni-stuttgart.de/advisories/rating.php for RUS-CERT's risk and threat rating. CVSS Rating === CVSS Base Score 7 CVSS Temporal Score 5.8 CVSS Environmental Score 6.2 Overall CVSS Score6.2 Base Score Metrics -- Related exploit range (AccessVector) Remote 1) Attack complexity (AccessComplexity) Low Level of authentication needed (Authentication) Not Required Confidentiality impact (ConfImpact) Partial Integrity impact (IntegImpact)Partial Availability impact (AvailImpact) Partial Impact value weighting (ImpactBias) Weight Availability 1) In a scenario with a compromised computer system that is daisy-chained to a telephone this vulnerability can be expoited remotely. Technical Context
[Full-disclosure] XSS in Space4k.[pl|fr|com|de|it]
Application: Space4k Web Site: http://www.space4k.[pl|fr|com|de|it] Bug: XSS (Cross site Scripting) Discoverer: Florian Stinglmayr Date: 2007-06-07 -- Description: Space4K is a massive multiplayer online game game which can be played via the browser. Space4k has several divisions for different countries, e.g. .de for German speaking users, .com for English speaking countries and so forth. Space4k is being developed by GameForge AG. Flaw: = The login.php has a GET variable named error which is used to display a string to the user in case of an error, e.g. Username wrong.. This variable is being send to the user without proper sanitizing. A malicious user is able to include arbitrary HTML/Javascript by using this variable. POC: http://space4k.com/space/login.php?error=%3Cscript%3Ealert(23);%3C/script%3E http://space4k.de/space/login.php?error=%3Cscript%3Ealert(23);%3C/script%3E http://space4k.fr/space/login.php?error=%3Cscript%3Ealert(23);%3C/script%3E http://space4k.it/space/login.php?error=%3Cscript%3Ealert(23);%3C/script%3E http://space4k.pl/space/login.php?error=%3Cscript%3Ealert(23);%3C/script%3E Vulnerable Sites: = http://www.space4k.de http://www.space4k.com http://www.space4k.fr http://www.space4k.it http://www.space4k.pl Regards, Florian Stinglmayr ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] You shady bastards.
[ [-- [ [Message: 2 [Date: Wed, 6 Jun 2007 20:23:25 -0400 [From: Larry Seltzer [EMAIL PROTECTED] [Subject: Re: [Full-disclosure] You shady bastards. [To: full-disclosure@lists.grok.org.uk [Message-ID: [ [EMAIL PROTECTED] [Content-Type: text/plain; charset=us-ascii [ [A more ethical company would have sent HDM a polite note saying that [the person no longer works there before curiosity got the best of them. [ [Does your company do this for all former employee e-mail accounts? [ [Let's hope he unsubscribed from all his mailing lists before he left. [ [Larry Seltzer [eWEEK.com Security Center Editor [http://security.eweek.com/ [http://blogs.eweek.com/cheap_hack/ [Contributing Editor, PC Magazine [EMAIL PROTECTED] [ [ [ [-- [ Problem here is that most of the time you are escorted out. Not much time to erase tracks. ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] You shady bastards.
The key is *personal* e-mail. It's not unreasonable for any company to assume their e-mail systems are used primarily for business purposes. The e-mail doesn't indicate it's personal. It doesn't say, Your Ghonorrhea test results have come back! Click here for the results. The e-mail has no contents other than a link and doesn't indicate that the Zero Day promise was made after this employee left the company. In fact, the subject Zero Day is directly related to SecureWork's business and it's entirely reasonable to expect a security company to investigate the contents. I'm actually surprised someone actually monitors these accounts and took the time to look into it! On Wed, 06 Jun 2007 20:28:26 -0400 security curmudgeon [EMAIL PROTECTED] wrote: : A more ethical company would have sent HDM a polite note saying that : the person no longer works there before curiosity got the best of them. : : Does your company do this for all former employee e-mail accounts? No. But they also don't continue to accept mail to those accounts either. : Let's hope he unsubscribed from all his mailing lists before he left. If a company is going to continue monitoring a former employee's mailbox (intentionally or via a 'catch all'), that is fine. But when they specifically act on a personal private mail between someone outside of their company and the former employee, they are crossing the line of ethical behavior I think. As I said, the least they should have done is mail HDM and notified him the person no longer works there. If they didn't do that, and if you think they shouldn't be required to, then they shouldn't act on the information in the mail either. ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ -- Click to become a master chef, own a restaurant and make millions http://tagline.hushmail.com/fc/CAaCXv1QhbNmqK0ynJatT1qFQMwOiVRg/ ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] You shady bastards.
On Wednesday 06 June 2007 11:06, Tim wrote: Sorry H.D., it most likely isn't illegal. I agree. But still sleazy. cheers, --dr ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Fw: [IACIS-L] Statement by Defense Expert
[EMAIL PROTECTED] wrote: So I take it that law enforcement computer examiners and prosecutors *do* have the years of experience in software engineering and exploit construction and use, to qualify them to translate a bit of data into forensic evidence of guilt? Catch 22. This is why prosecutors often rely on expert witnesses who even then are lacking. One of the things many omit in their methods of thinking when it comes to perhaps going to trial is the following, and please take it very seriously... Will the JURY understand it first and foremost, secondly will the jury even give a rats ass. From experience, 1) the jury WILL NOT understand even 1/2 of the terminology nor concepts, analogies you can throw at them. This works to the benefit of whichever side is willing to exploit the jurors. Overwhelm them with so much technology they'll have to believe the accused is guilty. After all, why bring in all of these *experts* (for the prosecution). Overwhelm them with so much technology to counter the former experts expertise and throw in doubt... For the defense. On the latter... While guilty until proven innocent is the American dream, it is seldomly practiced. If so there would be no need for bail since the defendant is after all innocent. (Bottom line holding true to the letter of the law... Not practical but this concept of innocent until proven guilty is flawed). Anyhow, if one were to find themselves on trial this is what you SHOULD expect... You will get a jury of your so called peers.. So let's define peer: Noun 1. peer - a person who is of equal standing with another in a group. Your peers will never be in equal standing from a technological perspective period. For one, it would take a miracle to gather a bunch of computer literate users for jury duty. Heck you will likely find 0 even if one appears for jury duty, it is likely the prosecution will try to rid this person from selection. Its not in their best interest to have someone fully technical on trial for a few reasons. 1) The juror might associate his experiences with the case being tried and taint an outcome based on HIS experience, not the facts presented. Would be the main reason. It might not be in the best interest of the defendant for the same reason. No sir, your peer will consist of someone who's likely going to be computer illiterate, likely twice your age, etc., they'll 1) be frustrated they have to go through jury duty and want to get things over with to return to normal life. 2) They'll be looking like a deer in headlights trying to understand what the hell an expert is talking about: SMTP is a protocol used to deliver electronic mail. This mail consists of binary zeros and ones which when converted formed a corrupted gif image which caused Microsoft's Windows Small Business Server to suffer a buffer overflow. Might sound like clockwork to anyone here, but will sound Klingon to a juror. I could go on and on... But one should be able to envision the possibilities of jurors being lost and irrate. I may or may not do a write up based on my case, but that is likely going to irritate a lot of federal agents and it will likely mean I will end up posting my case files online which will further piss off more federal agents and perhaps place me back to square one. Who knows maybe I will discuss this with an attorney beforehand. Lest I face the wrath of again breaking into an employer while on an airplane. But hey... An expert can always be called in on my defense on how it would have been impossible to spoof over the Atlantic Ocean... Then again, a counterexpert could show the possibility of me hijacking satellite after satellite after satellite for said connection to leave a teasing message saying... Hi I pwnd you for shits and giggles. -- J. Oquendo http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x1383A743 echo infiltrated.net|sed 's/^/sil@/g' Wise men talk because they have something to say; fools, because they have to say something. -- Plato smime.p7s Description: S/MIME Cryptographic Signature ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] You shady bastards.
Any company email adress is primarily intended for company related issues. Even the company in question allows you to use it for personal issues, it's still mainly intented for company use. An email adressed to, up until recently employed, security researcher, HR drone or sales assistant, Elmer Fudd using his company email [EMAIL PROTECTED] must be seen as adressed to this person in his position at the company, not to him as a person. If he for some reason can't take care of it, it's obvious that the company must take care of the message, usually by the individual who is covering for him (or replacing him). If you want to send a message to a specific individual, not a position at a company, then use his (or hers) personal adress. // hdw [EMAIL PROTECTED] wrote: The key is *personal* e-mail. It's not unreasonable for any company to assume their e-mail systems are used primarily for business purposes. The e-mail doesn't indicate it's personal. It doesn't say, Your Ghonorrhea test results have come back! Click here for the results. The e-mail has no contents other than a link and doesn't indicate that the Zero Day promise was made after this employee left the company. In fact, the subject Zero Day is directly related to SecureWork's business and it's entirely reasonable to expect a security company to investigate the contents. I'm actually surprised someone actually monitors these accounts and took the time to look into it! ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Fw: [IACIS-L] Statement by Defense Expert
Ayup, true enough re jury confusion. Once a machine has had a malware infection though, the point a layman needs to understand is simply: it is not possible in under (a large number, maybe 1000) man years) to determine that the machine has not been remotely controllable if connected to an outside net. Further it is not possible to say with certainty that an apparently clean machine, so connected, has not been infected in the past by something that removed its traces. One is left with probabilities. If for example I am looking for a worm author and find on his computer lots of partial code, edited versions of the worm, and maybe the final one, compilers etc., while it is possible these were inserted by an evil outsider, I might reckon that local creation is more likely. If all I find is a cache of warez, nasty pictures etc., and some server running, it is harder to exclude the idea the box might be in use by an evildoer as a hiding place for material the outsider is unwilling to risk serving out himself. As long as experts are suitably modest about what they can know, and explain the probabilities honestly all could be well. The more of these elderly jury selectees that are informed ahead of time about the limits of what can be found, the better. The story about Mr. Ballmer (Microsoft CEO) having a box infected, taking it to work to get it cleaned, and having all the experts he could access be unable to clean it save by wiping and reloading, may be a useful one to spread to said jury pool folks. It makes it clear the level of expertise and time needed to clean a box up, suggesting that Mr. 20something-self-proclaimed-forensic-guy who swears there could never have been external meddling on this box might be just a tad out of his depth. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of J. Oquendo Sent: Thursday, June 07, 2007 8:42 AM To: [EMAIL PROTECTED] Cc: Full Disclosure; Jason Coombs Subject: Re: [Full-disclosure] Fw: [IACIS-L] Statement by Defense Expert [EMAIL PROTECTED] wrote: So I take it that law enforcement computer examiners and prosecutors *do* have the years of experience in software engineering and exploit construction and use, to qualify them to translate a bit of data into forensic evidence of guilt? Catch 22. This is why prosecutors often rely on expert witnesses who even then are lacking. One of the things many omit in their methods of thinking when it comes to perhaps going to trial is the following, and please take it very seriously... Will the JURY understand it first and foremost, secondly will the jury even give a rats ass. From experience, 1) the jury WILL NOT understand even 1/2 of the terminology nor concepts, analogies you can throw at them. This works to the benefit of whichever side is willing to exploit the jurors. Overwhelm them with so much technology they'll have to believe the accused is guilty. After all, why bring in all of these *experts* (for the prosecution). Overwhelm them with so much technology to counter the former experts expertise and throw in doubt... For the defense. On the latter... While guilty until proven innocent is the American dream, it is seldomly practiced. If so there would be no need for bail since the defendant is after all innocent. (Bottom line holding true to the letter of the law... Not practical but this concept of innocent until proven guilty is flawed). Anyhow, if one were to find themselves on trial this is what you SHOULD expect... You will get a jury of your so called peers.. So let's define peer: Noun 1. peer - a person who is of equal standing with another in a group. Your peers will never be in equal standing from a technological perspective period. For one, it would take a miracle to gather a bunch of computer literate users for jury duty. Heck you will likely find 0 even if one appears for jury duty, it is likely the prosecution will try to rid this person from selection. Its not in their best interest to have someone fully technical on trial for a few reasons. 1) The juror might associate his experiences with the case being tried and taint an outcome based on HIS experience, not the facts presented. Would be the main reason. It might not be in the best interest of the defendant for the same reason. No sir, your peer will consist of someone who's likely going to be computer illiterate, likely twice your age, etc., they'll 1) be frustrated they have to go through jury duty and want to get things over with to return to normal life. 2) They'll be looking like a deer in headlights trying to understand what the hell an expert is talking about: SMTP is a protocol used to deliver electronic mail. This mail consists of binary zeros and ones which when converted formed a corrupted gif image which caused Microsoft's Windows Small Business Server to suffer a buffer overflow. Might sound like clockwork to anyone here, but will sound Klingon to a
Re: [Full-disclosure] Remote log injection on DenyHosts, Fail2ban and BlockHosts
Hi Tavis, Reply inline. On 6/7/07, Tavis Ormandy [EMAIL PROTECTED] wrote: These aren't exactly 0-day, I discussed several of these attacks last year, such as CVE-2006-6301, and informed the authors that there were undoubtedly more attacks against these tools. This topic is a favourite rant of mine, as the software itself is simply fundamentally flawed. These log injection attacks are nothing new, I know, but what CVE-2006-6301 and CVE-2006-6302 talks about are injecting the ip address in the user name field. Both fail2ban and denyhosts were patched against it, but what I used was the bad protocol log message to inject the data (as I say in the article). So, well, I think it is 0-day, since these tools were still vulnerable and patches were just released: http://www.aczoom.com/tools/blockhosts/CHANGES http://www.ossec.net/en/attacking-loganalysis.html#patches Also, I showed that instead of just inserting arbitrary IP addresses to the hosts.deny file, you can also add the all keyword, causing the box to be completely locked (bypassing access lists). Even unprivileged local users are usually permitted to create arbitrary log entries (eg, using logger), which will match any regex you can create. Even if that wasnt the case, obtaining data from untrusted sources, where remote unauthenticated attackers can manipulate the content with few restrictions, is clearly not a great idea. That's the very flawed concept of IDS (or IPS). Where you obtain data from untrusted sources and report the attackers or in the case of IPS, block them. Theorically, you can do the same think with NIPS, by attacking specific udp signatures (or tcp ones that do not require the full handshake) and blocking fake ip addresses. But that's not the point of discussion, since I agree with you (it is very dangerous). Every form of automated response have serious risks. There are better options, such as just ignoring the log noise from these weak password scans. If you're concerned your users may select passwords that can be easily guessed, use cracklib, jtr, passwordqc, etc. This is a far superior solution. * No additional privileged code is exposed to remote attackers. * No risk of false positive banning legitimate users. * No number of bad logins need to be permitted before action. If you really do insist on parsing log entries created by remote unauthenticated users as root, and realise how dangerous that is, the only sane solution is to parse btmp (documented in utmp(5)). That's a good solution, no doubt about it. Regarding parsing utmp, the issue is that you can not do it from a centralized location, which you can with your syslog (not that syslog is any safer, but that's another issue too). Thanks, Tavis. Thanks, -- Daniel B. Cid dcid ( at ) ossec.net ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] [CAID 35395, 35396]: CA Anti-Virus Engine CAB File Buffer Overflow Vulnerabilities
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Title: [CAID 35395, 35396]: CA Anti-Virus Engine CAB File Buffer Overflow Vulnerabilities CA Vuln ID (CAID): 35395, 35396 CA Advisory Date: 2007-06-05 Reported By: ZDI Impact: Remote attackers can cause a denial of service or potentially execute arbitrary code. Summary: CA Anti-Virus engine contains multiple vulnerabilities that can allow a remote attacker to cause a denial of service or possibly execute arbitrary code. CA has issued an update to address the vulnerabilities. The first vulnerability, CVE-2007-2863, is due to insufficient bounds checking on filenames contained in a CAB archive. The second vulnerability, CVE-2007-2863, is due to insufficient bounds checking on the coffFiles field. By using a specially malformed CAB file, an attacker can cause a crash or take unauthorized action on an affected system. Mitigating Factors: None Severity: CA has given these vulnerabilities a High risk rating. Affected Products: CA Anti-Virus for the Enterprise (formerly eTrust Antivirus) r8, r8.1 CA Anti-Virus 2007 (v8) eTrust EZ Antivirus r7, r6.1 CA Internet Security Suite 2007 (v3) eTrust Internet Security Suite r1, r2 eTrust EZ Armor r1, r2, r3.x CA Threat Manager for the Enterprise (formerly eTrust Integrated Threat Management) r8 CA Protection Suites r2, r3 CA Secure Content Manager (formerly eTrust Secure Content Manager) 8.0 CA Anti-Virus Gateway (formerly eTrust Antivirus eTrust Antivirus Gateway) 7.1 Unicenter Network and Systems Management (NSM) r3.0 Unicenter Network and Systems Management (NSM) r3.1 Unicenter Network and Systems Management (NSM) r11 Unicenter Network and Systems Management (NSM) r11.1 BrightStor ARCserve Backup r11.5 BrightStor ARCserve Backup r11.1 BrightStor ARCserve Backup r11 for Windows BrightStor Enterprise Backup r10.5 BrightStor ARCserve Backup v9.01 CA Common Services CA Anti-Virus SDK (formerly eTrust Anti-Virus SDK) Affected Platforms: All Status and Recommendation: CA has issued content update 30.6 to address the vulnerabilities. The updated engine is provided with content updates. Ensure the latest content update is installed if the signature version is less than version 30.6. For BrightStor ARCserve Backup: 1. To update the signatures one time only, open a command window, change into the C:\Program Files\CA\SharedComponents\ScanEngine directory, and enter the following command: inodist /cfg inodist.ini 2. To update on a regular schedule: * Submit a GenericJob using the ARCserve Job Scheduler. Please search the BrightStor Administrator's Guide for 'Antivirus Maintenance' and follow the directions. Or * Use the above command line instruction with the AT Scheduler. Workaround: None References (URLs may wrap): CA SupportConnect: http://supportconnect.ca.com/ CA SupportConnect Security Notice for this vulnerability: Security Notice for CA products implementing the Anti-Virus engine http://supportconnectw.ca.com/public/antivirus/infodocs/caantivirus-securit ynotice.asp CA Security Advisor posting: CA Anti-Virus Engine CAB File Buffer Overflow Vulnerabilities http://www.ca.com/us/securityadvisor/newsinfo/collateral.aspx?cid=144680 CAID: 35395, 35396 http://www.ca.com/us/securityadvisor/vulninfo/vuln.aspx?id=35395 http://www.ca.com/us/securityadvisor/vulninfo/vuln.aspx?id=35396 Reported By: ZDI ZDI Advisory: ZDI-07-034, ZDI-07-035 http://www.zerodayinitiative.com/advisories/ZDI-07-034.html http://www.zerodayinitiative.com/advisories/ZDI-07-035.html CVE References: CVE-2007-2863, CVE-2007-2864 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-2863 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-2864 OSVDB References: OSVDB-35244, OSVDB-35245 http://osvdb.org/35244 http://osvdb.org/35245 Changelog for this advisory: v1.0 - Initial Release Customers who require additional information should contact CA Technical Support at http://supportconnect.ca.com. For technical questions or comments related to this advisory, please send email to vuln AT ca DOT com. If you discover a vulnerability in CA products, please report your findings to vuln AT ca DOT com, or utilize our Submit a Vulnerability form. URL: http://www.ca.com/us/securityadvisor/vulninfo/submit.aspx Regards, Ken Williams ; 0xE2941985 Director, CA Vulnerability Research CA, 1 CA Plaza, Islandia, NY 11749 Contact http://www.ca.com/us/contact/ Legal Notice http://www.ca.com/us/legal/ Privacy Policy http://www.ca.com/us/privacy/ Copyright (c) 2007 CA. All rights reserved. -BEGIN PGP SIGNATURE- Version: PGP Desktop 9.5.3 (Build 5003) wj8DBQFGaCeieSWR3+KUGYURAjhzAJ9YE7QIAvaDm/R7TOg96YXiNvSNpQCfQ0Qo FcIXmbHI7BXaL4/AegsbRf8= =EGDi -END PGP SIGNATURE- ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Yahoo 0day ActiveX Webcam Exploit
cannot reproduce.. yahoo IM versions 6.0.0.1922 8.1.0.249 DCE2F8B1-A520-11D4-8FD0-00D0B7730277 ywcupl.dll versions 2.0.1.2 and 2.0.1.4 9D39223E-AE8E-11D4-8FD3-00D0B7730277 ywcvwr.dll versions 2.0.1.3 and 2.0.1.4 ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] [SECURITY] [DSA 1299-1] New ipsec-tools packages fix denial of service
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - --- Debian Security Advisory DSA 1299-1[EMAIL PROTECTED] http://www.debian.org/security/ dann frazier June 7th, 2007 http://www.debian.org/security/faq - --- Package: ipsec-tools Vulnerability : missing input sanitising Problem-Type : remote Debian-specific: no CVE ID : CVE-2007-2524 It was discovered that a specially-crafted packet sent to the racoon ipsec key exchange server could cause a tunnel to crash, resulting in a denial of service. The oldstable distribution (sarge) isn't affected by this problem. For the stable distribution (etch) this problem has been fixed in version 1:0.6.6-3.1. The unstable distribution (sid) will be fixed soon. We recommend that you upgrade your racoon package. Upgrade Instructions - - wget url will fetch the file for you dpkg -i file.deb will install the referenced file. If you are using the apt-get package manager, use the line for sources.list as given below: apt-get update will update the internal database apt-get upgrade will install corrected packages You may use an automated update by adding the resources from the footer to the proper configuration. Debian GNU/Linux 4.0 alias etch - Source archives: http://security.debian.org/pool/updates/main/i/ipsec-tools/ipsec-tools_0.6.6-3.1etch1.dsc Size/MD5 checksum: 714 8b0036099ce66a7cbe83e54d0b904af2 http://security.debian.org/pool/updates/main/i/ipsec-tools/ipsec-tools_0.6.6-3.1etch1.diff.gz Size/MD5 checksum:49981 087edd1d11957b09b2171900a9b11861 http://security.debian.org/pool/updates/main/i/ipsec-tools/ipsec-tools_0.6.6.orig.tar.gz Size/MD5 checksum: 914807 643a238e17148d242c603c511e28d029 Alpha architecture: http://security.debian.org/pool/updates/main/i/ipsec-tools/ipsec-tools_0.6.6-3.1etch1_alpha.deb Size/MD5 checksum:97060 2532ce5a61a9ddda86d2dc2b6c2fee0d http://security.debian.org/pool/updates/main/i/ipsec-tools/racoon_0.6.6-3.1etch1_alpha.deb Size/MD5 checksum: 376370 d20d19e5fa8943b80a1a5678044e578c AMD64 architecture: http://security.debian.org/pool/updates/main/i/ipsec-tools/ipsec-tools_0.6.6-3.1etch1_amd64.deb Size/MD5 checksum:89052 8ff0a34a1fca0e232edcee6827233760 http://security.debian.org/pool/updates/main/i/ipsec-tools/racoon_0.6.6-3.1etch1_amd64.deb Size/MD5 checksum: 341854 44f25a0b80eb783aa1c8f6a971ca237d ARM architecture: http://security.debian.org/pool/updates/main/i/ipsec-tools/ipsec-tools_0.6.6-3.1etch1_arm.deb Size/MD5 checksum:89788 d5378073f43820e820d5abfab4ea19ac http://security.debian.org/pool/updates/main/i/ipsec-tools/racoon_0.6.6-3.1etch1_arm.deb Size/MD5 checksum: 325002 fc60192e280377c8d802827fb35e9ccf HP Precision architecture: http://security.debian.org/pool/updates/main/i/ipsec-tools/ipsec-tools_0.6.6-3.1etch1_hppa.deb Size/MD5 checksum:93882 6a44a4a6f99bd607c47b993eb02ede0a http://security.debian.org/pool/updates/main/i/ipsec-tools/racoon_0.6.6-3.1etch1_hppa.deb Size/MD5 checksum: 354128 130b95fb7d817148acc080b87d650033 Intel IA-32 architecture: http://security.debian.org/pool/updates/main/i/ipsec-tools/ipsec-tools_0.6.6-3.1etch1_i386.deb Size/MD5 checksum:84608 a5ae0d2e2a6c804a7bc28bd78b89b9a8 http://security.debian.org/pool/updates/main/i/ipsec-tools/racoon_0.6.6-3.1etch1_i386.deb Size/MD5 checksum: 329946 ecf6c9f4b86fa32b24ef7d395ec786bc Intel IA-64 architecture: http://security.debian.org/pool/updates/main/i/ipsec-tools/ipsec-tools_0.6.6-3.1etch1_ia64.deb Size/MD5 checksum: 113136 8bda8ebe0253f6a122ed55ae5594061c http://security.debian.org/pool/updates/main/i/ipsec-tools/racoon_0.6.6-3.1etch1_ia64.deb Size/MD5 checksum: 467976 f10fd34a1511d2115429a07aa66c9505 Big endian MIPS architecture: http://security.debian.org/pool/updates/main/i/ipsec-tools/ipsec-tools_0.6.6-3.1etch1_mips.deb Size/MD5 checksum:89766 66e65d7dd8997376ec87419b9e578635 http://security.debian.org/pool/updates/main/i/ipsec-tools/racoon_0.6.6-3.1etch1_mips.deb Size/MD5 checksum: 344828 091f455c5364c6e086ccf3bab88b118d Little endian MIPS architecture: http://security.debian.org/pool/updates/main/i/ipsec-tools/ipsec-tools_0.6.6-3.1etch1_mipsel.deb Size/MD5 checksum:90078 23c815af2dd3b8caafbf51a36cc10f7e http://security.debian.org/pool/updates/main/i/ipsec-tools/racoon_0.6.6-3.1etch1_mipsel.deb Size/MD5 checksum: 346628 c31717b5c9d124fb762dd6bff3f05179 PowerPC architecture:
[Full-disclosure] You STUPID bastards.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 what's more stupid? a bunch of l33+ defcon security conference attendees too stupid to read a distribution list before sending sentive information or stupid rantings about big bad capitalistic corporations? - --- “You don't have to be a man to fight for freedom. All you have to do is to be an intelligent human being.” - Malcolm X On Jun 6, 2007, at 9:47 AM, H D Moore wrote: Hello, Some friends and I were putting together a contact list for the folks attending the Defcon conference this year in Las Vegas. My friend sent out an email, with a large CC list, asking people to respond if they planned on attending. The email was addressed to quite a few people, with one of them being David Maynor. Unfortunately, his old SecureWorks address was used, not his current address with ErrattaSec. Since one of the messages sent to the group contained a URL to our phone numbers and names, I got paranoid and decided to determine whether SecureWorks was still reading email addressed to David Maynor. I sent an email to David's old SecureWorks address, with a subject line promising 0-day, and a link to a non-public URL on the metasploit.com web server (via SSL). Twelve hours later, someone from a Comcast cable modem in Atlanta tried to access the link, and this someone was (confirmed) not David. SecureWorks is based in Atlanta. All times are CDT. I sent the following message last night at 7:02pm. --- From: H D Moore hdm[at]metasploit.com To: David Maynor dmaynor[at]secureworks.com Subject: Zero-day I promised Date: Tue, 5 Jun 2007 19:02:11 -0500 User-Agent: KMail/1.9.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: 200706051902.11544.hdm[at]metasploit.com Status: RO X-Status: RSC https://metasploit.com/maynor.tar.gz --- Approximately 12 hours later, the following request shows up in my Apache log file. It looks like someone at SecureWorks is reading email addressed to David and tried to access the link I sent: 71.59.27.152 - - [05/Jun/2007:19:16:42 -0500] GET /maynor.tar.gz HTTP/1.1 404 211 - Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en) AppleWebKit/419 (KHTML, like Gecko) Safari/419.3 This address resolves to: c-71-59-27-152.hsd1.ga.comcast.net The whois information is just the standard Comcast block boilerplate. --- Is this illegal? I could see reading email addressed to him being within the bounds of the law, but it seems like trying to download the 0day link crosses the line. Illegal or not, this is still pretty damned shady. Bastards. -HD ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ -BEGIN PGP SIGNATURE- Note: This signature can be verified at https://www.hushtools.com/verify Version: Hush 2.5 wpwEAQECAAYFAkZoYx8ACgkQK43TUsmw8Z650AP+M/d1QSqTtgxRpu0rwP1Jw5Fw8QjU qyfVdtm1IqIGbcQwdq425aBE0o24pVxqtcuYkfrEtSZjfdcEyD1SoTq0Vtb1DYXj4bMe rDO0m2d5ucYIRFoK5339Zgq8TfDMzDyFZBhLhx5fbk2DxGnzg+WDDzC6mRTW3ysX9qko ENVCDM4= =34Y6 -END PGP SIGNATURE- Get your free encrypted email at http://www.cyber-rights.net ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] [SECURITY] [DSA 1300-1] New iceape packages fix several vulnerabilities
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - -- Debian Security Advisory DSA 1300-1[EMAIL PROTECTED] http://www.debian.org/security/ Moritz Muehlenhoff June 7th, 2007 http://www.debian.org/security/faq - -- Package: iceape Vulnerability : several Problem-Type : remote Debian-specific: no CVE ID : CVE-2007-1362 CVE-2007-1558 CVE-2007-2867 CVE-2007-2868 CVE-2007-2870 CVE-2007-2871 Several remote vulnerabilities have been discovered in the Iceape internet suite, an unbranded version of the Seamonkey Internet Suite. The Common Vulnerabilities and Exposures project identifies the following problems: CVE-2007-1362 Nicolas Derouet discovered that Iceape performs insufficient validation of cookies, which could lead to denial of service. CVE-2007-1558 Gatan Leurent discovered a cryptographical weakness in APOP authentication, which reduces the required efforts for an MITM attack to intercept a password. The update enforces stricter validation, which prevents this attack. CVE-2007-2867 Boris Zbarsky, Eli Friedman, Georgi Guninski, Jesse Ruderman, Martijn Wargers and Olli Pettay discovered crashes in the layout engine, which might allow the execution of arbitrary code. CVE-2007-2868 Brendan Eich, Igor Bukanov, Jesse Ruderman, moz_bug_r_a4 and Wladimir Palant discovered crashes in the javascript engine, which might allow the execution of arbitrary code. CVE-2007-2870 moz_bug_r_a4 discovered that adding an event listener through the addEventListener() function allows cross-site scripting. CVE-2007-2871 Chris Thomas discovered that XUL popups can can be abused for spoofing or phishing attacks. Fixes for the oldstable distribution (sarge) are not available. While there will be another round of security updates for Mozilla products, Debian doesn't have the ressources to backport further security fixes to the old Mozilla products. You're strongly encouraged to upgrade to stable as soon as possible. For the stable distribution (etch) these problems have been fixed in version 1.0.9-0etch1. A build for the arm architecture is not yet available, it will be provided later. The unstable distribution (sid) will be fixed soon. We recommend that you upgrade your iceape packages. Upgrade Instructions - wget url will fetch the file for you dpkg -i file.deb will install the referenced file. If you are using the apt-get package manager, use the line for sources.list as given below: apt-get update will update the internal database apt-get upgrade will install corrected packages You may use an automated update by adding the resources from the footer to the proper configuration. Debian GNU/Linux 4.0 alias etch - --- Source archives: http://security.debian.org/pool/updates/main/i/iceape/iceape_1.0.9-0etch1.dsc Size/MD5 checksum: 1403 fac51ae60382306a1f5937d393cad9b8 http://security.debian.org/pool/updates/main/i/iceape/iceape_1.0.9-0etch1.diff.gz Size/MD5 checksum: 265235 f0632d0ab1011723516b42ddc3fbf077 http://security.debian.org/pool/updates/main/i/iceape/iceape_1.0.9.orig.tar.gz Size/MD5 checksum: 42936008 f3f2409c45e5e48124159f71c3f305db Architecture independent components: http://security.debian.org/pool/updates/main/i/iceape/iceape-chatzilla_1.0.9-0etch1_all.deb Size/MD5 checksum: 278514 abeb91d6d747fbd2a2dc4c53a0c1b730 http://security.debian.org/pool/updates/main/i/iceape/iceape-dev_1.0.9-0etch1_all.deb Size/MD5 checksum: 3655228 aeaa72117bdef3db570d175294003567 http://security.debian.org/pool/updates/main/i/iceape/iceape_1.0.9-0etch1_all.deb Size/MD5 checksum:27642 2c103331d2f75caab26dc5c5c5b53db5 http://security.debian.org/pool/updates/main/i/iceape/mozilla-browser_1.8+1.0.9-0etch1_all.deb Size/MD5 checksum:27172 6461173091e780104247676063370dd4 http://security.debian.org/pool/updates/main/i/iceape/mozilla-calendar_1.8+1.0.9-0etch1_all.deb Size/MD5 checksum:26244 3a26fad0fccac9cb3f0a3826eaba0398 http://security.debian.org/pool/updates/main/i/iceape/mozilla-chatzilla_1.8+1.0.9-0etch1_all.deb Size/MD5 checksum:26258 6c114441ed304d22a68626e641714a32 http://security.debian.org/pool/updates/main/i/iceape/mozilla-dev_1.8+1.0.9-0etch1_all.deb Size/MD5 checksum:26380 36e2977fd80cdf0e5132d3e5d3d7566f http://security.debian.org/pool/updates/main/i/iceape/mozilla-dom-inspector_1.8+1.0.9-0etch1_all.deb Size/MD5 checksum:26280 4f803f93ba3146cf3568a8255d7ff1ce http://security.debian.org/pool/updates/main/i/iceape/mozilla-js-debugger_1.8+1.0.9-0etch1_all.deb Size/MD5
Re: [Full-disclosure] Yahoo 0day ActiveX Webcam Exploit
What's the point of a disclosure you can't reproduce? aaargh, pest! On 07/06/07, Morning Wood [EMAIL PROTECTED] wrote: cannot reproduce.. yahoo IM versions 6.0.0.1922 8.1.0.249 DCE2F8B1-A520-11D4-8FD0-00D0B7730277 ywcupl.dll versions 2.0.1.2 and 2.0.1.4 9D39223E-AE8E-11D4-8FD3-00D0B7730277 ywcvwr.dll versions 2.0.1.3 and 2.0.1.4 ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ -- Ronald MacDonald http://www.rmacd.com/ 0777 235 1655 ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] Second Call for Papers: DeepSec IDSC 2007 Europe/Vienna: 20-23 Nov 2007
DeepSec In-Depth Security Conference 2007 Europe - Nov 20-23 2007 - Vienna, Austria http://deepsec.net/ Second Call for Papers We're inviting you to submit papers and proposals for trainings for the first annual DeepSec security conference. We've been able to get some really good submissions, fantastic keynotes, and extremely interesting invited talks so far, and are hoping we'll get even more exciting talks during the final phases of the CFP. We're especially interested in getting more non-web talks! Dudes - stop submitting basic ajax, web2.0 and voip security talks already, we're flooded by these! We still want to get more submissions and case studies of government project security (egovernment, electronic health/citizen cards, electronic passports, i- and evoting security, inter-government protocols, ...), and also more submissions on secure software development, rootkits, forensics, and the security of popular but seldom discussed protocols. We've managed to come up with a really nice social programme around the conference. Among other things, there'll be Capture the Flag and Live Web Hacking contests organized by the Hack in the Box team, exciting evening action at our partner event, the RoboExotica Cocktail-Robotics Festival, and a thrilling speakers after-party at Vienna's top hacker club, the Metalab. We're sure this will be a conference experience that you'll remember! So submit your talks and trainings now and don't miss the action! :) All proposals received before June 16th 2007, 23:59 CET will be considered by the Program Committee. == About DeepSec == DeepSec IDSC is an annual European two-day in-depth Conference on Computer-, Network-, and Application-Security. The first DeepSec Conference will be held from November 22nd to 23rd 2007 in Vienna, and aims to bring together the leading security experts from all over the world in Europe. In addition to the conference with thirty-two sessions, four two-day intense security training courses will be held before the main conference. The conference program will be augmented with a live hacking competition and a team capture the flag contest. DeepSec is a non-product, non-vendor-biased conference. Our aim is to present the best research and experience from the fields' leading experts. Target Audience: Security Officers, Security Professionals and Product Vendors, IT Decision Makers, Policy Makers, Security-, Network-, and Firewall-Admins, and Software Developers. == Speakers/Trainers == Until June 16th, 23:59 CET, we'll be accepting papers and lightning talk submissions. Please note we are non-product, non-vendor biased security conference, and do not accept vendor pitches. Speaker privileges include * One economy class return-ticket to Vienna. * 3 nights of accomodation in the Conference Hotel. * Breakfast, Lunch, and two coffee breaks * Speaker activities during, before, and after the conference. * Speaker After-Party in the Metalab Hackerspace on November, 24th. Trainer privileges include * 50% of the net profit of the class. * 2 nights of accomodation in the Conference Hotel during the trainings. * Breakfast, Lunch, and two coffee breaks. * Free Speaker Ticket for the Conference. * Speaker activities during, before, and after the conference. * Speaker After-Party in the Metalab Hackerspace on the 24th November == Topics == We are interested in bleeding edge security research, directly from leading researchers, professionals in academics, industry, and government, and the underground security community. Topics of special interest include * Vista, Linux, OSX Security * E/I-Voting Case-Studies, Attacks, Weaknesses * Mobile Security * Network Protocol Analysis * AJAX/Web2.0/Javascript Security * Secure Software Development * VoIP * Perimeter Defense / Firewall Technology * Digital Forensics * WLAN/WiFi, GPRS, IPv6 and 3G Security * IPv6 * Smart Card Security * Cryptography * Intrusion Detection * Incident Response * Rootkit Detection, Techniques, and Defense * Security Properties of Web-Frameworks * Malicious Code Analysis * Secure Framework Design * .Net and Java Security == Submission == Proposals for presentations and trainings at the first annual DeepSec In-Depth Security Conference will be accepted until June 16th 2007, 23:59 CET. All proposals should be submitted over the web at http://www.deepsec.net/cfp/. If you have questions, want to send us additional material, or have problems with the webform, feel free to contact us at [EMAIL PROTECTED] ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] 0day Yahoo Webcam Exploits
Corrected and working: I am very sorry! Please check again Exploit #1 new versions: 9D39223E-AE8E-11D4-8FD3-00D0B7730277 success yahoo version 8.1.0.249 Exploit #2: no success ( black box in IE ) 1 for 2 come on danny!!! ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] 0day Yahoo Webcam Exploits
Exploit #2: working now.. ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] rPSA-2007-0117-1 gd php php-mysql php-pgsql
rPath Security Advisory: 2007-0117-1 Published: 2007-06-07 Products: rPath Linux 1 Rating: Minor Exposure Level Classification: Indirect User Deterministic Denial of Service Updated Versions: gd=/[EMAIL PROTECTED]:devel//1/2.0.33-4.4-1 php=/[EMAIL PROTECTED]:devel//1/4.3.11-15.11-1 php-mysql=/[EMAIL PROTECTED]:devel//1/4.3.11-15.11-1 php-pgsql=/[EMAIL PROTECTED]:devel//1/4.3.11-15.11-1 References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-2756 https://issues.rpath.com/browse/RPL-1394 Description: Previous versions of the gd and php packages are vulnerable to a Denial of Service attack in which an attacker can use a truncated PNG image to cause unbounded CPU consumption. The libgd library is not exposed via any privileged or remote interfaces within rPath Linux per se, but it is exposed by some web applications, such as php (which provides its own internal version of libgd). Copyright 2007 rPath, Inc. This file is distributed under the terms of the MIT License. A copy is available at http://www.rpath.com/permanent/mit-license.html ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
