[Full-disclosure] PyFault 0.1a
Hey All, I have begun writing a little class to do some fault injection on Win32 applications. Currently it only has DLL injection/ejection which is useful if you are a MS Detours kinda person, or are writing DLL payloads for exploits and you want a quick and dirty way of getting them in and out of processes. Really I am looking for comments, and suggestsion on some interesting fault cases that everyone would like to see. As time permits I will be expanding this library to pound the snot out of software in all kinds of interesting ways. You can download it here: http://vdalabs.com/tools/pyfault.html And I look forward to your comments, suggestions and bug fix requests. JS [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/
[Full-disclosure] TippingPoint IPS Signature Evasion
= TippingPoint IPS Signature Evasion = = Vendor Website: = http://www.tippingpoint.com = = Affected Version: = TippingPoint IPS running TOS versions 2.1 2.2.0 - 2.2.4 = = Vendor Notified. 18th January 2006 = Public Disclosure. 11th July 2007 = http://security-assessment.com/files/advisories/2007-07-11_Tippingpoint_IPS_ Signature_Evasion.pdf == Overview == During security analysis of the Tippingpoint IPS product a signature evasion vulnerability was discovered. The use of specific Unicode characters on particular web servers allows a remote user to bypass IPS detection. == Exploitation == By using a hex encoded alternate Unicode character for forward slash (/) a request can be produced that will not match any IPS signature present in the TippingPoint device. Example: http://www.test.com/scripts/cmd.exe is a known attack, and detected by a signature. The same URI with alternate Unicode forward slash characters are not detected by the signature. http://www.test.com/scripts%c0%afcmd.exe http://www.test.com/scripts%e0%80%afcmd.exe http://www.test.com/scripts%c1%9ccmd.exe Web servers located behind a Tippingpoint IPS device which are capable of decoding alternate Unicode characters can be accessed, and exploited without triggering the IPS device. == Solutions == Security-Assessment.com has been in contact with Tipping and a new version of the Tippingpoint IPS software has been released to address the discovered vulnerability. This issue has been addressed in various TOS releases as indicated by the affected product below. - X-Family devices, 2.5.0.6682. - non-X-Family device (not including 600E, 1200E, 2400E or 5000E), 2.5.1.6826. - non-X-Family device (including 600E, 1200E, 2400E or 5000E), 2.5.2.6919. http://www.3com.com/securityalert/alerts/3COM-07-003.html == Credit == Discovered and advised to Tippingpoint January 18th 2006 by Paul Craig of Security-Assessment.com == About Security-Assessment.com == About Security-Assessment.com Security-Assessment.com is Australasia's leading team of Information Security consultants specialising in providing high quality Information Security services to clients throughout the Asia Pacific region. Our clients include some of the largest globally recognised companies in areas such as finance, telecommunications, broadcasting, legal and government. Our aim is to provide the very best independent advice and a high level of technical expertise while creating long and lasting professional relationships with our clients. Security-Assessment.com is committed to security research and development, and its team continues to identify and responsibly publish vulnerabilities in public and private software vendor's products. Members of the Security-Assessment.com RD team are globally recognised through their release of whitepapers and presentations related to new security research. Security-Assessment.com is an Endorsed Commonwealth Government of Australia supplier and sits on the Australian Government Attorney-General's Department Critical Infrastructure Project panel. We are certified by both Visa and MasterCard under their Payment Card Industry Data Security Standard Programs. Paul Craig Security Consultant Security-Assessment.com ___ 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] SecurityFocus Article
If you live outside Germany and think this doesn't affect you, wait! The lt;a href=quot;http://conventions.coe.int/Treaty/EN/Treaties/HTML/185.htmquot;gt;Convention on Cybercrimelt;/agt; was signed by non EU and non European countries too, and East European Countries as well as African and Arabic countries are planning to sign and ratify the Convention. You can read learn more reading the lt;a href=quot;http://www.usdoj.gov/criminal/cybercrime/COEFAQs.htmquot;gt;FAQ hosted by the United States Department of Justicelt;/agt;, or the lt;a href=quot;http://www.epic.org/privacy/intl/ccc.htmlquot;gt;comments by EPIClt;/agt; (Electronic Privacy Information Center). Achtung! New German Laws on Cybercrime by Federico Biancuzzi 2007-07-10 Germany is passing some new laws regarding cybercrime that might affect security professionals. Federico Biancuzzi interviewed Marco Gercke, one of the experts that was invited to the parliamentary hearing, to learn more about this delicate subject. They discussed what is covered by the new laws, which areas remain in the dark, and how they might affect vulnerability disclosure and the use of common tools, such as nmap. http://www.securityfocus.com/columnists/448 ___ 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] SUN Java JNLP Overflow
= SUN Java JNLP Overflow = = Vendor Advisory: = http://sunsolve.sun.com/search/document.do?assetkey=1-26-102996-1 = = Affected Software: = Java Web Start in JDK and JRE 6 Update 1 and earlier = Java Web Start in JDK and JRE 5.0 Update 11 and earlier = = Public disclosure on Wednesday July 11, 2007 == Overview == http://www.google.co.nz/search?hl=enq=same+bug+different+appmeta= My guess is that two years down the track, nobody really took any notice. EEYE posted out there advisory, a couple of days ago. Check it if you want the technical details. Not surprising that it was also discovered by another person, and most likely more than one. 1) Start-Regedit 2) Edit-Search-editflags 3) Find those that have a flag set of BINARY 00 00 01 00 4) *yawn* 5) Find a valid file of that type http://java.sun.com/j2se/1.4.2/docs/guide/jws/developersguide/syntax.htm l 6) Try a long string in an obvious place 7) Watch the debugger kick in 8) Finish your cup of coffee == Solutions == SUN has released a patch http://sunsolve.sun.com/search/document.do?assetkey=1-26-102996-1 This class of vulnerability is well known, and future cases can be mitigated by removing or modifying the editflags value for all registry entries that have 'Disable Open/Save dialog box' set. http://mc-computing.com/WinExplorer/WinExplorerEditFlags.htm == Credit == Discovered and advised to SUN November 15 2006 by Brett Moore of Security-Assessment.com == About Security-Assessment.com == Security-Assessment.com is Australasia's leading team of Information Security consultants specialising in providing high quality Information Security services to clients throughout the Asia Pacific region. Our clients include some of the largest globally recognised companies in areas such as finance, telecommunications, broadcasting, legal and government. Our aim is to provide the very best independent advice and a high level of technical expertise while creating long and lasting professional relationships with our clients. Security-Assessment.com is committed to security research and development, and its team continues to identify and responsibly publish vulnerabilities in public and private software vendor's products. Members of the Security-Assessment.com RD team are globally recognised through their release of whitepapers and presentations related to new security research. Security-Assessment.com is an Endorsed Commonwealth Government of Australia supplier and sits on the Australian Government Attorney-General's Department Critical Infrastructure Project panel. We are certified by both Visa and MasterCard under their Payment Card Industry Data Security Standard Programs. ___ 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] Exploiting reflected XSS vulnerabilities, where user input must come through HTTP Request headers
Contents: === 1.0 Introduction 2.0 The User_Agent Header 3.0 (Known) Firefox Safari Request Header Injection (Sometimes) 4.0 Attacking Caching Proxies 5.0 References 1.0 Introduction === Ever since Adobe patched Flash player to stop attackers spoofing certain headers such as Referer, User-Agent, etc, it has been considered impossible to exploit XSS vulnerabilities where the user input is taken from a request header, e.g. when a website prints out what User-Agent a user's browser is sending, without escaping it. With the exception of the Referer header which we can control enough to exploit XSS attacks through it. I want to showcase several ways in which we can still exploit these vulnerabilities. The rest of the write-up is at: http://kuza55.blogspot.com/2007/07/exploiting-reflected-xss.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/
Re: [Full-disclosure] Wachovia Bank website sends confidential information
On Tue, Jul 10, 2007 at 09:39:33PM -0400, Jim Popovitch wrote: On Tue, 2007-07-10 at 20:20 -0400, Bob Toxen wrote: VI. VENDOR RESPONSE The vendor (Wachovia Bank) was notified via their customer service phone number on June 25. We were transferred to web support. The person answering asked us to FAX the details to her and we did so, also on June 25. We explained that we were reporting a severe security problem on their web site. Severe? All that seems to be leaked is a person's Name/Address/SSN number and some other details. While this is too much info to leak, I'd hardly say it's severe. That same info can be easily found in people's mailboxes weekdays between noon and 4pm. Leaking a SSN is considered serious. My use of the term severe was to get their attention. We stated that that if we did not hear back from them within 7 days and the problem was not fixed by then that we would post the problem on the Full Disclosure list, following accepted industry practice. 7 days? industry practice? Come on Bob I know you know that large corporations can't feed a cat in 7 days let alone make unscheduled website changes that fast. Change control approvals alone would include 14 or more days in most enterprises. Why the rush to say so? Please read my posting more carefully. I stated that if I did not hear back within 7 days and the problem persisted then I would disclose it. All they had to do was to ask for more time and I would have granted any reasonable extension. Instead, it appears that they ignored my report; discouraging that is what Full Disclosure is all about, IMO. I think that that web page should have been shut down within the hour as any competent web person could have confirmed the leak with a few minutes' inspection of the page source. -Jim P. Bob ___ 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] durito: enVivo!CMS SQL injection
Dear [EMAIL PROTECTED],
durito [damagelab] -durito[at]mail[dot]ru- reported SQL injection
vulnerability in enVivo!CMS through ID parameter of default.asp.
Example:
http://www.example.com/default.asp?action=articleID=-1+or+1=(SELECT+TOP+1+username+from+users)--
Original message (in Russian): http://securityvulns.ru/Rdocument425.html
--
http://securityvulns.com/
/\_/\
{ , . } |\
+--oQQo-{ ^ }-+ \
| ZARAZA U 3APA3A } You know my name - look up my number (The Beatles)
+-o66o--+ /
|/
___
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] Multiple .NET Null Byte Injection Vulnerabilities
= Multiple .NET Null Byte Injection Vulnerabilities = = Vendor Website: = http://www.microsoft.com = = Affected Version: =.NET FrameWork v1.1 SP1 =.NET FrameWork v2.0.50727 = = Vendor Notified - October, 2006 = Public Disclosure - July 11th, 2007 = http://security-assessment.com/files/advisories/2007-07-11_Multiple_.NET_Nul l_Byte_Injection_Vulnerabilities.pdf == Overview == Security-Assessment.com recently completed research into the .NET Framework in relation to the affect a Null byte (%00) has on various aspects of the .NET Common Language Runtime. This advisory details the findings of that research conducted by Paul Craig Paul.Craigatsecurity-assessment.com. It was found that certain .NET methods in various sections of the .NET namespace are vulnerable to Null byte injection attacks. Null byte injection occurs when the .NET CLR incorrectly handles user supplied Null bytes. The .NET CLR considers Null bytes as 'data', .NET strings are not Null byte terminated. However, native POSIX compliant function calls terminate all strings at the first found Null byte. Interoperability issues are encountered when data containing a Null byte is used by .NET to directly call a native C function call. Native function calls terminate strings at the injected Null byte allowing a remote user to arbitrarily terminate a string parameter used by the vulnerable method. Security-Assessment.com has discovered five vulnerable methods in the .NET framework which are exploited through Null byte injection. Three of the discovered vulnerabilities allow strings to be arbitrary terminated through String Termination vulnerabilities. The remaining two resulted in an Arbitrary File Disclosure condition where a remote user is capable of accessing arbitrary files from within the web root. .NET has a history surrounding Null byte input flaws and associated logic. On September 8th, 2003 WebCohort Research [EMAIL PROTECTED] released an advisory titled Microsoft ASP.NET Request Validation Null Byte Filter Bypass Vulnerability. Where by the .NET request validation routine could be bypassed when using a Null byte injection. Null byte injection is not a new class of attack, and is a well known exploitive method but this is the first time a Null byte injection vulnerability has been found in methods within the .NET framework. Security researchers should be aware of Null byte injection attacks within the framework itself and .NET developed applications. == Exploitation == The following examples can be found at http://ha.cked.net/examples.zip Exploit 1: Server.MapPath A Null byte injected within the filename parameter of the Server.MapPath method will terminate any returned string, removing any string data concatenated to the user supplied value. This can be seen in example 1 below. name = test.aspx%00 Sub Page_Load() dim name as string dim realname as string name = request(name) .uploaded realname = Mappath(.) \ name response.write(Mappath value of name variable: MapPath(name) br) response.write(The real value is: realname br) End Sub Output: Mappath of name variable = C:\Inetpub\exploit1\test.aspx The Real value is : C:\Inetpub\exploit1\test.aspx.uploaded 1. Two variables are assigned, name and realname. 2. Name is a user supplied filename, and for security reasons .uploaded is appended to this value. 3. Real name is the virtual path for the current directory, with the name variable appended (This is the correct location of the file) 4. Inserting a Null byte suffix into the 'name' variable (name=test.aspx%00) is able to terminate the string returned from MapPath and any data concatenated to the user supplied value is removed. Exploit 2: Server.Execute and Server.Transfer Server.Execute and Server.Transfer were found to both be vulnerable to Null byte injection. Here the Null byte produces an arbitrary file disclosure vulnerability. If a remote user is able to control the input used in a Server.Execute or Server.Transfer method, the method can be used to disclose the contents of any file within the document root. As seen in example 2, below. Sub Page_Load() Server.Transfer(request(page)) End Sub Security-Assessment.com has witnessed Server.Transfer and Server.Execute being used in page redirection functionality where .NET sessions are transferred to a user supplied page variable. According to MSDN: The page transferred to should be another .aspx page. For instance, a transfer to an .asp or .asmx page is not valid. The Transfer method preserves
Re: [Full-disclosure] [WEB SECURITY] Attacking Password Recovery Facilities
when the provider sends and email with a link + hash, it normally wont allow you to send you another link (lets say password recovery email) unless the timeout for the first one expires...the timeout is normally a time/cost function that limits how long or how much money it would cost you to get the hash predicted the following attempt (usually hours) anyway, nice website mailinator.com, can be handy!!! anyone knows for how long it keeps your emails? probably not much! is anyone aware of cool sampling tools that tries usual tricks (like b8/64/etc encoding, etc) and non-usual ones? On 7/6/07, pdp (architect) [EMAIL PROTECTED] wrote: http://www.gnucitizen.org/blog/attacking-password-recovery-facilities this is a small article from ap (aka pagvac) on how to attack password recovery facilities. this post just briefly scratches the surface and I am sure that he will come up with more stuff in the near future. Nevertheless, he brought some interesting points. Hava a look. Cheers. -- pdp (architect) | petko d. petkov http://www.gnucitizen.org Join us on IRC: irc.freenode.net #webappsec Have a question? Search The Web Security Mailing List Archives: http://www.webappsec.org/lists/websecurity/ Subscribe via RSS: http://www.webappsec.org/rss/websecurity.rss [RSS Feed] ___ 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] [USN-482-1] OpenOffice.org vulnerability
=== Ubuntu Security Notice USN-482-1 July 10, 2007 openoffice.org(2)/-amd64 vulnerability CVE-2007-0245 === A security issue affects the following Ubuntu releases: Ubuntu 6.06 LTS Ubuntu 6.10 Ubuntu 7.04 This advisory also applies to the corresponding versions of Kubuntu, Edubuntu, and Xubuntu. The problem can be corrected by upgrading your system to the following package versions: Ubuntu 6.06 LTS: openoffice.org-core 2.0.2-2ubuntu12.4 openoffice.org2-base 2.0.2-2ubuntu12.4 Ubuntu 6.10: openoffice.org-core 2.0.4-0ubuntu6 Ubuntu 7.04: openoffice.org-core 2.2.0-1ubuntu4 After a standard system upgrade you need to restart OpenOffice, or reboot your computer, to effect the necessary changes. Details follow: John Heasman discovered that OpenOffice did not correctly validate the sizes of tags in RTF documents. If a user were tricked into opening a specially crafted document, a remote attacker could execute arbitrary code with user privileges. Updated packages for Ubuntu 6.06 LTS: Source archives: http://security.ubuntu.com/ubuntu/pool/main/o/openoffice.org-amd64/openoffice.org-amd64_2.0.2-2ubuntu12.4-1.diff.gz Size/MD5:36174 4f1cdad8f4da408f8e5518adedfe77e3 http://security.ubuntu.com/ubuntu/pool/main/o/openoffice.org-amd64/openoffice.org-amd64_2.0.2-2ubuntu12.4-1.dsc Size/MD5: 1038 509d279057b4cdc77aa800065a27780c http://security.ubuntu.com/ubuntu/pool/main/o/openoffice.org-amd64/openoffice.org-amd64_2.0.2-2ubuntu12.4.orig.tar.gz Size/MD5: 331056501 a35ec9f233b1eeca4c93ba16dc013c3b http://security.ubuntu.com/ubuntu/pool/main/o/openoffice.org/openoffice.org_2.0.2-2ubuntu12.4.diff.gz Size/MD5: 73116385 877a8d2c7253776419abf3329b87ffa9 http://security.ubuntu.com/ubuntu/pool/main/o/openoffice.org/openoffice.org_2.0.2-2ubuntu12.4.dsc Size/MD5: 3264 2cc078ecce03d186335b63f4fdd3aa35 http://security.ubuntu.com/ubuntu/pool/main/o/openoffice.org/openoffice.org_2.0.2.orig.tar.gz Size/MD5: 206094795 b789f87aaa1f943a47a75740a73ba7cc Architecture independent packages: http://security.ubuntu.com/ubuntu/pool/main/o/openoffice.org/openoffice.org-common_2.0.2-2ubuntu12.4_all.deb Size/MD5: 26439898 610d327c52c20ce1e722ac5beddb100a http://security.ubuntu.com/ubuntu/pool/main/o/openoffice.org/openoffice.org-dev-doc_2.0.2-2ubuntu12.4_all.deb Size/MD5: 4810534 59aa71d72bbce454d785b21f78e6068f http://security.ubuntu.com/ubuntu/pool/main/o/openoffice.org/openoffice.org-gtk-gnome_2.0.2-2ubuntu12.4_all.deb Size/MD5: 924 c297a9edab00e6857c6a635c0b06870c http://security.ubuntu.com/ubuntu/pool/main/o/openoffice.org/openoffice.org-java-common_2.0.2-2ubuntu12.4_all.deb Size/MD5: 2404592 927066b6a18ba5cfefdcf0f37e8c096c http://security.ubuntu.com/ubuntu/pool/main/o/openoffice.org/openoffice.org-l10n-en-us_2.0.2-2ubuntu12.4_all.deb Size/MD5: 605288 3d4ae7a4d12208124d94673f76954005 http://security.ubuntu.com/ubuntu/pool/main/o/openoffice.org/openoffice.org-qa-api-tests_2.0.2-2ubuntu12.4_all.deb Size/MD5: 2092658 8077413c303eb2e76d15da19b7d9943b http://security.ubuntu.com/ubuntu/pool/main/o/openoffice.org/openoffice.org2-base_2.0.2-2ubuntu12.4_all.deb Size/MD5: 920 14673bba873b5b83810b15db77c66208 http://security.ubuntu.com/ubuntu/pool/main/o/openoffice.org/openoffice.org2-calc_2.0.2-2ubuntu12.4_all.deb Size/MD5: 922 d5f9366e6d0b8caca9e21edaebdfdfbd http://security.ubuntu.com/ubuntu/pool/main/o/openoffice.org/openoffice.org2-draw_2.0.2-2ubuntu12.4_all.deb Size/MD5: 922 db4c110ed4e04349e8d6472cb13bf37f http://security.ubuntu.com/ubuntu/pool/main/o/openoffice.org/openoffice.org2-gnome_2.0.2-2ubuntu12.4_all.deb Size/MD5: 918 85547808ab52697aec19a6b33c018740 http://security.ubuntu.com/ubuntu/pool/main/o/openoffice.org/openoffice.org2-impress_2.0.2-2ubuntu12.4_all.deb Size/MD5: 926 fc88982433ba1251839a30dfe4fad59b http://security.ubuntu.com/ubuntu/pool/main/o/openoffice.org/openoffice.org2-kde_2.0.2-2ubuntu12.4_all.deb Size/MD5: 916 da8f539b72dca1a3386c6ce6ea3d15ad http://security.ubuntu.com/ubuntu/pool/main/o/openoffice.org/openoffice.org2-math_2.0.2-2ubuntu12.4_all.deb Size/MD5: 922 da2ffe4aa7417c09a662b32ca78432d5 http://security.ubuntu.com/ubuntu/pool/main/o/openoffice.org/openoffice.org2-writer_2.0.2-2ubuntu12.4_all.deb Size/MD5: 928 8f9593bf4ffa29ddbf46f9958fb4e289 http://security.ubuntu.com/ubuntu/pool/main/o/openoffice.org/openoffice.org2_2.0.2-2ubuntu12.4_all.deb Size/MD5: 904 a7802c9b44fefee23ed70a43b4fe72fe http://security.ubuntu.com/ubuntu/pool/main/o/openoffice.org/ttf-opensymbol_2.0.2-2ubuntu12.4_all.deb
Re: [Full-disclosure] HomestayFinder XSS Vulnerability in Wikipedia Mirror
Well, it does not appear to work for me in any browser (tested Firefox
2.0.0.3 and Konqueror).
LP Killer_X
Susam Pal wrote:
There is an XSS vulnerability in HomestayFinder's 'Dictionary.aspx'
script which is responsible for mirroring the content of Wikipedia. I
found this interesting because here a script injected in one website
exploits an XSS vulnerability in another website.
I am including only a short example to demonstrate the issue. The
complete document is available at:-
http://susam.in/security/advisory-2007-07-11.txt
http://en.wikipedia.org/wiki/User:Susam_pal/Sandbox consists of the
following as the source wiki markup:
scriptalert('XSS Demo')/script
http://www.homestayfinder.com/Dictionary.aspx?q=User:Susam_pal/Sandbox
consists of the same code as HTML without the special characters encoded
as HTML entities. Hence, the script is executed on the browser of the
visitor.
Contact Information:-
Susam Pal
[EMAIL PROTECTED]
http://susam.in/
___
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 - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] [Humor] [archivists] National Archives timestamp (fwd)
The Great Unwashed Masses discover SHA-256! -- Yours, J.A. Terranson sysadmin_at_mfn.org 0xBD4A95BF The real point is that you cannot harbor malice toward others and then cry foul when someone displays intolerance against you. Prejudice tolerated is intolerance encouraged. Rise up in righteousness when you witness the words and deeds of hate, but only if you are willing to rise up against them all, including your own. Otherwise suffer the slings and arrows of disrespect silently. Harvey Fierstein is an actor and playwright. -- Forwarded message -- Date: Tue, 10 Jul 2007 13:52:18 -0500 From: Brad Jensen [EMAIL PROTECTED] To: 'Bill Cribbs' [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: [archivists] National Archives timestamp For those who are not aware, there is a computational procedure you can do for any digital file, that creates a unique number, called a hash, that only matches that exact file. There is a Federal standard for one hashing algorithm, called SHA-1. That is a 160-biit number. More commonly used today is the SHA-256 hash, that generates a 256 bit number. Another term for this is 'digital thumbprint'. In the following discussion I am referring implicitly to the use of the SHA-256 hash. If you take a digital file 'A', and you change the order of two characters in the file, the hash becomes completely different. No two digital files will have the same thumbprint. You cannot predict what the thumbprint will be for a file. You cannot forge or modify a file to match an existing thumbprint. There are digital time stamping services on the internet that register these 'thumbprints' to prove a particular file existed at a particular date and time, and it has not changed. The US Postal Service offers a time stamping service for a small fee that they call an 'Electronic Postmark' but it only is kept for seven years. They also require the user to have a digital certificate to establish identity of the person time stamping the file. I propose something simpler. I propose that the National Archives create and offer a free time stamping service that does not require a digital certificate. The purpose of this is to store and retrieve unique file identifiers that will establish that a file existed at a certain date and time, and has not changed. Then files can be archived in multiple locations across a distributed network, and their identity and authenticity will remain unquestionable. This service would be a public good, similar to the digital time source offered by the Navy, for example. The National Archives will keep these timestamps in perpetuity. They would basically be entries in a database, with a 32-byte thumbprint, date and time. They would be a public record, so anyone can look up a thumbprint and now the date and time it was registered. Can others see the value of this idea? I can write the basic software for this. One part would be a database for the National Archives with a web XML interface for registering and retrieving the thumbprints. It would include a feature to thumbprint each day's database entries, to eliminate any possibility of human interference in the process. You don't have to trust anybody or even the institution, since the thumbprints are impossible to forge. The second thing would be a program, downloadable from a web page, to calculate and submit the thumbprint. I can write it in Windows, publish the source, and others could do the same for Linux, etc. What could it be used for? Scanned images, photographs, text documents, backup files, sound recordings, web pages, newspapers, anything that can be digitized. Since the only submission is the thumbprint and not the file, files can remain private yet still be authenticated later. And the processing load on the server is tiny. The other alternative to have someone like the National Archives do it, is to do it ourselves as a distributed database with replication across many sites and servers. I can do it myself, but this needs institutional support to last forever. That institution can be a formal body like the National Archives, or an ad hoc self-organizing one. Perhaps the latter makes sense in this global internet world. I think of this as the 'Forever Project' since it is the first thing designed to last forever. Brad Jensen President LaserVault LLC www.laservault.com ___ 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] HomestayFinder XSS Vulnerability in Wikipedia Mirror
Hi Matjaz,
I just checked it and I find it to be working with the browsers I have
(tested with Firefox 2.0.0.3 and Internet Explorer 7).
http://www.homestayfinder.com/Dictionary.aspx?q=User:Susam_pal/Sandbox
demonstrates the vulnerability.
http://en.wikipedia.org/wiki/User:Susam_pal/Sandbox is the page where
the script is hosted. The script present in Wikipedia exploits the XSS
vulnerability in HomestayFinder's Dictionary.aspx script.
Regards,
Susam Pal
Matjaz Debelak writes:
Well, it does not appear to work for me in any browser (tested Firefox
2.0.0.3 and Konqueror).
LP Killer_X
Susam Pal wrote:
There is an XSS vulnerability in HomestayFinder's 'Dictionary.aspx'
script which is responsible for mirroring the content of Wikipedia. I
found this interesting because here a script injected in one website
exploits an XSS vulnerability in another website.
I am including only a short example to demonstrate the issue. The
complete document is available at:-
http://susam.in/security/advisory-2007-07-11.txt
http://en.wikipedia.org/wiki/User:Susam_pal/Sandbox consists of the
following as the source wiki markup:
scriptalert('XSS Demo')/script
http://www.homestayfinder.com/Dictionary.aspx?q=User:Susam_pal/Sandbox
consists of the same code as HTML without the special characters encoded
as HTML entities. Hence, the script is executed on the browser of the
visitor.
Contact Information:-
Susam Pal
[EMAIL PROTECTED]
http://susam.in/
___
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 - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
___
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] [Humor] [archivists] National Archives timestamp(fwd)
They discover SHA256 but misunderstand somewhat. There will be cases where different files yield the same hash, but if the algorithm works as it should it will be infeasible to generate one given the desired hash value in any sufficiently simple way. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of J.A. Terranson Sent: Wednesday, July 11, 2007 12:25 AM To: full-disclosure@lists.grok.org.uk Subject: [Full-disclosure] [Humor] [archivists] National Archives timestamp(fwd) The Great Unwashed Masses discover SHA-256! -- Yours, J.A. Terranson sysadmin_at_mfn.org 0xBD4A95BF The real point is that you cannot harbor malice toward others and then cry foul when someone displays intolerance against you. Prejudice tolerated is intolerance encouraged. Rise up in righteousness when you witness the words and deeds of hate, but only if you are willing to rise up against them all, including your own. Otherwise suffer the slings and arrows of disrespect silently. Harvey Fierstein is an actor and playwright. -- Forwarded message -- Date: Tue, 10 Jul 2007 13:52:18 -0500 From: Brad Jensen [EMAIL PROTECTED] To: 'Bill Cribbs' [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: [archivists] National Archives timestamp For those who are not aware, there is a computational procedure you can do for any digital file, that creates a unique number, called a hash, that only matches that exact file. There is a Federal standard for one hashing algorithm, called SHA-1. That is a 160-biit number. More commonly used today is the SHA-256 hash, that generates a 256 bit number. Another term for this is 'digital thumbprint'. In the following discussion I am referring implicitly to the use of the SHA-256 hash. If you take a digital file 'A', and you change the order of two characters in the file, the hash becomes completely different. No two digital files will have the same thumbprint. You cannot predict what the thumbprint will be for a file. You cannot forge or modify a file to match an existing thumbprint. There are digital time stamping services on the internet that register these 'thumbprints' to prove a particular file existed at a particular date and time, and it has not changed. The US Postal Service offers a time stamping service for a small fee that they call an 'Electronic Postmark' but it only is kept for seven years. They also require the user to have a digital certificate to establish identity of the person time stamping the file. I propose something simpler. I propose that the National Archives create and offer a free time stamping service that does not require a digital certificate. The purpose of this is to store and retrieve unique file identifiers that will establish that a file existed at a certain date and time, and has not changed. Then files can be archived in multiple locations across a distributed network, and their identity and authenticity will remain unquestionable. This service would be a public good, similar to the digital time source offered by the Navy, for example. The National Archives will keep these timestamps in perpetuity. They would basically be entries in a database, with a 32-byte thumbprint, date and time. They would be a public record, so anyone can look up a thumbprint and now the date and time it was registered. Can others see the value of this idea? I can write the basic software for this. One part would be a database for the National Archives with a web XML interface for registering and retrieving the thumbprints. It would include a feature to thumbprint each day's database entries, to eliminate any possibility of human interference in the process. You don't have to trust anybody or even the institution, since the thumbprints are impossible to forge. The second thing would be a program, downloadable from a web page, to calculate and submit the thumbprint. I can write it in Windows, publish the source, and others could do the same for Linux, etc. What could it be used for? Scanned images, photographs, text documents, backup files, sound recordings, web pages, newspapers, anything that can be digitized. Since the only submission is the thumbprint and not the file, files can remain private yet still be authenticated later. And the processing load on the server is tiny. The other alternative to have someone like the National Archives do it, is to do it ourselves as a distributed database with replication across many sites and servers. I can do it myself, but this needs institutional support to last forever. That institution can be a formal body like the National Archives, or an ad hoc self-organizing one. Perhaps the latter makes sense in this global internet world. I think of this as the 'Forever Project' since it is the first thing designed to last forever. Brad Jensen President LaserVault LLC www.laservault.com ___ Full-Disclosure - We believe in it.
Re: [Full-disclosure] [Humor] [archivists] National Archives timestamp(fwd)
Finding collisions is definitely one piece. The other is that you can argue about SHA-1 being the Federal standard. Is it used more due to widespread use in existing applications? Yes. However, all Federal agencies (and people in general) should stop using it where possible. NIST has mandated by 2010 for most uses by Federal agencies. I guess we'll see how well that goes... --- March 15, 2006: The SHA-2 family of hash functions (i.e., SHA-224, SHA-256, SHA-384 and SHA-512) may be used by Federal agencies for all applications using secure hash algorithms. Federal agencies should stop using SHA-1 for digital signatures, digital time stamping and other applications that require collision resistance as soon as practical, and must use the SHA-2 family of hash functions for these applications after 2010. After 2010, Federal agencies may use SHA-1 only for the following applications: hash-based message authentication codes (HMACs); key derivation functions (KDFs); and random number generators (RNGs). Regardless of use, NIST encourages application and protocol designers to use the SHA-2 family of hash functions for all new applications and protocols. --- Ref: http://csrc.nist.gov/CryptoToolkit/tkhash.html Steven securityzone.org They discover SHA256 but misunderstand somewhat. There will be cases where different files yield the same hash, but if the algorithm works as it should it will be infeasible to generate one given the desired hash value in any sufficiently simple way. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of J.A. Terranson Sent: Wednesday, July 11, 2007 12:25 AM To: full-disclosure@lists.grok.org.uk Subject: [Full-disclosure] [Humor] [archivists] National Archives timestamp(fwd) The Great Unwashed Masses discover SHA-256! -- Yours, J.A. Terranson sysadmin_at_mfn.org 0xBD4A95BF The real point is that you cannot harbor malice toward others and then cry foul when someone displays intolerance against you. Prejudice tolerated is intolerance encouraged. Rise up in righteousness when you witness the words and deeds of hate, but only if you are willing to rise up against them all, including your own. Otherwise suffer the slings and arrows of disrespect silently. Harvey Fierstein is an actor and playwright. -- Forwarded message -- Date: Tue, 10 Jul 2007 13:52:18 -0500 From: Brad Jensen [EMAIL PROTECTED] To: 'Bill Cribbs' [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: [archivists] National Archives timestamp For those who are not aware, there is a computational procedure you can do for any digital file, that creates a unique number, called a hash, that only matches that exact file. There is a Federal standard for one hashing algorithm, called SHA-1. That is a 160-biit number. More commonly used today is the SHA-256 hash, that generates a 256 bit number. Another term for this is 'digital thumbprint'. In the following discussion I am referring implicitly to the use of the SHA-256 hash. If you take a digital file 'A', and you change the order of two characters in the file, the hash becomes completely different. No two digital files will have the same thumbprint. You cannot predict what the thumbprint will be for a file. You cannot forge or modify a file to match an existing thumbprint. There are digital time stamping services on the internet that register these 'thumbprints' to prove a particular file existed at a particular date and time, and it has not changed. The US Postal Service offers a time stamping service for a small fee that they call an 'Electronic Postmark' but it only is kept for seven years. They also require the user to have a digital certificate to establish identity of the person time stamping the file. I propose something simpler. I propose that the National Archives create and offer a free time stamping service that does not require a digital certificate. The purpose of this is to store and retrieve unique file identifiers that will establish that a file existed at a certain date and time, and has not changed. Then files can be archived in multiple locations across a distributed network, and their identity and authenticity will remain unquestionable. This service would be a public good, similar to the digital time source offered by the Navy, for example. The National Archives will keep these timestamps in perpetuity. They would basically be entries in a database, with a 32-byte thumbprint, date and time. They would be a public record, so anyone can look up a thumbprint and now the date and time it was registered. Can others see the value of this idea? I can write the basic software for this. One part would be a database for the National Archives with a web XML interface for registering and retrieving the thumbprints. It would include a feature to thumbprint each day's database entries, to eliminate any possibility of human
[Full-disclosure] TippingPoint detection bypass
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
(The following advisory is also available in PDF format for download at:
http://www.cybsec.com/vuln/CYBSEC-Security_Pre-Advisory_3Com_TippingPoint_IPS_Detection_Bypass_2.pdf
)
CYBSEC S.A.
www.cybsec.com
Pre-Advisory Name: TippingPoint detection bypass
==
Vulnerability Class: Design flaw
Release Date: 2007-07-04
=
Affected Platforms:
===
* TippingPoint IPS running TOS versions 2.1.x, 2.2.x prior to 2.2.5,
and 2.5.x prior to 2.5.2
Local / Remote: Remote
===
Severity: High
=
Author: Andres Riancho
===
Vendor Status:
==
* Confirmed, updates released.
Reference to Vulnerability Disclosure Policy:
=
http://www.cybsec.com/vulnerability_policy.pdf
Product Overview:
=
The TippingPoint Intrusion Prevention System (IPS) is an
award-winning security solution that blocks worms,
viruses, Trojans, Denial of Service and Distributed Denial of Service
attacks, Spyware, VoIP threats, and
Peer-to-Peer threats. Inspecting traffic through Layer 7, the IPS
blocks malicious traffic before damage occurs.
Vulnerability Description:
==
When IP packets are fragmented in a special way, the appliance fails
to correctly reassemble the data stream.
Technical Details:
==
Technical details will be released 30 days after publication of this
pre-advisory.
This was agreed upon with TippingPoint to allow their customers to
upgrade affected software prior to technical
knowledge been publicly available.
Impact:
===
Exploiting this vulnerability, an attacker would be able to bypass all
filters and detection.
Solutions:
==
TippingPoint has released a new version of the TippingPoint OS to
address this vulnerability. Customers
should apply the new firmware immediately. More information can be
found at
http://www.3com.com/securityalert/alerts/3COM-07-002.html
Vendor Response:
* 2006-02-06: Initial Vendor Contact.
* 2006-06-20: Vendor Confirmed Vulnerability.
* 2007-07-04: Vendor Releases Update.
Contact Information:
For more information regarding the vulnerability feel free to contact
the author at ariancho {at} cybsec.com.
For more information regarding CYBSEC: www.cybsec.com
(c) 2006 - CYBSEC S.A. Security Systems
- --
-
Andres Riancho
CYBSEC S.A. Security Systems
E-mail: [EMAIL PROTECTED]
PGP key: http://www.cybsec.com/pgp/ariancho.txt
Tel/Fax: [54 11] 4371-
Web: http://www.cybsec.com
- -
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGlMr91351/apVCtIRAvhWAJ9xN0HWUlZNIXEbv3WqsMZ/eG+aywCfQcMS
MfBRpx+IalvqFtQm0bvqwMI=
=YsAN
-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] TippingPoint IPS Signature Evasion
Dear Paul Craig, --Wednesday, July 11, 2007, 1:37:03 AM, you wrote to [EMAIL PROTECTED]: PC http://www.test.com/scripts%c0%afcmd.exe PC http://www.test.com/scripts%e0%80%afcmd.exe PC http://www.test.com/scripts%c1%9ccmd.exe PC Web servers located behind a Tippingpoint IPS device which are capable PC of decoding alternate Unicode characters can be accessed, and exploited PC without triggering the IPS device. Can you, please, provide example of such server? Fatih Ozavci reported similar problem with Checkpoint and Halfwidth/Fullwidth Unicode, potential attack vector was IIS with .Net framework, in this case IIS seems not to be exploitable. Blaming IPS it does not detect attack which is impossible in-the-wild is nonsense. Blaming corporate-level IPS doesn't detect attack against SOHO web server is acceptable nonsense :) -- ~/ZARAZA http://securityvulns.com/ ___ 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] Wachovia Bank website sends confidential information
[EMAIL PROTECTED] wrote: On Tue, 10 Jul 2007 21:39:33 EDT, Jim Popovitch said: 7 days? industry practice? Come on Bob I know you know that large corporations can't feed a cat in 7 days let alone make unscheduled website changes that fast. Change control approvals alone would include 14 or more days in most enterprises. Why the rush to say so? On the other hand, I think that they *could* manage at least a Wow d00dz, we really *do* have a hole there reply and at least give a handwaving about when they'd fix it. Of course, actually *fixing* a design flaw that big is going to take them *months*. Driver walks into a dealer and speaks to customer service: These brake pads are extremely vulnerable to slipping during X conditions on a 90 degree slalom says the driver. Puzzled and not knowing squat about slaloms, or the breaking system, the customer service rep send the driver to a mechanic. These brake pads are extremely vulnerable to slipping during X conditions on a 90 degree slalom. Someone will die! says the driver to the mechanic... Not being able to change the auto's design nor engineering, the mechanic is puzzled and offers to take the information although he is even more puzzled on who this should be directed to. Two days later driver rambles on news stations nationwide: Their arrogance will get people killed. I warned them repeatedly People moan and grumble, etc., recalls, fixes... This Wachovia thread is pointless. I see no mention or posting to perhaps any security list (and I'm on many both public and private) saying: Hey is there anyone who can put me in touch with someone in the know at Wachovia on any list. All I see is... I called customer service. So what, if you're a security professional you will know damn well you're getting nowhere with them. I spoke to their w3bm4ster. And? Either the poster is looking for attention or a complete and utter idiot. If his or her true intention was to provide a report of a security woe concerning said business or product, he or she could have easily jumped on any security mailing list and found the right connection instead of rambling on the sky is falling... Let me see: wachovia security cissp incident +network via Google This looks interesting: http://www.bryceporter.com/ I would have contacted someone on this level to put me in touch with the right person. But hey, guess its more hip to add stupid little tags next to your resume or webpage: I broke $INSERT_VENDOR_HERE -- 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/
[Full-disclosure] 0day linux 2.6 /dev/mem rootkit found
I found one interesting tool on my server, with the name 'Boxer 0.99 BETA3'. It's protected by ELFuck linux executables obfuscator. Google doesn't know anything about it. Now, it is available at http://surfall.net/rel.tar.gz (ELFuck password: 'notdead') Anybody seen it before? Sick sense of humor? Visit Yahoo! TV's Comedy with an Edge to see what's on, when. http://tv.yahoo.com/collections/222 Be a PS3 game guru. Get your game face on with the latest PS3 news and previews at Yahoo! Games. http://videogames.yahoo.com/platform?platform=120121 ___ 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] Advisory - Clam AntiVirus RAR File Handling Denial Of Service Vulnerability.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Noam Rathaus wrote: Hi, The vulnerability also affects unrar (3.70 beta 3 freeware by Alexander Roshal), as it tries to read a negative location from a pointer reference in the SET_VALUE(false,Data,Addr-Offset) function (found in rarvm.cpp). The values of Addr is 1666528 while Offset is 4546004 which of course results in -2879476 being accessed, or even better the value of 4292087820 as it is casted to an unsigned value without checking. Yes we have reported to them also. All the products using the code from unrar for linux are vulnerable. The RAR Labs requested to delay the advisory until next release. Regards Metaeye SG // http://www.metaeye.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFGlPtwgHlN5ncUR6wRAkxRAJ4n5ONzoP31FFAJzMAaw/L4dSXqwQCfarcK /0u6i3AQ7otAsN4YSeZoIoU= =MYBk -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/
[Full-disclosure] Advisory - Clam AntiVirus RAR File Handling Denial Of Service Vulnerability.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Vendor - -- Clam Antivirus (http://www.clamav.net) Product - --- Clamav (libclamav) Versions Affected - - All before 0.91 Severity - Moderate Issue - - Clamav crashes due to processing of standard filters in RAR VM, while processing a corrupted RAR file. Processing the corrupted file results in a null pointer deference. Impact - -- Processing the corrupted file will result in crashing of clamscan application and clamd daemon. Fix - --- Upgrade to version 0.91. PoC - --- http://www.metaeye.org/codes/corrupted.rar Vendor Status - - Reported: 25/06/2007 Fixed:11/07/2007 References - -- https://wwws.clamav.net/bugzilla/show_bug.cgi?id=555 http://www.metaeye.org/advisories/54 Metaeye SG // http://www.metaeye.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFGlPzXgHlN5ncUR6wRAsjSAJ9/AQDZBJBYywO/8m3EUCgMUXBlQgCfWiL8 f3Hq+HVMtsVrs1W+HOpI+kk= =t5nN -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/
[Full-disclosure] Advisory - Clam AntiVirus RAR File Handling Denial Of Service Vulnerability.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Vendor - -- Clam Antivirus (http://www.clamav.net) Product - --- Clamav (libclamav) Versions Affected - - All before 0.91 Severity - Moderate Issue - - Clamav crashes due to processing of standard filters in RAR VM, while processing a corrupted RAR file. Processing the corrupted file results in a null pointer deference. Impact - -- Processing the corrupted file will result in crashing of clamscan application and clamd daemon. Fix - --- Upgrade to version 0.91. PoC - --- http://www.metaeye.org/codes/corrupted.rar Vendor Status - - Reported: 25/06/2007 Fixed:11/07/2007 References - -- https://wwws.clamav.net/bugzilla/show_bug.cgi?id=555 http://www.metaeye.org/advisories/54 Metaeye SG // http://www.metaeye.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFGlPN/gHlN5ncUR6wRAo1AAJ9dNI51Y4t5BRG3aqIUHPih8cJQ7ACfVrW1 21o5Oadk6A7OVGhdzJph2gk= =YuBi -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/
[Full-disclosure] rPSA-2007-0137-1 tshark wireshark
rPath Security Advisory: 2007-0137-1 Published: 2007-07-11 Products: rPath Linux 1 Rating: Major Exposure Level Classification: Indirect User Deterministic Denial of Service Updated Versions: tshark=/[EMAIL PROTECTED]:devel//1/0.99.6-0.1-1 wireshark=/[EMAIL PROTECTED]:devel//1/0.99.6-0.1-1 References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-3389 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-3390 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-3391 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-3392 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-3393 https://issues.rpath.com/browse/RPL-1498 Description: Previous versions of the wireshark package are vulnerable to multiple types of Denial of Service attacks, including crashes and excessive memory consumption. It has not been determined that these vulnerabilities can be exploited to execute malicious code. 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/
Re: [Full-disclosure] HomestayFinder XSS Vulnerability in Wikipedia Mirror
It works for me. JS enabled in your browser?
On 7/11/07, Matjaz Debelak [EMAIL PROTECTED] wrote:
Well, it does not appear to work for me in any browser (tested Firefox
2.0.0.3 and Konqueror).
LP Killer_X
Susam Pal wrote:
There is an XSS vulnerability in HomestayFinder's 'Dictionary.aspx'
script which is responsible for mirroring the content of Wikipedia. I
found this interesting because here a script injected in one website
exploits an XSS vulnerability in another website.
I am including only a short example to demonstrate the issue. The
complete document is available at:-
http://susam.in/security/advisory-2007-07-11.txt
http://en.wikipedia.org/wiki/User:Susam_pal/Sandbox consists of the
following as the source wiki markup:
scriptalert('XSS Demo')/script
http://www.homestayfinder.com/Dictionary.aspx?q=User:Susam_pal/Sandbox
consists of the same code as HTML without the special characters encoded
as HTML entities. Hence, the script is executed on the browser of the
visitor.
Contact Information:-
Susam Pal
[EMAIL PROTECTED]
http://susam.in/
___
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 - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
___
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] Wachovia Bank website sends confidential information
I got you right? The one doing just for fun researches is in duty to find the correct person and not the company, making big buisness, in providing easy access to this person? Yes you are obviously right ^^ J. Oquendo wrote: [EMAIL PROTECTED] wrote: On Tue, 10 Jul 2007 21:39:33 EDT, Jim Popovitch said: 7 days? industry practice? Come on Bob I know you know that large corporations can't feed a cat in 7 days let alone make unscheduled website changes that fast. Change control approvals alone would include 14 or more days in most enterprises. Why the rush to say so? On the other hand, I think that they *could* manage at least a Wow d00dz, we really *do* have a hole there reply and at least give a handwaving about when they'd fix it. Of course, actually *fixing* a design flaw that big is going to take them *months*. Driver walks into a dealer and speaks to customer service: These brake pads are extremely vulnerable to slipping during X conditions on a 90 degree slalom says the driver. Puzzled and not knowing squat about slaloms, or the breaking system, the customer service rep send the driver to a mechanic. These brake pads are extremely vulnerable to slipping during X conditions on a 90 degree slalom. Someone will die! says the driver to the mechanic... Not being able to change the auto's design nor engineering, the mechanic is puzzled and offers to take the information although he is even more puzzled on who this should be directed to. Two days later driver rambles on news stations nationwide: Their arrogance will get people killed. I warned them repeatedly People moan and grumble, etc., recalls, fixes... This Wachovia thread is pointless. I see no mention or posting to perhaps any security list (and I'm on many both public and private) saying: Hey is there anyone who can put me in touch with someone in the know at Wachovia on any list. All I see is... I called customer service. So what, if you're a security professional you will know damn well you're getting nowhere with them. I spoke to their w3bm4ster. And? Either the poster is looking for attention or a complete and utter idiot. If his or her true intention was to provide a report of a security woe concerning said business or product, he or she could have easily jumped on any security mailing list and found the right connection instead of rambling on the sky is falling... Let me see: wachovia security cissp incident +network via Google This looks interesting: http://www.bryceporter.com/ I would have contacted someone on this level to put me in touch with the right person. But hey, guess its more hip to add stupid little tags next to your resume or webpage: I broke $INSERT_VENDOR_HERE ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ -- greets one must still have chaos in oneself to be able to give birth to a dancing star ___ 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] Cisco Security Advisory: Cisco Unified Communications Manager Overflow Vulnerabilities
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Cisco Security Advisory: Cisco Unified Communications Manager Overflow Vulnerabilities Document ID: 92015 Advisory ID: cisco-sa-20070711-cucm http://www.cisco.com/warp/public/707/cisco-sa-20070711-cucm.shtml Revision 1.0 For Public Release 2007 July 11 1600 UTC (GMT) - - Contents Summary Affected Products Details Vulnerability Scoring Details Impact Software Version and Fixes Workarounds Obtaining Fixed Software Exploitation and Public Announcements Status of this Notice: FINAL Distribution Revision History Cisco Security Procedures - - Summary === Cisco Unified Communications Manager (CUCM), formerly CallManager, contains two overflow vulnerabilities that could allow a remote, unauthenticated user to cause a denial of service (DoS) condition or execute arbitrary code. A workaround exists for one of the vulnerabilities. Cisco has made free software available to address these vulnerabilities for affected customers. This advisory is posted at http://www.cisco.com/warp/public/707/cisco-sa-20070711-cucm.shtml Affected Products = Note: Cisco Unified CallManager versions 4.2, 4.3, 5.1 and 6.0 have been renamed as Cisco Unified Communications Manager. CUCM versions 3.3, 4.0, 4.1 and 5.0 retain the Cisco Unified CallManager name. Vulnerable Products +-- These products are vulnerable: * Cisco Unified CallManager 3.3 versions prior to 3.3(5)SR3 * Cisco Unified CallManager 4.1 versions prior to 4.1(3)SR5 * Cisco Unified CallManager 4.2 versions prior to 4.2(3)SR2 * Cisco Unified Communications Manager 4.3 versions prior to 4.3(1) SR1 * Cisco Unified CallManager 5.0 and Communications Manager 5.1 versions prior to 5.1(2) Administrators of systems running CUCM version 3.x and 4.x can determine the software version by navigating to Help About Cisco Unified CallManager and selecting the Details button via the CUCM Administration interface. Administrators of systems running CUCM version 5.0 can determine the software version by viewing the main page of the CUCM Administration interface. The software version can also be determined by running the command show version active via the Command Line Interface (CLI). Products Confirmed Not Vulnerable + Cisco Unified Communications Manager version 6.0 and Cisco CallManager Express are not affected by these vulnerabilities. No other Cisco products are currently known to be affected by these vulnerabilities. Details === Cisco Unified Communications Manager (CUCM), formerly CallManager, is the call processing component of the Cisco IP telephony solution that extends enterprise telephony features and functions to packet telephony network devices, such as IP phones, media processing devices, voice-over-IP (VoIP) gateways, and multimedia applications. * CTL Provider Service Overflow The Certificate Trust List (CTL) Provider service of CUCM contains a heap overflow vulnerability that could allow a remote, unauthenticated user to cause a DoS condition or execute arbitrary code. The CTL Provider service listens on TCP port 2444 by default, but the port is user-configurable. This vulnerability is corrected in CUCM versions 4.1(3)SR5, 4.2(3)SR2, 4.3(1)SR1 and 5.1(2). CUCM 3.x versions are not affected by this vulnerability. This issue is documented in Cisco Bug ID CSCsi03042. * RIS Data Collector Heap Overflow The Real-Time Information Server (RIS) Data Collector service of CUCM contains a heap overflow vulnerability that could allow a remote, unauthenticated user to cause a DoS condition or execute arbitrary code. The RIS Data Collector process listens on TCP port 2556 by default, but the port is user-configurable. This vulnerability is corrected in CUCM versions 3.3(5)SR2b, 4.1(3) SR5, 4.2(3)SR2, 4.3(1)SR1 and 5.1(2). This issue is documented in Cisco Bug ID CSCsi10509. Vulnerability Scoring Details = Cisco is providing scores for the vulnerabilities in this advisory based on the Common Vulnerability Scoring System (CVSS). The CVSS scoring in this Security Advisory is done in accordance with CVSS version 1.0. Cisco will provide a base and temporal score. Customers can then compute environmental scores to assist in determining the impact of the vulnerability in individual networks. Cisco PSIRT will set the bias in all cases to normal. Customers are encouraged to apply the bias parameter when determining the environmental impact of a particular vulnerability. CVSS is a standards based scoring method that conveys vulnerability severity and helps determine urgency and priority of response. Cisco has provided an FAQ to answer additional
Re: [Full-disclosure] Wachovia Bank website sends confidential information
While it is true that lots of folk pick on vendors for a few minutes of fame, the Wachovia case is slightly different. They do have an attitude problem and are technically challenged. The basis for this is a law enforcement conference about six months ago. During a pressentation a Wachovia representative told a speaker to stop blaming the banks for problems. This was the third presentation this individual has listened to in which each speaker had blamed the banks for not doing enough and the frustration level was a bit high. This only comes up because of the current Wachovia web site issue. It shows that there is an internal problem, worse than most, endind with the current situation. And no I will not indentify any of the players. --bob On Wed, 11 Jul 2007, J. Oquendo wrote: [EMAIL PROTECTED] wrote: On Tue, 10 Jul 2007 21:39:33 EDT, Jim Popovitch said: 7 days? industry practice? Come on Bob I know you know that large corporations can't feed a cat in 7 days let alone make unscheduled website changes that fast. Change control approvals alone would include 14 or more days in most enterprises. Why the rush to say so? On the other hand, I think that they *could* manage at least a Wow d00dz, we really *do* have a hole there reply and at least give a handwaving about when they'd fix it. Of course, actually *fixing* a design flaw that big is going to take them *months*. Driver walks into a dealer and speaks to customer service: These brake pads are extremely vulnerable to slipping during X conditions on a 90 degree slalom says the driver. Puzzled and not knowing squat about slaloms, or the breaking system, the customer service rep send the driver to a mechanic. These brake pads are extremely vulnerable to slipping during X conditions on a 90 degree slalom. Someone will die! says the driver to the mechanic... Not being able to change the auto's design nor engineering, the mechanic is puzzled and offers to take the information although he is even more puzzled on who this should be directed to. Two days later driver rambles on news stations nationwide: Their arrogance will get people killed. I warned them repeatedly People moan and grumble, etc., recalls, fixes... This Wachovia thread is pointless. I see no mention or posting to perhaps any security list (and I'm on many both public and private) saying: Hey is there anyone who can put me in touch with someone in the know at Wachovia on any list. All I see is... I called customer service. So what, if you're a security professional you will know damn well you're getting nowhere with them. I spoke to their w3bm4ster. And? Either the poster is looking for attention or a complete and utter idiot. If his or her true intention was to provide a report of a security woe concerning said business or product, he or she could have easily jumped on any security mailing list and found the right connection instead of rambling on the sky is falling... Let me see: wachovia security cissp incident +network via Google This looks interesting: http://www.bryceporter.com/ I would have contacted someone on this level to put me in touch with the right person. But hey, guess its more hip to add stupid little tags next to your resume or webpage: I broke $INSERT_VENDOR_HERE -- Dr. Robert Bruen Cold Rain Technologies http://coldrain.net +1.802.579.6288 ___ 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] HomestayFinder XSS Vulnerability in Wikipedia Mirror
http://www.homestayfinder.com/Dictionary.aspx?q=User:Susam_pal/Sandbox
now redirects to
http://www.inglesnoexterior.com/dictionary.aspx?q=User:Susam_pal/Sandbox
Vulnerable script moved to another domain. To protect the cookies of
homestayfinder.com???
Wondering whether this kinda attack would be called persistent XSS or
something else? This is a case where the attack vector goes into one
site and the vector exploits another site. How to classify this?
On 7/11/07, Susam Pal [EMAIL PROTECTED] wrote:
Hi Matjaz,
I just checked it and I find it to be working with the browsers I have
(tested with Firefox 2.0.0.3 and Internet Explorer 7).
http://www.homestayfinder.com/Dictionary.aspx?q=User:Susam_pal/Sandbox
demonstrates the vulnerability.
http://en.wikipedia.org/wiki/User:Susam_pal/Sandbox is the page where
the script is hosted. The script present in Wikipedia exploits the XSS
vulnerability in HomestayFinder's Dictionary.aspx script.
Regards,
Susam Pal
Matjaz Debelak writes:
Well, it does not appear to work for me in any browser (tested Firefox
2.0.0.3 and Konqueror).
LP Killer_X
Susam Pal wrote:
There is an XSS vulnerability in HomestayFinder's 'Dictionary.aspx'
script which is responsible for mirroring the content of Wikipedia. I
found this interesting because here a script injected in one website
exploits an XSS vulnerability in another website.
I am including only a short example to demonstrate the issue. The
complete document is available at:-
http://susam.in/security/advisory-2007-07-11.txt
http://en.wikipedia.org/wiki/User:Susam_pal/Sandbox consists of the
following as the source wiki markup:
scriptalert('XSS Demo')/script
http://www.homestayfinder.com/Dictionary.aspx?q=User:Susam_pal/Sandbox
consists of the same code as HTML without the special characters encoded
as HTML entities. Hence, the script is executed on the browser of the
visitor.
Contact Information:-
Susam Pal
[EMAIL PROTECTED]
http://susam.in/
___
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 - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
___
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 - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] Cisco Security Advisory: Cisco Unified Communications Manager and Presence Server Unauthorized Access Vulnerabilities
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Cisco Security Advisory: Cisco Unified Communications Manager and Presence Server Unauthorized Access Vulnerabilities Document ID: 97060 Advisory ID: cisco-sa-20070711-voip http://www.cisco.com/warp/public/707/cisco-sa-20070711-voip.shtml Revision 1.0 For Public Release 2007 July 11 1600 UTC (GMT) - - Contents Summary Affected Products Details Vulnerability Scoring Details Impact Software Version and Fixes Workarounds Obtaining Fixed Software Exploitation and Public Announcements Status of this Notice: FINAL Distribution Revision History Cisco Security Procedures - - Summary === Cisco Unified Communications Manager (CUCM), formerly CallManager, and Cisco Unified Presence Server (CUPS) contain two vulnerabilities that could allow an unauthorized administrator to activate and terminate CUCM / CUPS system services and access SNMP configuration information. This may respectively result in a denial of service (DoS) condition affecting CUCM/CUPS cluster systems and the disclosure of sensitive SNMP details, including community strings. There are no workarounds for these vulnerabilities. Cisco has made free software available to address these vulnerabilities for affected customers. This advisory is posted at http://www.cisco.com/warp/public/707/cisco-sa-20070711-voip.shtml Affected Products = Note: Cisco Unified CallManager versions 4.2, 4.3, 5.1 and 6.0 have been renamed as Cisco Unified Communications Manager. CUCM versions 3.3, 4.0, 4.1 and 5.0 retain the Cisco Unified CallManager name. Vulnerable Products +-- These products are vulnerable: * Cisco Unified CallManager 5.0 and Communications Manager 5.1 versions up to and including 5.1(2) * Cisco Unified Presence Server 1.0 versions up to and including 1.0(3) Administrators of systems running CUCM version 5.x and CUPS version 1.x can determine the software version by viewing the main page of the CUCM/CUPS Administration interface. The software version can also be determined by running the command show version active via the Command Line Interface (CLI). Products Confirmed Not Vulnerable + * Cisco Unified CallManager versions 3.3, 4.0, 4.1, 4.2 * Cisco Unified Communications Manager versions 4.3, 6.0 * Cisco Unified Presence Server version 6.0 No other Cisco products are currently known to be affected by these vulnerabilities. Details === * Unauthorized Administrator Can Activate/Terminate CUCM/CUPS System Services An unauthorized CUCM/CUPS administrator may be able to activate and terminate system services in a CUCM/CUPS cluster environment. This may result in a denial of critical voice services. The unauthorized administrator cannot make changes to or view the configuration of the vulnerable CUCM/CUPS system, with the exception of viewing SNMP settings, which is documented in the next vulnerability. The CUCM issue is documented by Cisco Bug ID CSCsj09859. The CUPS issue is documented by Cisco Bug ID CSCsj19985. * Unauthorized Administrator Can View CUCM/CUPS SNMP Settings An unauthorized CUCM/CUPS administrator may be able to view sensitive SNMP configuration information in a CUCM/CUPS cluster environment. This may result in the disclosure of sensitive information, including SNMP community strings. The CUCM issue is documented in Cisco Bug ID CSCsj20668. The CUPS issue is documented in Cisco Bug ID CSCsj25962. Vulnerability Scoring Details = Cisco is providing scores for the vulnerabilities in this advisory based on the Common Vulnerability Scoring System (CVSS). The CVSS scoring in this Security Advisory is done in accordance with CVSS version 1.0. Cisco will provide a base and temporal score. Customers can then compute environmental scores to assist in determining the impact of the vulnerability in individual networks. Cisco PSIRT will set the bias in all cases to normal. Customers are encouraged to apply the bias parameter when determining the environmental impact of a particular vulnerability. CVSS is a standards based scoring method that conveys vulnerability severity and helps determine urgency and priority of response. Cisco has provided an FAQ to answer additional questions regarding CVSS at http://www.cisco.com/web/about/security/intelligence/cvss-qandas.html Cisco has also provided a CVSS calculator to help compute the environmental impact for individual networks at http://intellishield.cisco.com/security/alertmanager/cvss CSCsj09859 - Unauthorized administrators can start/stop CUCM services CVSS Base Score - 7 Access Vector -Remote Access Complexity -Low
[Full-disclosure] Paper: Anti Forensics: making computer forensics hard.
Yo, In this paper (translated from Portuguese in 2006) is presented since basic until advanced techniques used to defeat forensic analysis. Including the following topics: - What is computer forensics? - What is Anti Forensics? - Anti Forensics methods: Encryption. Steganography. Self Split Files + Encryption. Defeat last modified files technique. Wipe. Data Hiding: swap, file system bad blocks, unallocated spaces, ADS. Process dump. Integrity check (MD5 Collision). Database Rootkits. BIOS Rootkits. You can check the full paper in: http://ws.hackaholic.org/slides/AntiForensics-CodeBreakers2006-Translation-To-English.pdf Wendel Guglielmetti Henrique http://ws.hackaholic.org - personal page ___ 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] Wachovia Bank website sends confidential information
Bob Bruen wrote: While it is true that lots of folk pick on vendors for a few minutes of fame, the Wachovia case is slightly different. They do have an attitude problem and are technically challenged. The basis for this is a law enforcement conference about six months ago. During a pressentation a Wachovia representative told a speaker to stop blaming the banks for problems. This was the third presentation this individual has listened to in which each speaker had blamed the banks for not doing enough and the frustration level was a bit high. This only comes up because of the current Wachovia web site issue. It shows that there is an internal problem, worse than most, endind with the current situation. And no I will not indentify any of the players. --bob Mechanisms of politrix... I was doing contract work from home for a HUGE-O-MONGOUS tech company I won't name (NDA) and was assigned to do fw administration, configuration for a bank that outsource it to this HUGE-O-MONGOUS monster. When we needed to implement a change these were the steps: Uh oh.. We're seeing attacks from network X ... 1) Call manager 2) Manager calls his manager in another state 3) That manager calls sales rep 4) Sales rep called the bank's contact 5) Bank's contact called his security team 6) Hey security team, you need to speak with your contractors 7) Security team to bank's contact ok make a conference call 8) Bank's contact to the sales rep - ok make a conference call 9) bank sales rep to HUGE-O-MONGOUS' sales rep - ok make a conference call 10) manager to manager - hey we're going to do a conference call 11) No wait... My contractor is tied up... Can we re-schedule? In essence, when we needed to do things, it wasn't as cut and dry as I thought it would be. In fact it was downright frustrating. Here you are Rainwall open, NSM open about to fire off changes but have to wait for at minimum 4 business days hoping no one up the food chain was unavailable to make a mission critical change. Long story short, while at HUGE-O-MONGOUS I was surprised I was even given the opportunity to be there - but hey contractors liabilities, etc., legal foobarfoo wording exculpated HUGE-O-MONGOUS company from the whole shmoo (compsec historians know the HIStory), anyhow, I got frustrated working for them. I felt as if it was such a dead end. Mind you I was making about $80.00 per hour to roll out of bed and do work pretty much whenever I wanted. Sometimes, things aren't as clear cut as one may think they are. To me the initial Oh noes! Wachovia is evil post was nothing more than someone itching for their Andy Warhol 15 minutes. With that said... Off to lunch... -- 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] SecurityFocus Article
On 10 Jul 2007 22:40:09 -, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: ... Germany is passing some new laws regarding cybercrime that might affect security professionals. Q: I have heard from multiple sources that one of the worst aspects of the new laws was that security tools such as nmap (a port scanner), would become illegal. Just having them on your computer will be enough. Is it true? Every detail about this topic would be appreciated... Marco Gercke: The risk is there. Unlike Art. 6 of Convention on Cybercrime, Paragraph 202c Penal Code does not limit the criminalisation to tools that are primarily designed to commit certain computer crimes. Therefore it will be necessary to wait for the first verdicts. It is very likely that the courts will limit the application of the software with the result that the possession without link to criminal activities will not be punished. this bullshit has already brought the end of phenoelit and ROCKate. more to come, surely. very likely to limit application to criminal activities doesn't give much confidence in the face of a government antagonistic toward security research and privacy enhancing technology. http://www.phenoelit.de/202/202.html http://archives.seul.org/or/talk/Jul-2007/msg00044.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/
Re: [Full-disclosure] iDefense Security Advisory 07.09.07: WinPcap NPF.SYS Local Privilege Escalation Vulnerability
iDefense Labs wrote: WinPcap NPF.SYS Local Privilege Escalation Vulnerability iDefense Security Advisory 07.09.07 http://labs.idefense.com/intelligence/vulnerabilities/ Jul 09, 2007 I. BACKGROUND WinPcap is a software package that facilitates real-time link-level network access for Windows-based operating systems. It is used by a wide range of open-source projects including Wireshark. More information is available at the project web site at the URL shown below. http://www.winpcap.org/ II. DESCRIPTION Local exploitation of an input validation vulnerability within the NPF.SYS device driver of WinPcap allows attackers to execute arbitrary code in kernel context. The vulnerability specifically exists due to insufficient input validation when handling the Interrupt Request Packet (Irp) parameters passed to IOCTL 9031 (BIOCGSTATS). By passing carefully chosen parameters to this IOCTL, an attacker can overwrite arbitrary kernel memory. III. ANALYSIS Exploitation allows attackers to execute arbitrary code in kernel context. The vulnerable device driver is loaded when WinPcap is initialized. This driver can be set to load on start-up depending on a choice made at installation time. This is not the default setting. In a default installation, the device driver is not loaded until an Administrator utilizes a WinPcap dependent application. Once they do, it will become accessible to normal users as well. When a program using this driver exists, it is not unloaded. Attackers will continue to have access until the driver is manually unloaded. Nobody seemed to care about my patch for custom security on the capture device: http://www.winpcap.org/pipermail/winpcap-bugs/2005-June/29.html In other news, Microsoft just released Network Monitor 3.1: http://www.microsoft.com/downloads/details.aspx?familyid=18b1d59d-f4d8-4213-8d17-2f6dde7d7aac (I'm extremely impressed by the improvements on 2.x, BTW) ___ 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] iDefense Security Advisory 07.11.07: Symantec AntiVirus symtdi.sys Local Privilege Escalation Vulnerability
Symantec AntiVirus symtdi.sys Local Privilege Escalation Vulnerability iDefense Security Advisory 07.11.07 http://labs.idefense.com/intelligence/vulnerabilities/ Jul 11, 2007 I. BACKGROUND Symantec has a wide range of Anti-Virus and Internet Security products that are designed to protect users from viruses and other harmful software. More information can be found on the Symantec site at the following URL. http://www.symantec.com/ II. DESCRIPTION Local exploitation of an input validation vulnerability in version 5.5.1.6 of symtdi.sys allows attackers to elevate privileges to SYSTEM. The vulnerability specifically exists due to improper address space validation when the \\symTDI\ device driver processes IOCTL 0x83022323. An attacker can overwrite an arbitrary address, including code segments, with a constant double word value by supplying a specially crafted Irp to the IOCTL handler function. III. ANALYSIS Exploitation allows an attacker to obtain elevated privileges by exploiting a kernel-mode driver. This could allow the attacker to gain complete control of the affected system. Note that since the attacker can only overwrite with a constant double-word value, exploitation is not completely straight forward. However, this does not significantly impact the difficulty of exploitation since code segments can be overwritten within the kernel. IV. DETECTION iDefense confirmed this vulnerability in version 5.5.1.6 of Symantec's symtdi.sys device driver as included with version 10 of Symantec AntiVirus Corporate Edition. Previous versions and related products that contain the affected driver are suspected vulnerable. V. WORKAROUND iDefense is currently unaware of any effective workaround for this issue. VI. VENDOR RESPONSE Symantec has addressed this vulnerability by releasing updated versions of the SymTDI.sys device driver. The updated driver has been made available via LiveUpdate. For more information consult Symantec's advisory at the following URL. http://securityresponse.symantec.com/avcenter/security/Content/2007.07.11d.html VII. CVE INFORMATION The Common Vulnerabilities and Exposures (CVE) project has assigned the name CVE-2007-3673 to this issue. This is a candidate for inclusion in the CVE list (http://cve.mitre.org/), which standardizes names for security problems. VIII. DISCLOSURE TIMELINE 01/10/2007 Initial vendor notification 01/11/2007 Initial vendor response 07/11/2007 Coordinated public disclosure IX. CREDIT This vulnerability was reported to iDefense by Zohiartze Herce. Get paid for vulnerability research http://labs.idefense.com/methodology/vulnerability/vcp.php Free tools, research and upcoming events http://labs.idefense.com/ X. LEGAL NOTICES Copyright © 2007 iDefense, Inc. Permission is granted for the redistribution of this alert electronically. It may not be edited in any way without the express written consent of iDefense. If you wish to reprint the whole or any part of this alert in any other medium other than electronically, please e-mail [EMAIL PROTECTED] for permission. Disclaimer: The information in the advisory is believed to be accurate at the time of publishing based on currently available information. Use of the information constitutes acceptance for use in an AS IS condition. There are no warranties with regard to this information. Neither the author nor the publisher accepts any liability for any direct, indirect, or consequential loss or damage arising from use of, or reliance on, this information. ___ 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] Paper: Anti Forensics: making computer forensics hard.
Yo, In this paper (translated from Portuguese in 2006) is presented since basic until advanced techniques used to defeat forensic analysis. Including the following topics: - What is computer forensics? - What is Anti Forensics? - Anti Forensics methods: Encryption. Steganography. Self Split Files + Encryption. Defeat last modified files technique. Wipe. Data Hiding: swap, file system bad blocks, unallocated spaces, ADS. Process dump. Integrity check (MD5 Collision). Database Rootkits. BIOS Rootkits. You can check the full paper in: http://ws.hackaholic.org/slides/AntiForensics-CodeBreakers2006-Translation-To-English.pdf Wendel Guglielmetti Henrique http://ws.hackaholic.org - personal page ___ 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] Calyptix Security Advisory CX-2007-05 - eSoft InstaGate EX2 Cross-Site Request Forgery Attack
Calyptix Security Advisory CX-2007-05 eSoft InstaGate EX2 Cross-Site Request Forgery Attack Date: 07/11/2007 http://www.calyptix.com/ http://labs.calyptix.com/CX-2007-05.php http://labs.calyptix.com/CX-2007-05.txt [ Overview ] Multiple versions of eSoft's InstaGate EX2 UTM device are vulnerable to cross-site request forgery. The vulnerable firmwares include 3.1.20031001, 3.1.20060921, and 3.1.20070605. Other eSoft products were not tested. This vulnerability allows an attacker to run commands on the web interface if the attacker can get the eSoft user to view a hostile web page while logged into his eSoft. These actions could include opening up remote access. There are additional problems which are bad on their own, and also exacerbate the CSRF vulnerability: 1. A logged-in user can change the admin password without knowing the existing password. 2. The current admin password is visible in the source of the administrator's setting page. 3. The device provides no mechanism for logging out. (Closing your browser completely will usually accomplish this, although the device does not tell you this.) [ Risk ] Calyptix Security has classified this vulnerability as 'Medium-to-High Risk', based on the exacerbating conditions. This attack requires the attacker to know the URL that is used to manage the device. While this could conceivably be hard to guess, in practice many are given addresses at the start of RFC 1918 address spaces, such as 10.0.0.1 or 192.168.0.1. The attacker can try several addresses simultaneously. [ Patch / Fix / Workaround ] Versions including and after 3.1.20070615 have taken defenses against the CSRF attack, as well as addressing all three of the mitigating circumstances listed above. Note that this is not the most recent software for the InstaGate as listed at http://support.esoft.com . That listed version is vulnerable. Please check to be sure that your version number is at least 3.1.20070615. Some fixes may also be in 3.1.20070610, the release notes of which indicate added functionality to improve GUI security. eSoft's spokesman couldn't recall when the fix had been made: http://www.eweek.com/article2/0,1759,2154646,00.asp Please be aware that many products have this vulnerability. Even if you use devices besides InstaGate, you are advised to follow these steps to reduce your exposure. 1. Use web management in isolation. Each browser instance should only connect to one device's web interface. Do not operate multiple windows or tabs when managing a device. As a suggested approach, you could use Firefox to browse the web while using Internet Explorer to manage only your firewall. You could also run your favorite browser inside of a virtual machine. 2. Log out of your web interface when not using it, and configure its inactivity timeouts. 3. Update to the latest version of your product's software. CSRF attacks have only recently gained popularity, so any device more than a few years old is very likely to be vulnerable to them. 4. Disable JavaScript. Note that many devices and websites require JavaScript to be enabled. Authorizing sites on a case-by-case basis to use JavaScript can significantly reduce this vulnerability. (Please note that there may still be ways of exploiting this without JavaScript, but they generally involve social engineering or a poorly designed web interface.) 5. Operate your web management interface on a non-standard address and/or port. (Please note that this is security through obscurity, and although it may protect you from general attacks, anyone targeting you will likely be able to figure out the address.) [ Analysis ] Many web sites and web products use persistent authentication. After the user logs in, all future requests are automatically granted access. A common way of doing this is to give the browser a cookie, which it automatically supplies with every request. The server checks for the existence of this cookie on all important actions. A hostile web page can contain an invisible copy of the form that the firewall's web interface uses to, for example, create a new user. The form can be submitted without any action required on the end user's part. The browser will make the submission, automatically including the cookie. The server sees the cookie and processes the request as if the end user made it naturally. There are other methods of persistent authentication besides cookies; some of these are also vulnerable to CSRF, others are not. [ Disclosure Timeline ] 06/13/2007: Vulnerability discovered 06/14/2007: eSoft emailed (to info@ and suggestions@; security@ bounces) 06/22/2007: eSoft emailed again (to pr@, sales@, support@) 07/03/2007: eSoft responds through media as having fixed it 07/10/2007: version 3.1.20070615 confirmed to be secure 07/11/2007: Calyptix releases advisory [ Version Clarification ] We originally tested the 3.1.20060921 firmware version and believed it to be up-to-date, because it
Re: [Full-disclosure] Wachovia Bank website sends confidential information
Or hey, if you're not getting anywhere with him, talk to this guy! http://www.belkcollege.uncc.edu/jpfoley/ Let me see: wachovia security cissp incident +network via Google This looks interesting: http://www.bryceporter.com/ I would have contacted someone on this level to put me in touch with the right person. But hey, guess its more hip to add stupid little tags next to your resume or webpage: I broke $INSERT_VENDOR_HERE -- Lasciate ogne speranza, voi ch'intrate ___ 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] Wachovia Bank website sends confidential information
On Wed, 2007-07-11 at 12:03 -0400, Bob Bruen wrote: While it is true that lots of folk pick on vendors for a few minutes of fame, the Wachovia case is slightly different. They do have an attitude problem and are technically challenged. The basis for this is a law enforcement conference about six months ago. During a pressentation a Wachovia representative told a speaker to stop blaming the banks for problems. This was the third presentation this individual has listened to in which each speaker had blamed the banks for not doing enough and the frustration level was a bit high. So you declare the whole of Wachovia technically challenged based on the one incident at a security conference (did all of Wachovia attend?) six months ago? Come on. ;-) Wachovia, like every other large enterprise, has good, mediocre, and bad employees. It's a fact of life, but not a news worthy story. I'm sure that some days the best and brightest represent Wachovia at some conference somewhere, and I am equally sure that some days the worst and most deplorable represent Wachovia at some conference somewhere. It happens. -Jim P. ___ 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] Wachovia Bank website sends confidential information
Hi Jim, No, I did not declare the whole of Wachovia technically challenged based on the one incident at a security conference.. What I was pointing out is that the current problem of their failure to put up a secure web and their failure to respond to notification about has another data point from 6 about months ago. In general enterprises send only a small group of people to any given conference, so no, the whole of Wachovia did not attend. Nevertheless, when you are the one attending, you are a representive of that enterprise. You seemed to have missed the point that I was adding to a discussion, not trying to create a new one. My point was in the dustbin, where it would have stayed, until the current discussion appeared. -- bob On Wed, 11 Jul 2007, Jim Popovitch wrote: On Wed, 2007-07-11 at 12:03 -0400, Bob Bruen wrote: While it is true that lots of folk pick on vendors for a few minutes of fame, the Wachovia case is slightly different. They do have an attitude problem and are technically challenged. The basis for this is a law enforcement conference about six months ago. During a pressentation a Wachovia representative told a speaker to stop blaming the banks for problems. This was the third presentation this individual has listened to in which each speaker had blamed the banks for not doing enough and the frustration level was a bit high. So you declare the whole of Wachovia technically challenged based on the one incident at a security conference (did all of Wachovia attend?) six months ago? Come on. ;-) Wachovia, like every other large enterprise, has good, mediocre, and bad employees. It's a fact of life, but not a news worthy story. I'm sure that some days the best and brightest represent Wachovia at some conference somewhere, and I am equally sure that some days the worst and most deplorable represent Wachovia at some conference somewhere. It happens. -Jim P. ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ -- Dr. Robert Bruen Cold Rain Technologies http://coldrain.net +1.802.579.6288 ___ 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] Wachovia Bank website sends confidential information
The link now redirects to an HTTPS page -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bob Toxen Sent: Tuesday, July 10, 2007 8:20 PM To: full-disclosure@lists.grok.org.uk Subject: [Full-disclosure] Wachovia Bank website sends confidential information Wachovia Bank website sends confidential information (social security numbers, phone number, address, etc.) over the Internet without encryption. Horizon Network Security Security Advisory 07/10/2007 http://VerySecureLinux.com/ Jul 10, 2007 I. BACKGROUND Wachovia Bank's official web site offers the following URL to allow its customers to change their privacy preferences: http://www.wachovia.com/privacy Wachovia also notified its customers by U.S. Mail that they can use that same URL besides. That URL has a link to the following to actually change one's preferences: http://www.wachovia.com/personal/forms/privacy_optout Unfortunately, that page appears to be an ordinary HTML form whose filled out data then is transmitted via the post method to an http (not https) URL. III. ANALYSIS We inspected the page's source via our Opera browser. (We did not sniff the web traffic so we are not absolutely sure that there is not some hidden encryption method, though there appears to be none.) IV. DETECTION It is trivial to inspect the page source or sniff the data to demonstrate the problem. The problem has not been corrected. V. WORKAROUND Use a method other than their web site to exercise one's preferences. VI. VENDOR RESPONSE The vendor (Wachovia Bank) was notified via their customer service phone number on June 25. We were transferred to web support. The person answering asked us to FAX the details to her and we did so, also on June 25. We explained that we were reporting a severe security problem on their web site. We stated that that if we did not hear back from them within 7 days and the problem was not fixed by then that we would post the problem on the Full Disclosure list, following accepted industry practice. To date we have received no response and the problem remains unfixed. VII. CVE INFORMATION There is no CVE number. VIII. DISCLOSURE TIMELINE 06/25/2007 Initial vendor notification 06/25/2007 Vendor requested FAXed details 06/25/2007 Details FAXed to vendor 07/20/2007 No vendor response 07/20/2007 Public disclosure on this Full Disclosure list IX. CREDIT This problem was discovered by Bob Toxen, one of our engineers. X. LEGAL NOTICES Copyright C 2007 Horizon Network Security. All rights reserved. Permission is granted for the redistribution of this alert electronically. It may not be edited without the express written consent of Horizon Network Security. If you wish to reprint the whole or any part of this alert in any other medium other than electronically, please e-mail [EMAIL PROTECTED] for permission. Disclaimer: The information in the advisory is believed to be accurate at the time of publishing, based on currently available information. Use of the information constitutes acceptance for use in an AS IS condition and waiving of the right to any action against Horizon Network Security or its employees or contractors. There are no warranties with regard to this information. Neither the author nor the publisher accepts any liability for any direct, indirect, or consequential loss or damage arising from use of, or reliance on, this information. We believe Wachovia Bank is obligated by California's security breach disclosure laws to notify its California customers who may have used this form and the State of California. Other jurisdictions also may have notification requirements. Bob Toxen, Horizon Network Security http://www.verysecurelinux.com [Network Linux/Unix Security Consulting] http://www.realworldlinuxsecurity.com [Our 5* book: Real World Linux Security] ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.10.2/893 - Release Date: 7/9/2007 5:22 PM ___ 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] [ GLSA 200707-06 ] XnView: Stack-based buffer overflow
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Gentoo Linux Security Advisory GLSA 200707-06 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - http://security.gentoo.org/ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Severity: Normal Title: XnView: Stack-based buffer overflow Date: July 11, 2007 Bugs: #175670 ID: 200707-06 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Synopsis XnView is vulnerable to a stack-based buffer overflow and possible remote code execution when handling XPM image files. Background == XnView is software to view and convert graphics files. XPixMap (XPM) is a simple ascii-based graphics format. Affected packages = --- Package / Vulnerable / Unaffected --- 1 x11-misc/xnview1.70 Vulnerable! --- # Package 1 only applies to x86 users. --- NOTE: Certain packages are still vulnerable. Users should migrate to another package if one is available or wait for the existing packages to be marked stable by their architecture maintainers. Description === XnView is vulnerable to a stack-based buffer overflow while processing an XPM file with an overly long section string (greater than 1024 bytes). Impact == An attacker could entice a user to view a specially crafted XPM file with XnView that could trigger the vulnerability and possibly execute arbitrary code with the rights of the user running XnView. Workaround == There is no known workaround at this time. Resolution == No update appears to be forthcoming from the XnView developer and XnView is proprietary, so the XnView package has been masked in Portage. We recommend that users select an alternate graphics viewer and conversion utility, and unmerge XnView: # emerge --unmerge xnview References == [ 1 ] CVE-2007-2194 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-2194 Availability This GLSA and any updates to it are available for viewing at the Gentoo Security Website: http://security.gentoo.org/glsa/glsa-200707-06.xml Concerns? = Security is a primary focus of Gentoo Linux and ensuring the confidentiality and security of our users machines is of utmost importance to us. Any security concerns should be addressed to [EMAIL PROTECTED] or alternatively, you may file a bug at http://bugs.gentoo.org. License === Copyright 2007 Gentoo Foundation, Inc; referenced text belongs to its owner(s). The contents of this document are licensed under the Creative Commons - Attribution / Share Alike license. http://creativecommons.org/licenses/by-sa/2.5 signature.asc Description: This is a digitally signed message part ___ 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] Wachovia Bank website sends confidential information
On Wed, Jul 11, 2007 at 12:38:54PM -0400, Steve Ragan wrote: The link now redirects to an HTTPS page Thanks Steve. This proves the value of Full Disclosure. This seems to have changed within a few hours of my posting to Full Disclosure rather than in the several weeks after I first alerted it. Note that Wachovia still has not subsequently contacted me to thank me, acknowledge my work, or to threaten me. Yes, the page that consumers can get to by navigating Wachovia's web site (or in response to the paper mail Wachovia sent out) now is the following, which posts using https to provide strong encryption: https://www.wachovia.com/personal/forms/privacy_optout It has comments with time-stamps of late yesterday, after I disclosed on the list: !-- Vignette V6 Tue Jul 10 19:28:33 2007 -- I do note that the existing URL: http://www.wachovia.com/personal/forms/privacy_optout still exists and is accessible. That http page still appears to post the SSN, etc. unencrypted. Clearly, someone needs to delete the old page or only allow it as https. Of course, this is a very minor issue as there is no way for a consumer trip over this page accidentally. I wonder if Wachovia will follow the California state breach security policy. Bob -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bob Toxen Sent: Tuesday, July 10, 2007 8:20 PM To: full-disclosure@lists.grok.org.uk Subject: [Full-disclosure] Wachovia Bank website sends confidential information Wachovia Bank website sends confidential information (social security numbers, phone number, address, etc.) over the Internet without encryption. Horizon Network Security Security Advisory 07/10/2007 http://VerySecureLinux.com/ Jul 10, 2007 I. BACKGROUND Wachovia Bank's official web site offers the following URL to allow its customers to change their privacy preferences: http://www.wachovia.com/privacy Wachovia also notified its customers by U.S. Mail that they can use that same URL besides. That URL has a link to the following to actually change one's preferences: http://www.wachovia.com/personal/forms/privacy_optout Unfortunately, that page appears to be an ordinary HTML form whose filled out data then is transmitted via the post method to an http (not https) URL. III. ANALYSIS We inspected the page's source via our Opera browser. (We did not sniff the web traffic so we are not absolutely sure that there is not some hidden encryption method, though there appears to be none.) IV. DETECTION It is trivial to inspect the page source or sniff the data to demonstrate the problem. The problem has not been corrected. V. WORKAROUND Use a method other than their web site to exercise one's preferences. VI. VENDOR RESPONSE The vendor (Wachovia Bank) was notified via their customer service phone number on June 25. We were transferred to web support. The person answering asked us to FAX the details to her and we did so, also on June 25. We explained that we were reporting a severe security problem on their web site. We stated that that if we did not hear back from them within 7 days and the problem was not fixed by then that we would post the problem on the Full Disclosure list, following accepted industry practice. To date we have received no response and the problem remains unfixed. VII. CVE INFORMATION There is no CVE number. VIII. DISCLOSURE TIMELINE 06/25/2007 Initial vendor notification 06/25/2007 Vendor requested FAXed details 06/25/2007 Details FAXed to vendor 07/20/2007 No vendor response 07/20/2007 Public disclosure on this Full Disclosure list IX. CREDIT This problem was discovered by Bob Toxen, one of our engineers. X. LEGAL NOTICES Copyright C 2007 Horizon Network Security. All rights reserved. Permission is granted for the redistribution of this alert electronically. It may not be edited without the express written consent of Horizon Network Security. If you wish to reprint the whole or any part of this alert in any other medium other than electronically, please e-mail [EMAIL PROTECTED] for permission. Disclaimer: The information in the advisory is believed to be accurate at the time of publishing, based on currently available information. Use of the information constitutes acceptance for use in an AS IS condition and waiving of the right to any action against Horizon Network Security or its employees or contractors. There are no warranties with regard to this information. Neither the author nor the publisher accepts any liability for any direct, indirect, or consequential loss or damage arising from use of, or reliance on, this information. We believe Wachovia Bank is obligated by California's security breach disclosure laws to notify its California customers who may have used this form and the State of California. Other jurisdictions also may have
[Full-disclosure] iDefense Security Advisory 07.11.07: SquirrelMail G/PGP Plugin deleteKey() Command Injection Vulnerability
SquirrelMail G/PGP Plugin deleteKey() Command Injection Vulnerability iDefense Security Advisory 07.11.07 http://labs.idefense.com/intelligence/vulnerabilities/ Jul 11, 2007 I. BACKGROUND The SquirrelMail G/PGP Encrpytion Plugin is a general purpose encryption, decryption, and digital signature plug-in for SquirrelMail that implements the OpenPGP standard using GPG. More information is available at the following URL. http://www.squirrelmail.org/plugin_view.php?id=153 II. DESCRIPTION Remote exploitation of a command injection vulnerability in the G/PGP Encrpytion Plugin for The SquirrelMail Project Team's SquirrelMail webmail package allows attackers to execute arbitrary commands with the privileges of the underlying web server. The problem specifically exists within the function deleteKey() defined in gpg_keyring.php. A call is made to exec() with unfiltered user-supplied data as demonstrated in the following piece of code: $command = $path_to_gpg --batch --no-tty --yes --homedir \ $gpg_key_dir $flag $fpr 21; exec($command, $output, $returnval); The deleteKey() routine is called from three files: import_key_file.php, import_key_text.php and keyring_main.php. the '$fpr' variable from above is supplied in the POST data. The attacker must have a valid authenticated session to exploit this vulnerability. III. ANALYSIS Exploitation of the described vulnerability allows authenticated remote attackers to execute arbitrary commands with the privileges of the underlying web server. This vulnerability could be exploited by webmail users to gain shell access on the target server and potentially further compromise the system with local privilege escalation vulnerabilities. IV. DETECTION iDefense has confirmed the existence of this vulnerability in the latest version of the G/PGP Encryption Plugin for SquirrelMail, version 2.1. Furthermore, this vulnerability has been confirmed to exist as early as version 2.0. Other versions may be affected. V. WORKAROUND Disable the G/PGP Plugin if it is not required. Alternatively, add the following line above the initialization of the '$command' variable just prior to the call to exec(): $fpr = escapeshellarg($fpr); Please note that this is an unofficial source patch, but should be sufficient as a workaround until an official patch is released from the vendor. VI. VENDOR RESPONSE The maintainers of the SquirrelMail G/PGP plug-in have not responded to repeated inquires regarding this vulnerability. As such, it remains unpatched, even in the most current release made on July 7th, 2007. VII. CVE INFORMATION The Common Vulnerabilities and Exposures (CVE) project has assigned the name CVE-2005-1924 to this issue. This is a candidate for inclusion in the CVE list (http://cve.mitre.org/), which standardizes names for security problems. VIII. DISCLOSURE TIMELINE 10/27/2005 Initial vendor notification 10/27/2005 Initial vendor response 03/02/2006 Second vendor notification 02/16/2007 Third vendor notification 07/11/2007 Public disclosure IX. CREDIT The discoverer of this vulnerability wishes to remain anonymous. Get paid for vulnerability research http://labs.idefense.com/methodology/vulnerability/vcp.php Free tools, research and upcoming events http://labs.idefense.com/ X. LEGAL NOTICES Copyright © 2007 iDefense, Inc. Permission is granted for the redistribution of this alert electronically. It may not be edited in any way without the express written consent of iDefense. If you wish to reprint the whole or any part of this alert in any other medium other than electronically, please e-mail [EMAIL PROTECTED] for permission. Disclaimer: The information in the advisory is believed to be accurate at the time of publishing based on currently available information. Use of the information constitutes acceptance for use in an AS IS condition. There are no warranties with regard to this information. Neither the author nor the publisher accepts any liability for any direct, indirect, or consequential loss or damage arising from use of, or reliance on, this information. ___ 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] iDefense Security Advisory 07.11.07: SquirrelMail G/PGP Plugin gpg_check_sign_pgp_mime() Command Injection Vulnerability
SquirrelMail G/PGP Plugin gpg_check_sign_pgp_mime() Command Injection Vulnerability iDefense Security Advisory 07.11.07 http://labs.idefense.com/intelligence/vulnerabilities/ Jul 11, 2007 I. BACKGROUND The SquirrelMail G/PGP Encrpytion Plugin is a general purpose encryption, decryption, and digital signature plug-in for SquirrelMail that implements the OpenPGP standard using GPG. More information is available at the following URL. http://www.squirrelmail.org/plugin_view.php?id=153 II. DESCRIPTION Remote exploitation of a command injection vulnerability in the G/PGP Encrpytion Plugin for The SquirrelMail Project Team's SquirrelMail webmail package allows attackers to execute arbitrary commands with the privileges of the underlying web server. The problem specifically exists within the function gpg_check_sign_pgp_mime() defined in gpg_hook_functions.php. A call is made to exec() with unfiltered user-supplied data as demonstrated in the following piece of code: $command = echo -n \$messageSignedText\ | $path_to_gpg --batch \ --no-tty --homedir $gpg_key_dir --verify .\ $detachedSignatureFilename.- 21; if ($debug) echo gpg command: .$command.\; exec($command, $results, $returnval); The '$messageSignedText' variable from above contains the stripped e-mail message. III. ANALYSIS Exploitation of the described vulnerability allows unauthenticated remote attackers to execute arbitrary commands with the privileges of the underlying web server. Exploitation of this vulnerability occurs when a target webmail user opens a malicious e-mail message. As such the vulnerability can be exploited by any attacker who can convince a target user to open a malicious message. IV. DETECTION iDefense has confirmed the existence of this vulnerability in version 2.0 of the G/PGP Encryption Plugin for SquirrelMail. It is suspected that earlier versions of the plug-in are also affected. V. WORKAROUND Disable the G/PGP Plugin if it is not required. Alternatively, add the following line above the initialization of the '$command' variable just prior to the call to exec(): $messageSignedText= escapeshellarg($messageSignedText); Please note that this is an unofficial source patch, but should be sufficient as a workaround. VI. VENDOR RESPONSE The maintainers of the SquirrelMail G/PGP plug-in have not responded to repeated inquires regarding this vulnerability. Versions since 2.1devbuild12Sep06 appear to include a fix for this problem. This problem is not present in the recent 2.1 release made on July 7th, 2007. VII. CVE INFORMATION A Mitre Corp. Common Vulnerabilities and Exposures (CVE) number has not been assigned yet. VIII. DISCLOSURE TIMELINE 10/27/2005 Initial vendor notification 10/27/2005 Initial vendor response 03/02/2006 Second vendor notification 02/16/2007 Third vendor notification 07/11/2007 Public disclosure IX. CREDIT The discoverer of this vulnerability wishes to remain anonymous. Get paid for vulnerability research http://labs.idefense.com/methodology/vulnerability/vcp.php Free tools, research and upcoming events http://labs.idefense.com/ X. LEGAL NOTICES Copyright © 2007 iDefense, Inc. Permission is granted for the redistribution of this alert electronically. It may not be edited in any way without the express written consent of iDefense. If you wish to reprint the whole or any part of this alert in any other medium other than electronically, please e-mail [EMAIL PROTECTED] for permission. Disclaimer: The information in the advisory is believed to be accurate at the time of publishing based on currently available information. Use of the information constitutes acceptance for use in an AS IS condition. There are no warranties with regard to this information. Neither the author nor the publisher accepts any liability for any direct, indirect, or consequential loss or damage arising from use of, or reliance on, this information. ___ 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] iDefense Security Advisory 07.11.07: SquirrelMail G/PGP Plugin gpg_recv_key() Command Injection Vulnerability
SquirrelMail G/PGP Plugin gpg_recv_key() Command Injection Vulnerability iDefense Security Advisory 07.11.07 http://labs.idefense.com/intelligence/vulnerabilities/ Jul 11, 2007 I. BACKGROUND The SquirrelMail G/PGP Encrpytion Plugin is a general purpose encryption, decryption, and digital signature plug-in for SquirrelMail that implements the OpenPGP standard using GPG. More information is available at the following URL. http://www.squirrelmail.org/plugin_view.php?id=153 II. DESCRIPTION Remote exploitation of a command injection vulnerability in the G/PGP Encrpytion Plugin for The SquirrelMail Project Team's SquirrelMail webmail package allows attackers to execute arbitrary commands with the privileges of the underlying web server. The problem specifically exists within the function gpg_recv_key() defined in gpg_key_functions.php. A call is made to exec() with unfiltered user-supplied data as demonstrated in the following piece of code: $command = $path_to_gpg --batch --no-tty --homedir $gpg_key_dir \ --keyserver hkp://$keyserver --recv-key $searchkeyid 21; [...] exec($command, $output, $returnval); The aforementioned '$keyserver' variable is supplied in the POST data to the gpg_options.php script. The attacker must have a valid authenticated session to exploit this vulnerability. III. ANALYSIS Exploitation of the described vulnerability allows authenticated remote attackers to execute arbitrary commands with the privileges of the underlying web server. This vulnerability could be exploited by webmail users to gain shell access on the target server and potentially further compromise the system with local privilege escalation vulnerabilities. IV. DETECTION iDefense has confirmed the existence of this vulnerability in the latest version of the G/PGP Encryption Plugin for SquirrelMail, version 2.1. Furthermore, this vulnerability has been confirmed to exist as early as version 2.0. Other versions may be affected. V. WORKAROUND Disable the G/PGP Plugin if it is not required. Alternatively, add the following line above the initialization of the '$command' variable just prior to the call to exec(): $keyserver = escapeshellarg($keyserver); Please note that this is an unofficial source patch, but should be sufficient as a workaround until an official patch is released from the vendor. VI. VENDOR RESPONSE The maintainers of the SquirrelMail G/PGP plug-in have not responded to repeated inquires regarding this vulnerability. As such, it remains unpatched, even in the most current release made on July 7th, 2007. VII. CVE INFORMATION The Common Vulnerabilities and Exposures (CVE) project has assigned the name CVE-2005-1924 to this issue. This is a candidate for inclusion in the CVE list (http://cve.mitre.org/), which standardizes names for security problems. VIII. DISCLOSURE TIMELINE 10/27/2005 Initial vendor notification 10/27/2005 Initial vendor response 03/02/2006 Second vendor notification 02/16/2007 Third vendor notification 07/11/2007 Public disclosure IX. CREDIT The discoverer of this vulnerability wishes to remain anonymous. Get paid for vulnerability research http://labs.idefense.com/methodology/vulnerability/vcp.php Free tools, research and upcoming events http://labs.idefense.com/ X. LEGAL NOTICES Copyright © 2007 iDefense, Inc. Permission is granted for the redistribution of this alert electronically. It may not be edited in any way without the express written consent of iDefense. If you wish to reprint the whole or any part of this alert in any other medium other than electronically, please e-mail [EMAIL PROTECTED] for permission. Disclaimer: The information in the advisory is believed to be accurate at the time of publishing based on currently available information. Use of the information constitutes acceptance for use in an AS IS condition. There are no warranties with regard to this information. Neither the author nor the publisher accepts any liability for any direct, indirect, or consequential loss or damage arising from use of, or reliance on, this information. ___ 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] iDefense Security Advisory 07.11.07: SquirrelMail G/PGP Plugin gpg_help.php Local File Inclusion Vulnerability
SquirrelMail G/PGP Plugin gpg_help.php Local File Inclusion Vulnerability iDefense Security Advisory 07.11.07 http://labs.idefense.com/intelligence/vulnerabilities/ Jul 11, 2007 I. BACKGROUND The SquirrelMail G/PGP Encrpytion Plugin is a general purpose encryption, decryption, and digital signature plug-in for SquirrelMail that implements the OpenPGP standard using GPG. More information is available at the following URL. http://www.squirrelmail.org/plugin_view.php?id=153 II. DESCRIPTION Remote exploitation of a local file inclusion vulnerability in version 2.0 of the SquirrelMail G/PGP Plugin could allow an authenticated webmail user to execute arbitrary PHP code under the security context of the running web server. Version 2.0 of the SquirrelMail G/PGP Plugin contains an implementation flaw in the way it includes certain files. Specifically, the 'gpg_help.php' and 'gpg_help_base.php' files will include local files that are supplied via the 'help' HTTP GET request parameter. An excerpt from the code follows: 68 // Help body text is inserted here via GET parameter 69 require_once (SM_PATH.'plugins/gpg/help/' . $_GET['help'] ); By using directory traversal specifiers, an attacker can trivially cause files stored on the Web server to be parsed as PHP code. III. ANALYSIS Exploitation could allow an attacker to include an arbitrary local file on the affected host. Due to the lack of input validation on $GET_['help'], directory traversal specifiers could be utilized to parse any file on the system as PHP code. IV. DETECTION iDefense has confirmed the existence of this vulnerability in version 2.0 of the G/PGP Encryption Plugin for SquirrelMail. It is suspected that earlier versions of the plug-in are also affected. V. WORKAROUND iDefense is unaware of any available workarounds for this vulnerability. VI. VENDOR RESPONSE The maintainers of the SquirrelMail G/PGP plug-in have not responded to repeated inquires regarding this vulnerability. Versions since gpg.2.1devbuild14Jun07 appear to include a fix for this problem. This problem is not present in the recent 2.1 release made on July 7th, 2007. VII. CVE INFORMATION The Common Vulnerabilities and Exposures (CVE) project has assigned the name CVE-2006-4169 to this issue. This is a candidate for inclusion in the CVE list (http://cve.mitre.org/), which standardizes names for security problems. VIII. DISCLOSURE TIMELINE 08/16/2006 Initial vendor notification 10/06/2006 Second vendor notification 02/16/2007 Third vendor notification 07/11/2007 Public disclosure IX. CREDIT The discoverer of this vulnerability wishes to remain anonymous. Get paid for vulnerability research http://labs.idefense.com/methodology/vulnerability/vcp.php Free tools, research and upcoming events http://labs.idefense.com/ X. LEGAL NOTICES Copyright © 2007 iDefense, Inc. Permission is granted for the redistribution of this alert electronically. It may not be edited in any way without the express written consent of iDefense. If you wish to reprint the whole or any part of this alert in any other medium other than electronically, please e-mail [EMAIL PROTECTED] for permission. Disclaimer: The information in the advisory is believed to be accurate at the time of publishing based on currently available information. Use of the information constitutes acceptance for use in an AS IS condition. There are no warranties with regard to this information. Neither the author nor the publisher accepts any liability for any direct, indirect, or consequential loss or damage arising from use of, or reliance on, this information. ___ 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] iDefense Security Advisory 07.11.07: Apple QuickTime SMIL File Processing Integer Overflow Vulnerability
Apple QuickTime SMIL File Processing Integer Overflow Vulnerability iDefense Security Advisory 07.11.07 http://labs.idefense.com/intelligence/vulnerabilities/ Jul 11, 2007 I. BACKGROUND QuickTime is Apple's media player product used to render video and other media. For more information visit http://www.apple.com/quicktime/ The Synchronized Multimedia Integration Language (SMIL) provides a high-level scripting syntax for describing multimedia presentations. SMIL files are text files that use XML-based syntax to specify what media elements to present, and where and when to present them. II. DESCRIPTION Remote exploitation of an integer overflow vulnerability in Apple Computer Inc.'s QuickTime media player could allow attackers to execute arbitrary code in the context of the targeted user. The vulnerability specifically exists in QuickTime players handling of the title and author fields in an SMIL file. When parsing an SMIL file, arithmetic calculations can cause insufficient memory to be allocated. When copying in user-supplied data from the SMIL file, a heap-based buffer overflow occurs. This results in a potentially exploitable condition. III. ANALYSIS Exploitation could allow attackers to execute arbitrary code in the context of the current user. In order to exploit this vulnerability, an attacker must persuade a user into using QuickTime to open a specially crafted SMIL file. This could be accomplished using a malicious SMIL file referenced from a website under the attacker's control. IV. DETECTION iDefense Labs confirmed this vulnerability exists in version 7.1.3 and 7.1.5 of QuickTime on Windows and Mac OS X. Previous versions are suspected to be vulnerable. V. WORKAROUND iDefense is currently unaware of any effective workarounds for this vulnerability. VI. VENDOR RESPONSE Apple has released QuickTime 7.2 which resolves this issue. More information is available via Apple's QuickTime Security Update page at the URL shown below. http://docs.info.apple.com/article.html?artnum=305947 VII. CVE INFORMATION The Common Vulnerabilities and Exposures (CVE) project has assigned the name CVE-2007-2394 to this issue. This is a candidate for inclusion in the CVE list (http://cve.mitre.org/), which standardizes names for security problems. VIII. DISCLOSURE TIMELINE 04/02/2007 Initial vendor notification 04/09/2007 Initial vendor response 07/11/2007 Coordinated public disclosure IX. CREDIT This vulnerability was reported to iDefense by David Vaartjes from ITsec Security Services http://www.itsec-ss.nl/. Get paid for vulnerability research http://labs.idefense.com/methodology/vulnerability/vcp.php Free tools, research and upcoming events http://labs.idefense.com/ X. LEGAL NOTICES Copyright © 2007 iDefense, Inc. Permission is granted for the redistribution of this alert electronically. It may not be edited in any way without the express written consent of iDefense. If you wish to reprint the whole or any part of this alert in any other medium other than electronically, please e-mail [EMAIL PROTECTED] for permission. Disclaimer: The information in the advisory is believed to be accurate at the time of publishing based on currently available information. Use of the information constitutes acceptance for use in an AS IS condition. There are no warranties with regard to this information. Neither the author nor the publisher accepts any liability for any direct, indirect, or consequential loss or damage arising from use of, or reliance on, this information. ___ 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] Wachovia Bank website sends confidential information
Reconfirming time stamp(s) !-- Vignette V6 Wed Jul 11 16:13:41 2007 -- their policy pages was updated On 7/11/07, Bob Toxen [EMAIL PROTECTED] wrote: On Wed, Jul 11, 2007 at 12:38:54PM -0400, Steve Ragan wrote: It has comments with time-stamps of late yesterday, after I disclosed on the list: !-- Vignette V6 Tue Jul 10 19:28:33 2007 -- ___ 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] XSS Tunnelling White Paper and Tool
XSS Tunnelling is the tunnelling of HTTP traffic through an opened XSS Channel. Thus any application with HTTP proxy support can tunnel its traffic through an XSS Channel (a channel opened by a tool like XSS Shell). White paper is explaining XSS Tunnelling, benefits, real worlds examples and basic usage of XSS Tunnel (a local HTTP proxy for tunnelling) tool. XSS Tunelling Paper: http://www.portcullis-security.com/uplds/whitepapers/XSSTunnelling.pdf XSS Shell, XSS Tunnel Binary Releases and Source Code: http://www.portcullis-security.com/16.php A Short Demonstration Video: http://ferruh.mavituna.com/blogs/xsstunnelling-video.zip Video shows to exploit a permanent XSS in wordpress and bypass Basic Auth on the fly by XSS Tunnel. Regards, -- Ferruh Mavituna http://ferruh.mavituna.com ___ 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] IPSwitch WS_FTP Logging Server Remote Denial of Service -- a VDA Labs, LLC discovery
IPSwitch WS_FTP Logging Server Remote Denial of Service Version: 7.5.29.0 (Logsrv.exe) Overview The WS FTP logging server is a daemon that listens on UDP port 5151 and is shipped with WS FTP and by default is turned on and used by the local WS FTP instance. It binds to the public IP address of the server and is accessible externally, in part so that other WS FTP machines are able to use it as a logging interface. Description of Crash WS FTP uses a binary protocol to speak to the logging daemon, and each transmission begins with a two byte header 0xab 0xaa. If using a long string of characters to mangle the remaining portions of the message, a pointer operation fails at: 0x00401769 cmp word ptr [ecx], 0AAADh jnz short loc_401787 This crashes the process. By flipping two bytes immediately after the two primary header bytes, you are also able to control where the dereferencing address is at the time of the crash. However, this does not appear to allow code execution on the remote host as the address referenced is too far away from any user supplied input. Discovered By Justin Seitz of VDA Labs LLC ([EMAIL PROTECTED]) Full advisory and attack code location: http://www.vdalabs.com/resources http://www.vdalabs.com/tools/ipswitch.html ipswitchlogsrv-killer.py - Change the IP and PORT numbers as necessary at the top of the file. There are two bytes that lead to different address offsets where the pointer dereference is attempted. ___ 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] Updated versions of EFS and GPF
Are available here: http://www.vdalabs.com/resources Thanks, Jared ___ 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] IPSwitch WS_FTP Logging Server Remote Denial of Service -- a VDA Labs, LLC discovery
I will be sure to patch for this serious exploit vulnerability proof of concept code hack so that my machines cannot be cracked. J On Thu, 12 Jul 2007 00:15:32 -0400 Jared DeMott [EMAIL PROTECTED] wrote: IPSwitch WS_FTP Logging Server Remote Denial of Service Version: 7.5.29.0 (Logsrv.exe) Overview The WS FTP logging server is a daemon that listens on UDP port 5151 and is shipped with WS FTP and by default is turned on and used by the local WS FTP instance. It binds to the public IP address of the server and is accessible externally, in part so that other WS FTP machines are able to use it as a logging interface. Description of Crash WS FTP uses a binary protocol to speak to the logging daemon, and each transmission begins with a two byte header 0xab 0xaa. If using a long string of characters to mangle the remaining portions of the message, a pointer operation fails at: 0x00401769 cmp word ptr [ecx], 0AAADh jnz short loc_401787 This crashes the process. By flipping two bytes immediately after the two primary header bytes, you are also able to control where the dereferencing address is at the time of the crash. However, this does not appear to allow code execution on the remote host as the address referenced is too far away from any user supplied input. Discovered By Justin Seitz of VDA Labs LLC ([EMAIL PROTECTED]) Full advisory and attack code location: http://www.vdalabs.com/resources http://www.vdalabs.com/tools/ipswitch.html ipswitchlogsrv-killer.py - Change the IP and PORT numbers as necessary at the top of the file. There are two bytes that lead to different address offsets where the pointer dereference is attempted. ___ 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 lower your debt and consolidate your monthly expenses http://tagline.hushmail.com/fc/Ioyw6h4d716878MGXyA105YJMeLioAE5OXJBN3lPtxoU6pi90kPhcE/ ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
