Jira Service Desk Server and Jira Service Desk Data Center - URL path traversal allows information disclosure - CVE-2019-14994
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 This email refers to the advisory found at https://confluence.atlassian.com/jira/jira-service-desk-security-advisory-2019-09-18-976171274.html CVE ID: * CVE-2019-14994. Product: Jira Service Desk Server and Data Center. Affected Jira Service Desk Server and Data Center product versions: version < 3.9.16 3.10.0 <= version < 3.16.8 4.0.0 <= version < 4.1.3 4.2.0 <= version < 4.2.5 4.3.0 <= version < 4.3.4 4.4.0 <= version < 4.4.1 Fixed Jira Service Desk Server and Data Center product versions: * for 3.9.x and earlier, Jira Service Desk Server and Data Center 3.9.16 has been released with a fix for this issue. * for 3.16.x, Jira Service Desk Server and Data Center 3.16.8 has been released with a fix for this issue. * for 4.1.x, Jira Service Desk Server and Data Center 4.1.3 has been released with a fix for this issue. * for 4.2.x, Jira Service Desk Server and Data Center 4.2.5 has been released with a fix for this issue. * for 4.3.x, Jira Service Desk Server and Data Center 4.3.4 has been released with a fix for this issue. * for 4.4.x, Jira Service Desk Server and Data Center 4.4.1 has been released with a fix for this issue. Summary: This advisory discloses a critical severity security vulnerability. Versions of Jira Service Desk Server and Data Center are affected by this vulnerability. Customers who have upgraded Jira Service Desk Server and Data Center to version 3.9.16, 3.16.8, 4.1.3, 4.2.5, 4.3.4, or 4.4.1 are not affected. Customers who have downloaded and installed affected versions of Jira Service Desk Server and Data, please upgrade your Jira Service Desk Server and Data Center installations immediately to fix this vulnerability. URL path traversal allows information disclosure - CVE-2019-14994 Severity: Atlassian rates the severity level of this vulnerability as critical, according to the scale published in our Atlassian severity levels. The scale allows us to rank the severity as critical, high, moderate or low. This is our assessment and you should evaluate its applicability to your own IT environment. Description: By design, Jira Service Desk gives customer portal users permissions only to raise requests and view issues. This allows users to interact with the customer portal without having direct access to Jira. These restrictions can be bypassed by a remote attacker with portal access who exploits a path traversal vulnerability. Exploitation allows an attacker to view all issues within all Jira projects contained in the vulnerable instance. This could include Jira Service Desk projects, Jira Core projects, and Jira Software projects. Note that attackers can grant themselves access to Jira Service Desk portals that have the 'Anyone can email the service desk or raise a request in the portal' setting enabled. Changing this setting does not defend against an attacker that has portal access via other means. Atlassian does not recommend changing the setting. Instead, upgrade to a non-vulnerable version listed below. Versions of Jira Service Desk Server and Data Center before 3.9.16 (the fixed version for 3.9.x), from version 3.10.0 before 3.16.8 (the fixed version for 3.16.x), from version 4.0.0 before 4.1.3 (the fixed version for 4.1.x), from version 4.2.0 before 4.2.5 (the fixed version for 4.2.x), from version 4.3.0 before 4.3.4 (the fixed version for 4.3.x), and from version 4.4.0 before 4.4.1 (the fixed version for 4.4.x) are affected by this vulnerability. This issue can be tracked at: https://jira.atlassian.com/browse/JSDSERVER-6517. Fix: To address this issue, we've released the following versions containing a fix: * Jira Service Desk Server and Data Center version 3.9.16 * Jira Service Desk Server and Data Center version 3.16.8 * Jira Service Desk Server and Data Center version 4.1.3 * Jira Service Desk Server and Data Center version 4.2.5 * Jira Service Desk Server and Data Center version 4.3.4 * Jira Service Desk Server and Data Center version 4.4.1 Remediation: Upgrade Jira Service Desk Server and Data Center to version 4.4.1 or higher. The vulnerabilities and fix versions are described above. If affected, you should upgrade to the latest version immediately. If you are running Jira Service Desk Server and Data Center 3.9.x and cannot upgrade to 4.4.1, upgrade to version 3.9.16. If you are running Jira Service Desk Server and Data Center 3.16.x and cannot upgrade to 4.4.1, upgrade to version 3.16.8. If you are running Jira Service Desk Server and Data Center 4.1.x and cannot upgrade to 4.4.1, upgrade to version 4.1.3. If you are running Jira Service Desk Server and Data Center 4.2.x and cannot upgrade to 4.4.1, upgrade to version 4.2.5. If you are running Jira Service Desk Server and Data Center 4.3.x and cannot upgrade to 4.4.1, upgrade to version 4.3.4. For a full description of the latest version of Jira Service Desk Server and Data Center, see the release notes found at https://confluence.atlassian.com
[ANNOUNCE][CVE-2016-6802] Apache Shiro 1.3.2 released
The Shiro team is pleased to announce the release of Apache Shiro version 1.3.2. This security release contains 1 fix since the 1.3.1 release and is available for Download now [1]. CVE-2016-6802: Apache Shiro before 1.3.2, when using a non-root servlet context path, specifically crafted requests can be used to by pass some security servlet filters, resulting in unauthorized access. Release binaries (.jars) are also available through Maven Central and source bundles through Apache distribution mirrors. For more information on Shiro, please read the documentation[2]. -The Apache Shiro Team [1] http://shiro.apache.org/download.html [2] http://shiro.apache.org/documentation.html
[Announce] CVE-2016-4437: Apache Shiro information disclosure vulnerability
Severity: Important Vendor: The Apache Software Foundation Versions Affected: 1.0.0-incubating - 1.2.4 Description: A default cipher key is used for the "remember me" feature when not explicitly configured. A request that included a specially crafted request parameter could be used to execute arbitrary code or access content that would otherwise be protected by a security constraint. Mitigation: Users should upgrade to 1.2.5 [1], ensure a secret cipher key is configured [2], or disable the "remember me" feature. [3] All binaries (.jars) are available in Maven Central already. References: [1] http://shiro.apache.org/download.html [2] http://shiro.apache.org/configuration.html#Configuration-ByteArrayValues [3] If using a shiro.ini, "remember me" can be disabled adding the following config line in the '[main]' section: securityManager.rememberMeManager = null
CVE-2015-4670 - AjaxControlToolkit File Upload Directory Traversal
The AjaxControlToolkit prior to version 15.1 has a file upload directory traversal vulnerability which on a poorly configured web server can lead to remote code execution. The issue affects any application using the AjaxFileUpload control. The vulnerability arises because the =E2=80=9CfileId=E2=80=9D is not validated = and can be altered by the user to contain directory traversal characters (\..\..\..\) allowing an attacker to write the uploaded file to any location on the file system that the web server=E2=80=99s file permissions allow. The "fileid" parameter is passed when uploading files. Intercepting the request and modifying the value of "fileid" to a directory path will result in the file being uploaded to be placed in the location on the remote server as long as file system permissions allow. If an attacker is capable of writing an arbitrary file to the server's web directory then remote code execution is possible. A demonstration of this is written here: http://www.cardinaleconcepts.com/cve-2015-4670-directory-traversal-to-remot= <http://www.cardinaleconcepts.com/cve-2015-4670-directory-traversal-to-remot=> e-code-execution-in-ajaxcontroltoolkit/ This issue has been reported to the vendor and an updated version of the library has been made available. CVE Number: CVE-2015-4670 Discovered by: Brian Cardinale Write Up: http://www.cardinaleconcepts.com/cve-2015-4670-directory-traversal-to-remot= <http://www.cardinaleconcepts.com/cve-2015-4670-directory-traversal-to-remot=> e-code-execution-in-ajaxcontroltoolkit/ Sample Vuln App: https://bitbucket.org/bcardinale/cve-2015-4670-vuln-app/sr= <https://bitbucket.org/bcardinale/cve-2015-4670-vuln-app/sr=> c Affected Versions: * 7.1213.0 * 7.1005.0 * 7.1002.0 * 7.930.0 * 7.725.0 * 7.607.0 * 7.429.0
Re: DDIVRT-2011-39 SolarWinds Storage Manager Server SQL Injection Authentication Bypass
This issue was fixed with a hotfix and in subsequent version, 5.2. See: http://ddilabs.blogspot.com/2012/02/solarwinds-storage-manager-server-sql.html
Re: WikkaWiki <= 1.3.2 Multiple Security Vulnerabilities
This was patched 12Dec as reported by Secunia: http://secunia.com/advisories/47034/ Really is rather irresponsible to continue to report an exploit as unpatched that has, in fact, been patched.
Re: Web Tool Announcement: ismymailsecure.com
On Wed, 25 Aug 2010, Tim wrote: It's unfortunate that STARTTLS is currently a disaster to configure securely, particularly because it is just a point-to-point encryption mechanism and all of this complexity has to be addressed at every hop. I think as a security community we'd be a lot better off putting our efforts into encouraging end-to-end encryption with S/MIME or PGP/MIME. That's the conclusion we came to in the NHIN Direct project (http://nhindirect.org/, secure messaging for the health IT industry) though server-server TLS with agreed-upon CAs (establishing "trust circles") are helpful. What TLS didn't appear to allow is negotiation of CAs - which ones do I trust, which ones do you have signatures from, what's the intersection. That would allow it to grow more intelligently than the "trust this long list of root CAs" model that web browsers use. In our case it's useful to also encrypt the server-server link, even if you are S/MIME encrypting the message content, because From/To/Subject data can be pretty sensitive. Seeing encrypted SSL traffic between suttermentalhealth.com and healthvault.com is a lot less revealing than From: dr...@suttermentalhealth.com To: br...@healthvault.com Subject: Are you taking your meds? Brian
Re: Major security risk in the unlock pattern for Android devices
Sure you would. Most people press slightly harder initially, and usually the beginning and end points will be rounded. Would I say its a "major" risk? No. The "locking" features of most phones have no real security purpose at all, just psychological peace. Brian Altenhofel http://www.facebook.com/brian.altenhofel http://www.linkedin.com/in/brianaltenhofel http://www.twitter.com/BrianAltenhofel http://www.vmdoh.com
WowWee Rovio - Insufficient Access Controls - Covert Audio/Video Snooping Possible
SUMMARY WowWee Rovio - Insufficient Access Controls - Covert Audio/Video Snooping Possible OVERVIEW Rovio from WowWee does not adequately secure all accessible URLs or media streams, enabling an unauthorized user with network access to the robotic webcam platform the ability to listen to and view audio/video streamed from the device's onboard camera. Additionally, audio-send capabilities are also not secured, enabling mischievous sending of audio through Rovio's built-in speaker. Additional manipulations may be possible, robot control does not appear to be impacted at this time. DESCRIPTION >From WowWee Website: Rovio(tm) is the ground breaking new Wi-Fi enable mobile webcam that lets you view and interact with its environment through streaming video and audio, wherever you are! Unfortunately, Rovio's access control mechanisms (username/password) are not completely utilized across the platform even when enabled. Certain URLs and RTSP Streaming capabilities of the device are accessible with no authentication. Furthermore, deployment of the device in the default configuration attempts to use UPnP to automatically configure your firewall to allow external access to the mobile webcam platform. Resources exposed without proper access controls include: rtsp://[rovio]/webcam -- RTSP Audio/Video Stream, directly accessible. and the following http://[rovio]:[publishedport]/ URLs are accessbile to anyone: /GetUPnP.cgi-- Get UPnP config, including ports in use for RTSP /GetStatus.cgi -- display general device status /GetVer.cgi -- display firmware version, enables targeted attacks, discovery. /ScanWlan.cgi -- display WiFi Networks visible to device /GetAudio.cgi -- "Send" audio to Rovio's speaker, "What's up Doc?" /GetMac.cgi -- device mac adress /Upload.cgi -- upload new firmware [actual upload untested] /GetUpdateProgress.cgi /GetTime.cgi /GetLogo.cgi /GetName.cgi /GetVNet.cgi /description.xml /cmgr/control /cmgr/event /cdir/control /cdir/event /Cmd.cgi-- Accessible without arguments, but does not appear to allow ACL bypass to normally protected sub-commands. Unknown if any hidden commands exist. /SendHttp.cgi -- When authentication is enabled, this appears to be protected. However in a default configuration with no authentication, it could provide for interesting reverse-proxy like manipulation of web-based firewall admin interfaces. Additionally, this script is used by the "Ping Test" that WowWee sends to their servers to help verify your internet connectivity and UPnP settings are working. What's disheartening here is that your IP address and rovio's port are sent to WowWee and potentially stored in their server logs. ADDITIONAL ISSUES Additionally, WowWee is advised that they should alter the default configuration to not automatically utilize UPnP to attempt to open up external access to these devices. 1) In the default configuration no authentication is required until the user sets up accounts. 2) Proper notification should be displayed to users regarding the potential risks and ramifications of these settings and they must be involved in the decision process, by being required to take action action to agree to expose such devices to external access. Additionally, it should be noted that the platform uses HTTP Basic authentication over unencrypted HTTP. Using such mechanisms across the internet does expose users to network-sniffing attacks, where an attacker could obtain the credentials or observe the data streams being transmitted. IMPACT Users of this mobile wi-fi webcam may unwittingly open their homes up to anonymous eaves-dropping of their personal lives and communications. SOLUTION WowWee must supply an updated firmware that fixes these issues. WORKAROUND Users of these devices are encouraged to disable direct external access and seek other means to secure such access (Authenticated, Encyrpting Proxies, or Access over a VPN connection for example). It is understood that most consumers of these devices do not have such means, so WowWee should be compelled to provide adequate protection and access controls. REFERENCES http://www.simplicity.net/vuln/2009-01-Rovio-insecurity.html http://www.wowwee.com/en/products/tech/household/rovio CREDIT This issue was discovered and disclosed by Brian Dowling of Simplicity Communications. HISTORY 2009-01-06 - Initial Report to WowWee support. 2009-01-07 - Second request to simply conf
InstallShield Update Agent - Downloads and executes "Rule Scripts" insecurely.
t is assumed that the vendor has/will taken the actions they deem appropriate to notify its customer base. SOLUTION No vendor provided solution is known at this time. The vendor largely discounts the issue, implying that it may be difficult to exploit and that following best practices to secure the server systems would prevent this from being exploited. They have provided a brief document to this effect, unfortunately they also tagged it as confidential and I cannot release it. The vendor said they will release it when this information is published. With the addition of the Kaminsky attack, this is just another reason why you must be sure your DNS is update to date, and be proactive as new protection mechanisms come out for DNS. WORKAROUND Unfortunately, there is no good workaround to prevent this issue while still allowing critical updates for other products dependant on this platform for distribution. Enterprises that have proxy capabilities could disable access to the GetRules.asp URLs that are used to download the script instructions, however this may have consequences to programs that depend on the rules for determining patch applicability. The only way to be comfortable that you fully prevent the risk of this issue for users that are concerned with the security of their systems is to disable this automatic update program for the time being. For InstallShield, this includes removing any Autorun entries for ISSCH.EXE, ISUSPM.EXE, and possibly setting the Kill bit for any related ActiveX controls (isusweb.dll), that remain enabled (See references for one patch related to this -- it is not clear to me they covered all GUIDs with these patches). Some users may wish to rename the "\Program Files\Common Files\InstallShield\UpdateService" or related UpdateManager folders of other products to prevent automated execution of these programs until a fix is provided. Unfortunately this workaround is clearly a catch-22 as other critical updates to products that depend on these services may now be overlooked as well. Use this information at your own risk. Absolutely no warrantees expressed or implied! REFERENCES This issue has been assingned CVE-2008-1093 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1093 Also published at http://www.simplicity.net/vuln/CVE-2008-1093.txt http://www.kb.cert.org/vuls/id/837092 These prior issues are related, but are distinct from this bulletin. http://www.kb.cert.org/vuls/id/524681 http://www.kb.cert.org/vuls/id/847993 http://www.kb.cert.org/vuls/id/181041 CREDIT This issue was discovered and disclosed following responsible disclosure procedures by Brian Dowling of Simplicity Communications. HISTORY This time-line is mostly here to keep track of work and progress on this issue. However it does highlight one important thing. Vendors need to provide valid, secure, contact information that can get security issues reported to the proper individuals within their organization. This contact information should be clearly published on their public facing web sites. 12/05/2007 - Initial Discovery 12/12/2007 - Contacted Cert Coordination Center to attempt to obtain appropriate vendor contact information. 12/17/2007 - Additional work on details, proof of concept interim- No response from Macrovision either directly or through Cert (who kept in constant contact with me). 01/02/2008 - Posted to product request site for security contact information. 01/08/2008 - Automated sales response, asking how "Product Evaluation" is going. 01/18/2008 - In contact with sales representative @ Macrovision 02/05/2008 - Attempted to contact Product Technical Support 02/06/2008 - Technical Support call back - forwarded me back to "Product Coordinator" (local Sales Contact). 02/07/2008 - Contacted by Director of Product Management for Macrovision 02/08/2008 - Sent vendor vulnerability details 02/21/2008 - Resent information, vendor was unable to decrypt 03/03/2008 - Vendor responds "We are reviewing the materials and will provide a public response shortly." 03/10/2008 - Inquired if they have been able to reproduce. Similar response to above, "..public response in the coming days" 03/21/2008 - Inquired, was told they were crafting a public response. 04/01/2008 - Product vendor splits off software business, InstallShield now owned by Acresso Software. 04/24/2008 - Vendor provided "Acresso's official response" which they do not appear to have yet published publicly, and I feel I cannot due to the following legal tagging: "This document contains proprietary trade secrets of Acresso Software Inc. Receipt or possession does not convey any right to reproduce, disclose its content, or to manufacture, use, or sell a
Re: defining 0day
On 9/25/07, Adrian Griffis <[EMAIL PROTECTED]> wrote: > I understand why this descriptivist approach is tempting over a > prescriptivist approach. But it's important, I think, to keep in mind > that the public uses the word "illegal" when they really mean > "unlawful" and uses the word "Schizophrenic" when they are talking > about multiple personality disorders. All technical fields have their > jargon, and the general public is simply not well educated enough > about the issues involved to arbitrate disputes over usage. Just as > the legal profession needs the word "illegal" with its proper meaning, > we also need our jargon to facilitate precise discussions about > security matters. The public can't always be the source of our > definitions. I understand and agree. The issue is, that as with those other terms, the industry has allowed the term to be misused long enough that the public now using it wrong as well. However, the "public" I was referring to is reference materials - dictionaries, wikipedia, etc.. If a newcomer to the security field hears the term "zero day" where does he go to find out what a "zero day" exploit is? Most students go to dictionaries or the like... and whats wrong with the current definition of a "zero day"? Okay, dump "zero day" completely and choose a new term for each division of exploit or vulnerability. Blue Sky Rambling: Try to enable a unified method of disclosure for all types of exploits and vulnerabilities via a single medium/site or multiple sites with a unified form or some such. I envision a check list asking things like "is this vulnerability known to the vendor - yes/no" and "does this exploit work against latest versions and all patches - yes/no" or whatever it takes to filter disclosures and allow them to be programatically labeled and disseminated, and the "participating" vendor to be contacted - everything occurring in an orderly, acceptable fashion by way of carved-in-stone rules. Definitions of the labels can't be argued because the rules don't bend for one person's perception. If all of the right check boxes are checked, its zero day, or its not. Oh, and you have to be "certified" to release a disclosure!
Re: defining 0day
On 9/25/07, Gadi Evron <[EMAIL PROTECTED]> wrote: > No longer good enough. > > We can get a press scare over a public vuln release, or a wake-up call. > > I think we can do better as an industry. > Who, then, rewrites all of the reference material? And doesn't any new definition simply become definition number 2 in Webster? Is it really the definition that is lacking or is the use of the word at issue? Seems to me, from the beginning of this debate, that its the usage. Far easier to reform the "zero day process" (disclosure, etc.) than to redefine the term "zero day". The term is owned by the public, the process is owned by those who follow it, the industry. Couldn't a formal process be developed that does the defining/labeling of a particular disclosure?
Re: defining 0day
On 9/25/07, Gadi Evron <[EMAIL PROTECTED]> wrote: > Okay. I think we exhausted the different views, and maybe we are now able > to come to a conlusion on what we WANT 0day to mean. > > What do you, as professional, believe 0day should mean, regardless of > previous definitions? Seems to me that definitions, and language itself, is a product of evolution. You can't just remove all previous meanings. Its better anyway to stick to the most accepted, acknowledged and DOCUMENTED definitions: http://en.wikipedia.org/wiki/0day http://dictionary.reference.com/browse/zero%20day http://www.answers.com/main/ntquery?s=what+is+0day&gwp=13 Even better: http://64.233.167.104/search?q=cache:DERnyW4MM4wJ:nujia.norwich.edu/current/2_2_art01.pdf+origins+of+zero+day+definition&hl=en&ct=clnk&cd=6&gl=us&client=firefox-a or http://nujia.norwich.edu/current/2_2_art01.pdf
Re: XXS in script Phorum
Once again, a false report about Phorum. Please issue an apology ASAP. 1. upgradefiles as a var is only used inside a function. PHP does not take variables from the global scope for use in functions automatically. 2. 2 lines before that var is echoed, it is set by reading a file name from disk using the dir() function in PHP. 3. The dir() function reads from a hard coded, relative path on disk and does not use a variable. Thanks for trying. If you find a real bug, please let us know. We strive to make Phorum as bug free as possible.
Re: Phorum HTML Injection Vulnerability
I have emailed this reporter about this already. Other than allowing characters such as " and >< in a user name, there is nothing vulnerable about this page. The characters are escaped properly on this page when there is an error. I have asked for more information about this issue both via email and on our own bug tracking system. I have received no reply so far. Phorum 5.1.18 did include a FIX for an XSS issue. But, it does not appear that this reporter is referring to that.
Re: [WEB SECURITY] Universal XSS with PDF files: highly dangerous
Someone (I believe RSnake) pointed out that many browser machines have PDF files in predictable locations that can be accessed via file:// links. That lets an attacker gain local javascript execution. At one point Firefox had a rule restricting http:// and https:// web pages from accessing file:// links. Does that rule still exist, and if so does it mitigate the risk posed to firefox users? Regards, Brian
Re: [Full-disclosure] Oracle Portal 10g HTTP Response Splitting
On 12/20/06, putosoft softputo <[EMAIL PROTECTED]> wrote:
Oracle Portal/Applications HTTP Response Splitting
--
Sample:
http:///webapp/jsp/calendar.jsp?enc=iso-8859-1%0d%0aContent-length=12%0d%0a%0d%0a%3Cscript%3Ealert('hi')%3C/script%3E
So they let the URL specify the content-encoding? They might be
vulnerable to XSS via UTF-7 as well.
Regards,
Brian
Re: [Full-disclosure] IE UXSS (Universal XSS in IE, was Re: Microsoft Internet Information Services UTF-7 XSS Vulnerability [MS06-053])
On 10/2/06, Paul Szabo <[EMAIL PROTECTED]> wrote:
This provides UXSS (Universal Cross-Site Scripting):
http://apache.svr/+ADw-SCRIPT+AD4-alert('XSS');+ADw-/SCRIPT+AD4-/ZZZ...
(with a couple of hundred Zs) will do what we want. Works for https also:
https://apache.svr/+ADw-SCRIPT+AD4-alert('XSS');+ADw-/SCRIPT+AD4-/ZZZ...
Can steal any Apache server (http or https) cookies. I do not have easy
access to ISS servers to test whether similar attacks would work there.
Will Apache fix (carefully escape) the error message? Will MS fix IE to
not be so over-friendly?
This should only be possible if neither the HTTP headers nor the HTML
page specifies the character set of the document. If the server
doesn't tell IE the character set, the autodetection "feature" will
kick in, and the site is vulnerable. I just tested Apache 1.3.37 and
Apache 2.2.3, and both specified a content-type header of "text/html;
charset=iso-8859-1" for 404 responses, so the attack failed. My
browser was IE 6.0.2800.1106.
I'm guessing that you tested a server wth some kind of customized 404
response that neglected to include a charset specification. That's
not a vulnerability in Apache, that is poor site configuration.
(I do wish that IE didn't have this character set autodetection
feature, or at least that it was restricted to commonly used character
sets that don't use strange encodings for HTML metacharacters.)
Regards,
Brian
Re: Re[3]: RSA SecurID SID800 Token vulnerable by design
On 9/11/06, 3APA3A <[EMAIL PROTECTED]> wrote: BE> Two-factor auth cannot be said to make accessing the network from a BE> compromised PC "safe". That does not make two-factor auth useless. BE> With plain passwords, once the attacker has the password, they can BE> access the network at will. With two-factor auth, they can access BE> the network for a much more limited time span. Network is compromised as long as attacker keeps control under compromised host regardless of authentication. And sometimes longer. I think we're talking about different kinds of environments and authentication schemes. The example I had in mind was this one: - corporate web mail system requires two-factor auth for access - employee accesses the web mail system from a friend's machine that is loaded with spyware, authenticating using their token. - the spyware has access to the web mail system for as long as the token is in the machine - once the token is removed, the spyware can continue accessing the web mail system until the web mail system session expires So the damage is limited to what is stolen during the session, while with a password-only system the account could be used for an indefinite time period, i.e. until password change. It means, if authentication schema is NTLM-compatible (it must be for compatibility with pre-Windows 2000 hosts and some network applications, like Outlook Express), attacker can use compromised account to access network resources without having access to 2-factor authentication device. How long he can retain this access depends on how often account's NT key is changed (usually with password change, but actually depends on implementation of authentication system and may be never). Is this RSA whitepaper an example of what you are talking about? http://tinyurl.com/pb5n7 The whitepaper refers to Kerberos tickets, but the mechanism sounds like it could work with NTLM as well. I think the situation you are pointing out is where an authentication process requires an initial two-factor authentication, but then issues some kind of session key that takes a very long time to expire. That would seem to defeat the purpose of the two-factor auth. Regards, Brian
Re: [Full-disclosure] Re: RSA SecurID SID800 Token vulnerable by design
On 9/9/06, Lyal Collins <[EMAIL PROTECTED]> wrote: If there's malware on the machine, and there is a connected USB token, then authentication is only as good as the password - malware can probe the connected token as often as desired. In theory, with trusted data paths everywhere (internal to worksation as well as he network) OTP is better than passwords alone. But since this data patch assumption is rarely 100% valid, OTP is as good as a password alone. In the situation where data paths are trust-able, OTP is a somewhat better than passwords alone. If you think about it in terms of how long an attacker has to act, I think you'll come to a different conclusion. Two-factor auth is better than password alone even when the end user is typing OTPs into a machine that is completely and totally rooted. The key phrase in your analysis is "connected token." Once the token is disconnected, the malware no longer has access to the authentication data. When a password is stolen it could be usable for months. When an OTP is stolen it is usable for hours, if that. Two-factor auth reduces the risk because it reduces the length of time of the compromise. Does the risk justify the costs involved (tokens, token management, authentication host, and trusted data paths)? That is the big question. Even if you are willing to pay for two-factor, transactional authentication might provide better value. Regards, Brian
Re: [Full-disclosure] Re: RSA SecurID SID800 Token vulnerable by design
On 9/9/06, 3APA3A <[EMAIL PROTECTED]> wrote: The only additional attack factor this issue creates is attacker can get _physical_ access to console with user's credentials _any time_ while user is logged in, while in case token can not be red (e.g. it's not plugged to USB) he can only access console short after user logs in to compromised host (while token is not changed). For web SSO in particular, accessing the token once is nearly as good as accessing it constantly. The token will be used for the initial authentication, but normally a cookie will be used for session tracking. An attacker who can sniff the token code can certainly steal the cookie as well. Two-factor auth cannot be said to make accessing the network from a compromised PC "safe". That does not make two-factor auth useless. With plain passwords, once the attacker has the password, they can access the network at will. With two-factor auth, they can access the network for a much more limited time span. Regards, Brian
Re: # MHG Security Team --- PHORUM 5.1.13 Remote File Inc.
This is a bogus report. Please mark it as such or remove it. This so called exploit is nothing but an attemtpt to defame the name of Phorum. 1. common.php is checked on the very first line of non-comment code that it is not being called directly. It has been this way in all 5.x version of Phorum. 2. The varialbe $PHORUM["http_path"] is only used for redirects and echoing in emails. It is never used to include or open files. 3. Versions of Phorum before 5.0 did not use the variable at all. THE MHG Security Team owes the Phorum Development Team a public apology.
Re[2]: The Weakness of Windows Impersonation Model
Just one important note regarding Database Security Brief: http://www.databasesecurity.com/dbsec/db-sec-tokens.pdf "Why should I never logon to a Windows database server if I've got admin privileges?" We describe a little different problem for MS SQL. MS SQL gets privileged context on its own from MSDTC. So it doesn't matter if administrator was logged into database or not. MS SQL service's default state after its start is sufficient. A suggested policy to refrain admin logons will not protect for MSSQL. Additionally, to exploit this usually you no need a "sleeper" that waits for privileged client to logon. Impersonating processes often keep their impersonation tokens for a while. In order to exploit an attacker needs just search for token handles. The list of handles can be retrieved through Windows native API. Brian L. Walche, http://www.gentlesecurity.com > Hi Brian, > I wrote a paper on this subject last year, "Snagging Security Tokens to > Elevate Privileges" > (http://www.databasesecurity.com/dbsec-briefs.htm) after > Tim Mullen and thrashed out a few details at Blackhat last year over a few > White Russians. The paper discusses the problem in the context of database > servers and examines the LogonUser() and AcceptSecurityContext() functions. > I believe Longhorn/Vista will address many of issues that currently affect > impersonation. > Cheers, > David Litchfield > http://www.databasesecurity.com/ > http://www.ngssoftware.com/ > - Original Message - > From: "Brian L. Walche" <[EMAIL PROTECTED]> > To: > Sent: Tuesday, May 16, 2006 7:25 PM > Subject: The Weakness of Windows Impersonation Model > The Weakness of Windows Impersonation Model > <http://www.gentlesecurity.com/04302006.html> > Summary > 1. Network Service account’s context is elevated to LocalSystem. > 2. A context of MS SQL service running as unique user account is > elevated up to LocalSystem. > 3. Any service’s context could be elevated to LocalSystem > There is an immanent risk to run network services as privileged > account, e.g. LocalSystem or Administrator. The threat is widely > accepted and recognized. However, most are not aware that nearly the > same risk is present for a service configured to run on behalf of > non-privileged account such as Network Service, Local Service or > unique user. > Technical Details > Security implications of impersonation are not new, but are not widely > recognized and understood. By definition, impersonation allows a > server application to replace (impersonate) its security context > (credentials) by context of client. In general, impersonation assumes > a server reduces its privileges but it also imposes a threat of > unauthorized privilege elevation. > The attack scenario is well known and understood. An attacker > terminates, pauses or crashes a privileged server application and > starts its own one with the same interface. It receives requests from > privileged client and impersonate. There were number of attacks > reported that have used this approach with named pipes [1, 2, 3]. > However, the scope is not limited to named pipes. Any communication > channel that supports impersonation can be hijacked for privilege > elevation purposes, including LPC, RPC, DDE, COM, etc. Named pipe > interfaces are merely less opaque and easier to discover and exploit. > Provided threat of impersonation led to creating of a separate > privilege – “Impersonate a client after authentication”. Therefore, > since Windows XP only LocalSystem, Administrators and services have > this privilege by default [4] and can impersonate to client’s > credentials. Regular users are not able to exploit impersonation > anymore, but services (special processes managed by Service Control > Manager) still can. The risk of services run as LocalSystem and > Administrators is recognized, however the threat of other accounts > used to run services is underestimated. Network Service, Local Service > and even unique user accounts used to run a service still allow > privilege elevation for intruder who successfully attacked a service. > There are two attack scenarios: > 1) If a service does not impersonate highly privileged clients then an > attacker who breaks into such service can simulate communication > interface used by privileged services. > 2) If a service happen to impersonate highly privileged clients then > attacker’s task is easier, he needs just catch up privileged client > context during impersonation. > Windows XP and Windows 2003 use Network Service account to run > critical services such as Remote Procedure Call (RPC), which > impersonate privileged clients. As result, the second attack scenario > is possible to ele
Re[2]: The Weakness of Windows Impersonation Model
thanks for reference David. As advisory notes impersonation implications are not something new. We would like to stress the fact of how easy it is to exploit by two notable samples. - An attacker can reliably elevate a context running on behalf of Network Service acccount. For example, by default, IIS 6.0 runs Worker Process as Network Service. So an attacker who able to upload an ASP script can gain administrative privileges. - MS SQL service context is elevated up to LocalSystem regardless account it runs. These are purely practical exploitations for Windows 2003 in default configuration without additional pre-requirements. We provide demo tools exploiting these elevations as a part of our products evaluation procedure. Additionally, we want to stress the obscurity of nearly all "official" manuals that declare Network Service as non-privileged account, a quote: “The new Network Service account … has a greatly reduced privilege level on the server itself and, therefore, does not have local administrator privileges.” In fact, provided easiness of Network Service elevation and some additional permissions, you may consider Network Service account as an equivalent of LocalSystem. Even if Vista would address certain issues, how long we have to wait for Windows 2003 successor - Vista Server.. Brian L. Walche, Know the Fact - http://www.gentlesecurity.com/knowthefacts.html GentleSecurity S.a.r.l. www.gentlesecurity.com > Hi Brian, > I wrote a paper on this subject last year, "Snagging Security Tokens to > Elevate Privileges" > (http://www.databasesecurity.com/dbsec-briefs.htm) after > Tim Mullen and thrashed out a few details at Blackhat last year over a few > White Russians. The paper discusses the problem in the context of database > servers and examines the LogonUser() and AcceptSecurityContext() functions. > I believe Longhorn/Vista will address many of issues that currently affect > impersonation. > Cheers, > David Litchfield > http://www.databasesecurity.com/ > http://www.ngssoftware.com/
Multiple SQL Injection Vulnerabilities in Dreamweaver Generated Code
Multiple SQL Injection Vulnerabilities in Dreamweaver Generated Code INFORMATION: - Class: SQL Injection CVE: CVE-2006-2042 Remote: Yes Local: Yes Published: May 09, 2006 Credit: Brian Gallagher <[EMAIL PROTECTED]> Vulnerable: Dreamweaver Ultradev Dreamweaver MX Dreamweaver MX 2004 Dreamweaver 8 (fixed in version 8.0.2) DISCUSSION - There are multiple SQL Injection vulnerabilities in the code generated by Adobe's Macromedia Dreamweaver prior to versino 8.0.2. This vulnerability affects the ColdFusion, PHP mySQL, ASP, ASP.NET and JSP server models. If the database server is configured to allow local system commands to be executed via database calls, this vulnerability may also allow local code execution. Dreamweaver offers powerful rapid-application design (RAD) tools for quickly and easily creating Internet and Intranet applications for a variety of server models (databases and languages). The code generated automatically by these functions does not properly validate input and are vulnerable to SQL Injection attacks from remote users. Macromedia (now Adobe) was notified of the problem in October 2005. They have been working cooperatively to remedy this problem, including examining and updating all their server models. If all vendors were this cooperative and responsive, the digital world would be a safer and better place. Adobe today released the updated version of Dreamweaver 8.0.2 (free download) along with instructions on how to workaround the problem in code developed in earlier versions of Dreamweaver. The Adobe announcement can be found here: http://www.adobe.com/support/security/bulletins/apsb06-07.html EXPLOIT - This vulnerability can be exploited by standard SQL injection techniques. The documentation supplied by Adobe in their release details where the vulnerabilities exist and how to correct them. If a web server's database allows access to the system commands through SQL queries local command execution is possible. SOLUTION - Dreamweaver 8: Install the free updater to version 8.0.2 and recreate your server components to use the new more secure code. Dreamweaver MX 2004: Follow the directions for your server model on how to secure your existing code. Dreamweaver MX, Ultradev: Read the directions for the MX 2004 fixes and adapt these to your code. REFERENCES - Macromedia Security Bulletin: Dreamweaver Server Behavior SQL Injection vulnerability http://www.adobe.com/support/security/bulletins/apsb06-07.html Dreamweaver Support Center: Updaters http://www.adobe.com/support/dreamweaver/downloads_updaters.html Protecting ColdFusion server behaviors from SQL injection vulnerability http://www.adobe.com/cfusion/knowledgebase/index.cfm?id=300b670e Protecting PHP server behaviors from SQL injection vulnerability http://www.adobe.com/cfusion/knowledgebase/index.cfm?id=30037473 Protecting ASP VBScript server behaviors from SQL injection vulnerability http://www.adobe.com/cfusion/knowledgebase/index.cfm?id=57ae79b2 Protecting ASP JavaScript server behaviors from SQL injection vulnerability http://www.adobe.com/cfusion/knowledgebase/index.cfm?id=581a553c Protecting JSP server behaviors from SQL injection vulnerability http://www.adobe.com/cfusion/knowledgebase/index.cfm?id=585ac720 -- Brian Gallagher - DiamondSea.com - [EMAIL PROTECTED] We Make E-Commerce Easy - No Technical Experience Required Consulting - E-Commerce - Web Site Design - Custom Programming http://www.DiamondSea.com - Toll-Free: 800-604-1476 - Fax: 888-411-8144
Bugs/Security issues with PatchLink's Update Server
lanatory bug. 62> Opened 2005/11/29 - Closed /xx/xx - #001-00-007073 - Typo: Extra space in MS05-031 text string Note: The text for all patches but this one are exactly the same if you viewed from a web page OR from the Export of a mandatory baseline. I use the Exports to show configuration changes. But when I use an exported spreadsheet & I copy a cell with a patch name and the paste it into the find window box of Internet Explorer when I am in the section to add or remove patches from a baseline... the pasted text does not match the name in the list. This is not an Internet Explorer issue because the extra space is in the middle of the text. PatchLink Support is refusing to add a (Rev 2) to this patch like they have done with other patches. 63> Opened 2005/11/29 - Closed /xx/xx - #001-00-007074 - Issue with MPSB05-07 Flash Player 7 patch & Update Servers' deployment Note: This is a really big issue I have with PatchLink as a company. When this patch came out (http://www.macromedia.com/devnet/security/security_zone/mpsb05-07.html) PatchLink as a company decided to not offer the patch that fixed this situation. Macromedia offers this patch as well (http://www.macromedia.com/cfusion/knowledgebase/index.cfm?id=d9c2fe33). Instead PatchLink packaged Macromedia's Flash Player 8 as the patch that fixed Flash Player 7. They did note this in their Description. But if you install their patch, vulnerable files still exist on the client that was "patched". It is impossible to patch the vulnerable Flash Player 7 files using Update Server. I have issues because they made a decision to patch a product with a new version of the application. I have issues with PatchLink because this issue was raised to them and they have done nothing about this. I have issues with their naming scheme because the patch name suggests that it will patch Flash Player 7 when it doesn't do this at all. Note: In prior upgrades of Flash Play the old version was removed. When Flash Player 8 came out, this no longer happened. 64> Opened 2005/12/16 - Closed /xx/xx - #001-00-007528 - Trying to figure out why SQL Server patches are reported as missing Note: From PatchLink: This is a known issue. A missing registry key produces a false negative. Well there you have it. I hope that these qualify as bugs & security vulnerabilities that can benefit bugtraq. So as I asked before, could you let me know what is going to happen to this information now that you have it? Could you give me a URL that shows me where this information went to? Regards, Brian Boner Sr. Systems Administrator TBG Financial
Re: Another Mac OS X ScreenSaver Security Issue (after Security Update 2003-07-14)
Gavin Hanover wrote: I don't quite agree. Windows uses control-alt-delete as a security device. It binds those keys as a hotkey in such a way that no other aplication can replace it. This is why it is used at logon; it prevents a user from creating a program that looked like a logon prompt, and could bind the control-alt-delete keys to display a password prompt. (pressing control-alt-delete in any application other than the logon screen would display the "shutdown/logoff/task manager" window, at which point you would know not to enter your password in any prompt) If someone were to find a way to bind to those hotkeys, would you then consider this a security issue with Windows? If so, how is Apple's failure to block kill calls to the screen saver not a security issue? Gavin Windows does allow others to bind to those hotkeys. The Novell client is a good example. The Novell NDS password can be used to unlock the screen saver, without requiring the Windows password to be entered. Obviously other programs could bypass the Windows authentication as well. Brian -- Brian Eckman Security Analyst OIT Security and Assurance University of Minnesota 612-626-7737 "There are 10 types of people in this world. Those who understand binary and those who don't."
Re: ssh host key generation in Red Hat Linux
> SSH is likely getting it's entropy from /dev/random. The kernel will > decide whether there is enough entropy in the /dev/random entropy pool, > and block reads until the pool fills. > > This pool, in turn, is going to have pleanty of entropy generated by > timing jitter in disk I/O interrupts. > > To experiment with this, run the command: > > cat /dev/random | od -cx You can also see how much 'pure entropy' is available without depeleting it by checking /proc: $ cat /proc/sys/kernel/random/entropy_avail 215 > Disclaimer: there is dispute in the crypto community about the hashing > done in /dev/urandom (note the 'u') which never blocks. /dev/urandom > just recycles the entropy pool with a PRNG, and people have variable > faith in the quality of PRNG's. Incidentally, many Linux distros will dump a chunk from /dev/urandom on reboot and write that chunk back on bootup, s.t. even /dev/urandom has something available from the get-go, based on the previous state. (The previous state hopefully had user interaction, etc.) Now this depends on us trusting the previous PRNG too, I'm not commenting on that.) The server on which I'm writing this has no keyboard for random input. In the time it took me to write this email (via SSH), it's gathered about 500 bytes of entropy, as seen through the aforemeantioned /proc entry. I just modified the bootup init.d scripts on a UML kernel I have. The very first thing rc does is cat entropy_avail to the screen, before any of the S?? scripts are run. It reported 23 bytes available, so even the execution of init => rc is sufficient to get some randomness in there. Not the best in the world, but it's a start. Even without user interaction, you're likely to get some entropy from the kernel. -- Brian Hatch "I see. So, you feel like Systems andyou've been symbolically Security Engineer cast... in a bad light." http://www.ifokr.org/bri/"Well put." Every message PGP signed pgp0.pgp Description: PGP signature
RE: Authentication Vulnerability in NetScreen ScreenOS
However, after a user is authenticated, anyone else may also access the protected services if they orginate from the same source IP address (NAT'd network). The authentication mechanism is designed to authenticate based on source-ip address only. Most firewalls track authenticated users based on the client's source IP address. If you need a stronger method, you could always use the Netscreen Remote client software and require a secure tunnel from the clients to get to your protected resources. -Brian Soby _ The new MSN 8: advanced junk mail protection and 2 months FREE* http://join.msn.com/?page=features/junkmail
Re: Phorum 3.4 Cross Site Scripting
In-Reply-To: <[EMAIL PROTECTED]>
FYI, the versions prior to 3.4 did not have this problem.
Brian.
Phorum Dev Team
>From: Peter "Stöckli" <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED]
>Subject: Phorum 3.4 Cross Site Scripting
>
>
>
>Description:
>It is possible to insert javascript code in a message
and execute it.
>
>1.) go to a phorum
>2.) click on new topic
>3.) enter any name
>4.) enter any email
>5.) enter a title in the way like this
"><script>alert
>("Vulnerable");</script>
>6.) enter any text
>7.) click the preview button
>8.) click the send button on the top of the page
>
>Solution:
>Edit the source code to strip malicious characters
from title or escape
>malicious characters using addslashes().
>
Stunnel: RSA timing attacks / key discovery
Release Date: 2003-Mar-21 Package: stunnel Versions: Stunnel 3.xx <= 22 Stunnel 4.xx <= 04 Problem type: Key discovery / Information Leakage Exploit script:None publicly available Severity: High Network-accessible:yes Network-accessible:yes Discovery: D. Boneh, D. Brumley Writeup: Brian Hatch <[EMAIL PROTECTED]> Summary: SSL sessions where RSA blinding is not in effect are vulnerable to timing attacks which could allow a cracker to discover your private RSA key. Description: Stunnel is an SSL wrapper able to act as an SSL client or server, enabling non-SSL aware applications and servers to utilize SSL encryption. Dan Boneh and David Brumley have successfully implemented an RSA timing attack against OpenSSL-enabled SSL software, including Stunnel. Their writeup is available at http://crypto.stanford.edu/~dabo/abstracts/ssl-timing.html Impact: If you use an RSA key for an SSL server, a determined cracker could eventually determine your key. This could be used to impersonate your server via a man-in-the-middle attack, or to decrypt all SSL connections between client and server that can be sniffed/etc from the cracker's location. Mitigating factors: The timing attack works best under situations where there is little or no network lag, such as over a localhost connection. If the attacking host is more distant that network packets have a larger range of turnaround times may make the attack less successful. However a very slow CPU on the Stunnel server (which would process the RSA number crunching more slowly) may counteract the network lag. The number of connections an attacking host must make to discover the key is rather large, enough that you may well notice the increase in your CPU usage, number of available sockets, or volume of log messages spewing through your system. Solution: * Recompile OpenSSL using the patch[1] they have supplied and then recompile Stunnel. or * Apply the patch for Stunnel 3.x available at http://www.stunnel.org/patches/desc/blinding-3.x_bri.html or the patch for Stunnel 4.x available at http://www.stunnel.org/patches/desc/blinding-4.x_bri.html and recompile Stunnel. I expect Stunnel 4.05 and 3.23 will be released which incorporate these or similar patches. For more information about Stunnel, consult the folowing pages: http://stunnel.mirt.net/# Official Stunnel home page http://www.stunnel.org/ # Stunnel.org: FAQ/Distribution/Patches/Etc Discovery: The code to successfully perform an RSA timing attack against Stunnel was created by David Brumley and Dan Boneh. Here is the original email they sent to the Stunnel mailing list on 13-Mar-2003. To: [EMAIL PROTECTED] Date: 13 Mar 2003 16:09:17 -0800 From: David Brumley <[EMAIL PROTECTED]> Subject: Timing attack against stunnel/OpenSSL Dan Boneh and I have been researching timing attacks against software crypto libraries. Timing attacks are usually used to attack weak computing devices such as smartcards. We've successfully developed and mounted timing attacks against software crypto libraries running on general purpose PC's. We found that we can recover an RSA secret from OpenSSL using anywhere from only 300,000 to 1.4 million queries. We demonstrated our attack was pratical by successfully launching an attack against Apache + mod_SSL and stunnel on the local network. Our results show that timing attacks are practical against widely-deploy servers running on the network. While OpenSSL definitely does provide for blinding, mod_SSL doesn't appear to use it. One reason is it appears difficult to enable blinding from the SSL API. This paper was submitted to Usenix security 03. The link to the paper is here: http://crypto.stanford.edu/~dabo/abstracts/ssl-timing.html We notified CERT about a month ago re: this attack, so it's possible you heard about this from them already. flames > /dev/null. Feel free to write with any questions. Cheers, -David Brumley ---- -- Brian Hatch Quantum Mechanics: Systems andThe dreams stuff Security Engineer is made of. www.hackinglinuxexposed.com Every message PGP signed pgp0.pgp Description: PGP signature
Re: Preventing exploitation with rebasing
> With all the respect... I think your ideea is a BAD one ! Why ? Well... > It might be verry efective if one to... mhm... 100 persons would aply > this technique. That's because hackers/worms wouldn't mind loosing a few > servers if they got the rest of the world. But if this technique would > became a standard then the worm-industry (if there is such a thing) > would also evolve... making it brute-force the addreses. I admit that > brute-forcing would slow down the worm/hacker/whatever... but this is no > way of looking at the security. This is like protecting a house/store by > putting 15 doors that all could be easily broken... Of course there is a > chance that a thief trying to break in would get bored breaking door > after door... but if he's really determined... Well... I guess I made my > point. I fail to see how adding security that doesn't have a performance or stability cost is ever a bad thing. No one is suggesting that the security community *rely* on this technique for security. It is an additional layer - the classic 'denfense in depth' that we are constantly touting. People keep saying "but it won't stop everything", and that's true. But since when have we turned down a security procedure that is not a silver bullet against all evils? I'd love to make it harder for worms to attack my systems. I'd love for them to take longer to break into the machines down the hall. That means things will spread slower, and we can stop the damage quicker. Why is this bad? > Rebasing might be usefull up to some point. But it contains a "mental" > vulnerability. If one would apply this technique he would probably think > he is safe and neglect updating his security. David has not suggested that this is a solution. And any administrator who has such a "mental" vulnerability probably has several other non-rebasing related vulnerabilities on their servers anyway. They probably think that a firewall stops all attacks, so wouldn't bother rebasing in the first place. This is not a satisfying argument against rebasing. If rebasing causes a problem with performance, stability or the ability to apply security-related patechs, that's a good argument against it for that envoronment. It may even be application-specific, and I have no knowledge of how well you can perform it on Windows boxen. But I don't see any reason that you shouldn't if it can be done right. More layers of security are good... additional layers of security are good... additional layers of security are good... -- Brian Hatch Microbiology Lab: Systems andStaph Only! Security Engineer www.hackinglinuxexposed.com Every message PGP signed msg10663/pgp0.pgp Description: PGP signature
Re: Putting the "NSA Data Overwrite Standard" Legend to Death...
> Near as I can tell if someone says they are doing NSA overwrites, they are > full of shit. In addition, based upon Mr. Gutmann's paper and the fact > that it is quite old, one can assume that with advanced forensics the > simple 3, 7, or 9 time overwrites that these products are claiming as > secure actually are not even close to the level of security they claim. In > fact, by following this "glossy brochure" de facto standard, data is not > secured from recovery by an advanced recovery effort at all. And worse yet, your data may well live in other places aside from the official blocks on the disk. If you're using a journaling file system, your data was probably written to the journal before going to the final blocks. If the data was read by a process that swapped, your swap partition may contain a copy of the data. If the filesystem layer decided to move your data around on the physical disk for some reason then the original location will not be overwritten by our standand 'write junk x times' method. To my knowledge there is no 100% guarenteed method to delete your bits irrevocably from the hardware without writing over the entire disk[1], not just the parts officially allocated to the file at any given time. [1] multiple times with different data each time, as meantioned before. -- Brian Hatch "Cannot say. Saying I Systems andwould know. Do not know, Security Engineer so can not say." www.hackinglinuxexposed.com Every message PGP signed msg10637/pgp0.pgp Description: PGP signature
RE: MS SQL WORM IS DESTROYING INTERNET BLOCK PORT 1434!
The fact that the nations largest banking institution relies on the Internet for ATM transactions is disturbing. I personally experienced this while at a Bank of America ATM today. I will never use Bank of America because of a statement like that. -brian On Sat, 25 Jan 2003, Richard M. Smith wrote: > However, this worm might not be so harmless as it appears because of > collateral damage: > >Bank of America ATMs Disrupted by Virus > > http://story.news.yahoo.com/news?tmpl=story&ncid=578&e=3&cid=569&u=/nm/2 > 0030125/tc_nm/tech_virus_dc > >"SEATTLE (Reuters) - Bank of America Corp. said on >Saturday that customers at a majority of its 13,000 >automatic teller machines were unable to process >customer transactions after a malicious computer worm >nearly froze Internet traffic worldwide." > > Richard M. Smith > http://www.ComputerBytesMan.com > > -Original Message- > From: Jason Coombs [mailto:[EMAIL PROTECTED]] > Sent: Saturday, January 25, 2003 4:41 PM > To: Jay D. Dyson; Bugtraq > Subject: RE: MS SQL WORM IS DESTROYING INTERNET BLOCK PORT 1434! > > > Jay Dyson wrote: > > And to think...up until tonight, I thought the vulnerabilities > > that paved the way for Nimda were the worst that Microsoft could do > > to the net.community. They've really topped themselves this time. > > As of now we don't know who wrote the worm, but we do know that it looks > like a concept worm with no malicious payload. There is a good argument > to > be made in favor of such worms. Whomever did write this worm could have > done > severe damage beyond unfocused DDoS and chose not to do so. One would > expect > intelligence agencies in developed countries to write and release > precisely > this type of concept worm as a form of mass inoculation against > malicious > attacks. > > Before you get upset at your vendor, or anyone else's, consider the > bigger > picture and recognize the increased security hardening the Internet just > received. Belief in this silver lining shouldn't be taken too far, of > course, but flaming anyone over an event like this is misplaced > considering > the number of infosec experts who would probably have agreed to write > this > worm if approached by their nations' government with proof that an > adversary > was planning to cause severe harm by exploiting the W32/SQLSlammer > vulnerability. > > Sincerely, > > Jason Coombs > [EMAIL PROTECTED] > >
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.
RE: Bypassing website filter in SonicWall
That weakness would exist in any product that filters by domain name, because many of them will not perform a reverse DNS lookup. This would be the behavior of most home products (such as Cyberpatrol) which allow an administrator to specify forbidden domains, but if I wanted to see the site bad enough I would just ping/tracert/etc to get the IP address. In most cases the filter will not capture the IP address because all the admin knew to enter was the domain name. SonicWall could (and should) resolve this by adding Reverse DNS lookup to the Forbidden Domains list. That would possibly slow down Internet traffic on the LAN side but the admin could disable it if they wish. Also if the reverse DNS fails it could give the admin the option to block the site or allow it anyway. Brian J. Gaia Print Shop & Information Systems Assistant Webmaster, Pure and Undefiled Religion (PURE) Church of the Open Door -Original Message- From: Marc Ruef [mailto:marc.ruef@;computec.ch] Sent: Tuesday, October 29, 2002 2:36 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Bypassing website filter in SonicWall Hi! I found a little weakness in SonicWall: I turn on the blocking mechanism for websites (e.g. www.google.com). Now I can't reach the website using the domainname. But if I choose the IP address of the host (e.g. http://216.239.53.101/), I can contact the forbidden website. The same issue I've discovered for NetGear FM114P in http://online.securityfocus.com/bid/5667 It would make sense if you can do an internal nslookup. Otherwise the user can do a workaround and adding always the ip address(es) of the blocked websites. But this can cause some problems if there were some virtual hostings. A smart attacker can use some dottless-ips to bypass the new workaround IP filter. The box will sadly loose performance because of the additional filter line(s). My description was sent on 02/10/15 to [EMAIL PROTECTED] - No response came back. The blocking URL message style and problem reminds my the website blocking mechanism by NetGears FM114P. It could be that both use the same mechanism (by a 3rd party?). So, if the bug is fixed for one box the other will also be fixed - I think so. Bye, Marc -- Computer, Technik und Security http://www.computec.ch
Ingenium Admin Password Vulnerability
The vendor was contacted, but I have not received any response (other than an autoresponder) over the past week... -E Security Advisory -- Click2Learn's Ingenium LMS Brian Enigma <[EMAIL PROTECTED]> http://netninja.com/papers/ingenium/ --- OVERVIEW --- Product: Ingenium Learning Management System Versions: Known to work on v5.1 and v6.1. It is likely that all versions are vulnerable. Click2Learn's Aspen LMS has not been tested. Vulnerabilities: (1) Administrator password, public visibility (2) All user passwords visible with database SELECT access Affected Systems: All Ingenium installations visible to the public internet (do a Google search for "Ingenium Web Connect") Reporter: Brian Enigma <[EMAIL PROTECTED]> Vendor Contacted: 2002-10-07, no response Publication Date: 2002-10-14 Company: Click2Learn Company URL: http://home.click2learn.com/ --- BACKGROUND --- I work for a company that uses Click2Learn's Ingenium Learning Management System. Part of my job involves locating, evaluating, and fixing security vulnerabilities in an assortment of products. A few things about Ingenium have recently caught my interest. First, a user on the public internet can retrieve the administrator's password hash. Second, the password hash is easily reversible. Third, user passwords (not as easily accessible, as they are stored in a Microsoft SQL database) are also hashed using the same reversible algorithm. --- SEVERITY --- This is a very serious problem. Any site using Ingenium as their learning management system is vulnerable. Since the HTML title used by the frameset in all Ingenium installations is "Ingenium Web Connect," a Google search will reveal quite a number of vulnerable sites. In theory, a user can log into any of these sites as an administrator using these vulnerabilities. --- ADMINISTRATOR PASSWORD HASH VISIBILITY --- Ingenium stores a number of configuration parameters in a Microsoft SQL database. It also must store a few values on the local system, as it needs to know several important values before being able to access the database--for instance, the location, login, and password for connecting to the database. Basically this is the database "bootstrap" information. In examining the file more closely (it is called [install directory]/config/config.txt), I also noted that the application's administrator password, as a hashed value, is also stored in this file. Even further inspection of the file location, directory structure, and IIS installation shows that the file is located in a folder under the htdocs web directory! This means that a simple HTTP request can grab the config file! In most default installations, replacing the "default.asp" file name in the URL, when looking at the Ingenium home page, with "config/config.txt" will retrieve the file, including the administrator password hash. This is just plain silly! Most web programmers with any amount of training or experience know that you need to store your data out-of-band from the documents/programs. Raw data files should not be web accessible. While this particular vulnerability is a known issue (see Click2Learn's Knowledge Base article Q1254), it is brushed off as advice for the paranoid. Personal observation has not shown a single site that hides this configuration file. Utilizing this vulnerability leads us to the importance of the next one. --- ADMINISTRATOR PASSWORD HASH DECRYPTION --- You may or my not already know that the best way to store passwords in a persistent data store is with a one-way hash function. In fact, this is how all Unix systems work. You cannot reverse out a password from a password hash without a lot of brute force--in most cases, so much number crunching that the process is not worth it. You may also know that one of the worst ways to store passwords (or any data) is with XOR "encryption." Two large enough samples and a minute of math will give you a pretty darn good idea of what the "encryption" key is. An even less secure method of encrypting data is with a secret decoder ring. In fact, most newspapers have a "Cryptogram" section with the Sunday comics that lets you solve these as a diversion (shameless self-plug: http://sourceforge.net/projects/cryptoslam/). It is called a Caesar cypher and is made mildly more challenging/annoying by varying the offset depending on the position of the letter in the message. I'll give you three guesses what Ingenium uses to store passwords, but the first two guesses cannot be &
Re: Postnuke XSS issues [correction]
In-Reply-To: <[EMAIL PROTECTED]> >As it turns out the Postnuke issue in particular is a red herring. > >As the lead developer describes it -- the cookie generated is a local >site cookie that is sandboxed within the confines of the >browser/session. > >It is not the remote user's cookie. The correction posted here on BugTraq is false. The vulnerability exists with PostNuke .72. I expect this exists for previous versions as well but have not tested. I have used the sample exploit URL against my own PN .72 system. 1. Close all instances of IE. 2. Use the url against my site. The session ID is displayed in the popup (the script is embeded in the the HTML source). 3. View my site database in MySQL. NUKE_SESSION_INFO table contains an active session ID (pn_sessid field). No user is associated with this session ID (i.e. pn_uid=0). 4. Logon to my site. Provide a userid and password. 5. View my site database in MySQL. NUKE_SESSION_INFO table contains an active session ID (as displayed in #3). The userid I used to logon to my site (from #4) is now associated with this session ID. 5. Use the url against my site. The session ID is displayed in the popup (the script is embeded in the HTML source). This is the same session ID displayed in #1 and represents the authentication token for the user (user account used in #4). An attacker who successfully obtains this information could hijack the valid session and assume the identity and privileges of the user from #4. This process has been simplified and does not reflect multiple instances of IE (which could have unique or shared session ID's). Yes, PN may use a sandbox environment if the user has not logged into the site yet. However, if the user logs on before or after this vulnerability is exploited it becomes more serious. 1. If an attacker obtains (and explots) a valid session ID of a regular user, the damage caused to the site would would likely be minimal. However, the user may experiance embarassment or some loss of reputation as someone could have impersonated them and posted comments as the user. 2. If an attacker obtains (and exploits) a valids session ID of a postnuke moderator or other privileged user (i.e. postnuke admin), the damage caused to the site would be greater than #1. This user may be able to alter the configuration of the postnuke application or affect data that appears on the site to other users. This would not allow direct access to the MySQL database or file system. Damage to user is same as #1. A postnuke admin can protect the site by timing out session ID's when no longer in use. A user can protect themself by logging out of the application, don't just close the browser. I would also argue that if a user's actions are not monitored, they will go undetected. Will a driver run through a red light if they are stopped on a deserted road with no one around? What about if that driver see's they are being watched by a camera? Yes, the web server may be logging requests but these records do not easily or directly show what action a particular user performed. In my opinion, individual user accountability in PostNuke is not achieved. Knowing that actions may go undetected, a user may be further tempted to try exploiting vulnerabilities. Regards, Brian, CISSP
IE bug not fixed - update
Microsoft Baseline security analyser shows a red cross against "MS02-008, XMLHTTP Control Can Allow Access to Local Files" on both my systems, and this is backed up by the exploit http://jscript.dk/Jumper/xploit/xmlhttp.asp is working on both my systems despite reapplying the required patch many times in the past and then installing the latest IE patch that should also of fixed it. > The bug shown on the following pages is not fixed > > http://online.security.com/bid/3699 > > I have 2 computers running Win XP Pro & IE6, both systems have all = > updates installed via the Windows Update including Q323759: August, 2002 = > Cumulative Patch for Internet Explorer 6 (Windows XP), installed on 23 = > Aug 02. > > Yet the page http://jscript.dk/Jumper/xploit/xmlhttp.asp still allows = > local file reading on both computers, which was ment to be patched in = > MS02-008. > > If you need any details, computer config, dll versions etc just drop me = > a mail and I will get you detailed compuer hardware and software info. > Can you confirm the existance of this bug on your test systems. > > Thanks > Brian
RE: Apache Artificially Long Slash Path Directory Listing Vulnerability -- FILE READ ACCESS
As we don't have access to all versions of Apache on all platforms, I can't say for certain that this will work on all of them. The version that we have successfully tested on with 100% consistency is Apache 1.3.12 on NT4. Please let me know if you duplicate this success on any other platforms. Brian -Original Message- From: Moorjani uday [mailto:[EMAIL PROTECTED]] Sent: Friday, July 27, 2001 1:47 PM To: Brian Dinello Cc: [EMAIL PROTECTED] Subject: Re: Apache Artificially Long Slash Path Directory Listing Vulnerability -- FILE READ ACCESS Hi sir, I seem to have tested your statings on Apache AdvanceExtranetServer 1.3.12 on Mandrake Corporate Server 1.01 and the following still seems to give me my default Apache page, please do correct me if I'm wrong though. Uday Moorjani
Apache Artificially Long Slash Path Directory Listing Vulnerability -- FILE READ ACCESS
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Apache Artificially Long Slash Path Directory Listing Vulnerability BUGTRAQ ID 2503 I'm not really sure if this is a known issue, but here goes: Old news: As the vulnerability's description describes, any user with a web browser can obtain directory listing of the Apache http root directory, even if the directory contains an index.html file and is password protected. New news: You can access files/directories under the http root by subtracting the number of slashes from the appended url equal to the number of characters in the file or directory name you are attempting to access. Example: Standard Directory List: http://15.16.17.18 Download an Arbitrary file: http://15.16.17.18 thisfile.txt Or In a Directory: http://15.16.17.18subd ir1/thisfile.txt I've made no attempt to contact The Apache Group to discuss this as it is the result of a known vulnerability and patches have already been released to fix vulnerable systems. Brian Dinello Security Consultant VigilantMinds, Inc. [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com> iQA/AwUBO2A9ma1dkgK5UcWTEQIa4wCfXK2NheBMvCb67CSOXBGpGoXEkfsAoNOC ZjyC05S8XddgUvLifLIIvx2o =Fz1o -END PGP SIGNATURE-
Re: URGENT SECURITY ADVISORY FOR SSH SECURE SHELL 3.0.0
OpenSSH is not vulnerable at all weather or not you use PAM.. this is SSH the commercial Version. If you didn't pay for it then you are OK!! -- Brian Carpio CSG Systems Inc. Open Systems Unix System Admin x3317 -- --- Security is a Process NOT a Product On Sat, 21 Jul 2001, Marcin Zurakowski wrote: > On Fri, 20 Jul 2001, Stephanie Thomas wrote: > > > an empty password. This affects SSH Secure Shell 3.0.0 > > I guess openssh with pam support is not vulnerable?? > > -- > > Marcin Zurakowski > > InterFirma Administrator > > >
RE: OpenBSD 2.9,2.8 local root compromise
Was this tested on OpenBSD 2.8 release or stable? I have tested your exploit on my OpenBSD 2.8 stable box and was unable to get a root shell. I tried it a few times with core dumps and then it did work a couple times but there was no link in /tmp. I went ahead and rebooted my box, never executed /usr/bin/su and your code executed fine with no core dumps but still had the same results with no link in /tmp. Im no C coder but im sure this has something to do with the amount of fork()'s in $num or the value of $joro. my box is a P233 MMX with 64 megs of memory. Brian - snip -- Georgi Guninski security advisory #47, 2001 OpenBSD 2.9,2.8 local root compromise Systems affected: OpenBSD 2.9,2.8
Re: [PkC] Advisory #005: Default Slackware 7.1 installation /etc/shells perms bug
> - Vulnerable program: Linux Slackware 7.1 default installation > - Problems: /etc/shells installed with world-writable perms. This was reported as early as 2000-09-22. http://archives.neohapsis.com/archives/vuln-dev/2000-q3/0932.html
Re: IIS Decode
Yep, it works on IIS 3.0. At least the server I tested. I was verifing the vulnerability for a friend at a remote site, so I don't know what patch level of the system. bs - Original Message - From: "Michael Vassiliadis" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, May 16, 2001 11:52 PM Subject: IIS Decode > There has been so much talk about this new "diamond" from m$, but NOONE > discovered that this also works on IIS 3!!!. > > Please confirm... >
Re: def-2001-16: Internet & Acceleration Server Event DoS
I don't see this as being a true security risk. As you mention in your advisory, this only occurs if the installer has notification set for event logs and event logs are left to the default write method. I honestly think that the only people at risk here are incompitent administrators who do not porperly configure their network. That being the case, this puts the risk into the ID10T catagory. I put this on the par with administrators who allow their smtp servers to relay for anyone and who set their firewalls to allow netbios traffic through. Just my 2 cents... Brian P. McClory MCT, CCI, MCSE, MCP+I, CCA, ETC... "I'm not an actor, I just play one on TV."
Re: .. ptrace improvement
I keep trying all these exploits posted on the list on my webserver with no success, they all say "bug exploited successfully" but don't give root, am I doing something wrong? Brian Parris [EMAIL PROTECTED] - Original Message - From: "Tim Yardley" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Saturday, March 31, 2001 9:12 PM Subject: .. ptrace improvement > As always, there are always ways to improve things. This version of the > exploit posted here previously overwrites the dl _start routine and doesnt > modify eip. This will help on stack non-exec systems and doesnt require > you to calculate the bss offset. I didn't test it, but this should still > work on a stackguard compiled program as well. > > your mileage may vary, and this will still suffer from the disk cache issue > (speed becoming a paramount concern). the recent post by "Ihq" where his > exploit created a big file, is one way to fill out the cache so that the > suid binary is not in the cache. manual methods are just as easy. > > rsh, gpasswd, passwd, etc etc are all common choices for hitting. anything > will work. > > more details lay within the code. enjoy. > > /tmy > > -- Diving into infinity my consciousness expands in inverse > proportion to my distance from singularity > > + --- -- - --- -- --- -- --- - > --+ > | Tim Yardley ([EMAIL PROTECTED]) > | http://www.students.uiuc.edu/~yardley/ > + --- -- - --- -- --- -- --- - > --+ >
Re: Glibc Local Root Exploit
In bash, simplest way to discourage idiots who are going to do this is to put the following in /etc/bashrc or /etc/profile (if you use Bash, I dont know about tcsh or the others): readonly RESOLV_HOST_CONF="" Its not fool-proof, and wont last long, and definately wont stop those intent on doing damage, but hopefully this problem will get fixed quickly... Brian Bruns Valley Of The Mage Consulting http://www.magenet.com ICQ: 8077511 Charles Stevenson wrote: > > Hi all, > This has been bouncing around on vuln-dev and the debian-devel lists. It > effects glibc >= 2.1.9x and it would seem many if not all OSes using these > versions of glibc. Ben Collins writes, "This wasn't supposed to happen, and > the actual fix was a missing comma in the list of secure env vars that were > supposed to be cleared when a program starts up suid/sgid (including > RESOLV_HOST_CONF)." The exploit varies from system to system but in our > devel version of Yellow Dog Linux I was able to print the /etc/shadow file > as a normal user in the following manner: > > export RESOLV_HOST_CONF=/etc/shadow > ssh whatever.host.com > > Other programs have the same effect depending on the defaults for the > system. I have tested this on Red Hat 7.0, Yellow Dog Linux 2.0 > (prerelease), and Debian Woody. Others have reported similar results on > slackware and even "home brew[ed]" GNU/Linux. > > Best Regards, > Charles Stevenson > Software Engineer > > -- > Terra Soft Solutions, Inc > http://www.terrasoftsolutions.com/ > > Yellow Dog Linux > http://www.yellowdoglinux.com/ > > Black Lab Linux > http://www.blacklablinux.com S/MIME Cryptographic Signature
Re: [ Hackerslab bug_paper ] Linux printtool get printer passwor
On 08-Mar-2000 Sheshep ankh Dubhe wrote:
> [ Hackerslab bug_paper ] Linux printtool get printer password
>
> File : /usr/bin/printtool
>
> SYSTEM : Linux
>
> INFO :
>
> If make printer configuration by printtool package, It make vule config file.
> Config file perrmission is "-rw-r--r-- root root".
> If use samba network printer, password stored in config file.
>
> Tested platform : RedHat 6.1 - 6.2B
> printtool-3.41-2
> printtool-3.42-3ac
> printtool-3.43-1
I fixed my /usr/bin/printtool (v. 3.41) with:
2302a2303,2307
> #
> # set the .config permissions to something sane
> #
> catch {exec chown root.lp $smb_config}
> catch {exec chmod 600 $smb_config}
2465a2471,2475
> #
> # set the .config permissions to something sane
> #
> catch {exec chown root.lp $ncp_config}
> catch {exec chmod 600 $ncp_config}
Seems to work.
--
Brian Knotts [EMAIL PROTECTED]
Re: SSH & xauth
Ok, just to make sure everyone completely understands my previous post about SSH & xauth. The whole issue is that by default the *SSH CLIENT* automagicly requests xforwarding from the server if the client was run during an x session. The *entire* reason for the above post was NOT to alert people of a new hole, just to make SSH users aware that by default the SSH Client is set up to allow a trojanized server control of their x session. This is more significant than trojanizing the SSH server. There is a large amount of control given when X forwarding is on, far beyond the control of just what goes on in that ssh terminal session. For absolute security, a client should always give out trust in the smallest portions available. Trusting X tunneling by default is not a good idea, and should be turned off. As stated in previous postings, if you must use X, use Xnest. If this was unclear in my previous post to bugtraq, then I am sorry. -- Brian Caswell <[EMAIL PROTECTED]> I can levitate birds. Nobody cares. --- Steven Wright
SSH & xauth
The default SSH configuration for SSH1 and SSH2 allow for remote controlling of X sessions through X forwarding. All children of the SSH connection are able to tunnel X11 sessions through the X tunnel to the client X11 session. This is accomplished by running xauth upon logging in. If xauth is replaced on the server by a malicious program that does both of the following: - runs xauth, adding in the "correct" information allowing the children of the session to tunnel X11 programs through the SSH session - runs xauth, adding in the "malicious" information, allowing a malicious source to tunnel X11 programs through the SSH session. With the added data in .Xauthority, a malicious source can fully control the client X session. The malicious source can then do most anything to the X session, from logging keystrokes of the X session, to taking screen captures, to typing in commands to open terminals. The only thing that is required for the client system to be compromised is for the client to remotely log via ssh (with X11 forwarding enabled) into a compromised server. Allowing X forwarding seems to be turned on by default in SSH1, SSH2, and OpenSSH. To fix this "issue" add the following lines to the SSH client configuration. ($HOME/.ssh/config or ssh_config) Host * ForwardX11 no Discussions of security flaws within X11 have been going on for years. The "issue" in SSH X11 forwarding is not new. SSH has added to the security of X11, but by no means does the use of SSH secure X11. -- Brian Caswell <[EMAIL PROTECTED]> If I could load the world into vi, the first command I would use is: %s/Windows NT//gi PGP signature
Re: Bypass Virus Checking
Hmmm . . must depend on if it's 98/NT or not - I was able to observe the .txt file NOT being deleted, and I'm running (if it can be called that) '98 (not sure if it's Rev 1 or 2). B
Re: SyGate 3.11 Port 7323 / Remote Admin hole
When we last heard from you, the following words rang out across the 'Net: >The Sygate gateway server is the computer that connects >to the Internet and is running the Sygate software. >Sygate runs on Win95/98 and Windows NT 4.0 ( Service >Pack 3 and higher). On NT Server 4.0 it installs and >runs as an NT Service. >Sybergen does NOT document this utility. Cute. >This "Remote Administration Engine" (RAE) is SUPPOSEDLY >ACCESSIBLE ONLY FROM THE INTERNAL NETWORK, by >initiating a Telnet session to port 7323 on the Sygate >gateway. For security reasons, access to this utility >from the Internet is SUPPOSED to be blocked. >However, I have been able to access the Sygate Remote >Administration Engine from outside the Sygate gateway. >I have been able to initiate a Telnet session to port >7323 of a Sygate 3.11 gateway from machines on the >Internet that were supposed to NOT be able to establish >this kind of connection. >I have been able to duplicate this security hole on a >number of machines running Windows NT Server 4.0 with >Service Pack 4 and Sygate 3.11 builds 556 and 560. I >have not tested this on Win95/98. Also, all these NT >servers did NOT have the Sygate "Enhanced Security" >feature enabled, nor were these NT servers running >Secure Desktop (SyShield), a Sybergen firewall product. Verified with NT Workstation and Sygate as well. >HOWEVER, this access via Telnet over the Internet is >possible only ONCE per NT Server reboot. I do not know >why this is so but after ending the initial Internet >connection to port 7323 of the Sygate server, another >Telnet session cannot connect to that port until the NT >server is rebooted. Verified as well. Odd but handy. I suppose another interim fix is to make sure you telnet from external as soon as your machine has booted :) B. -- Brian P. Hampson ASL Analytical Service Laboratories Ltd System Administrator, Vancouver, BC (604)253-4188 - http://www.ASL.CA/ Speaking for myself, not ASL
Re: Security Issues with HIGHSPEEDWEB.NET leased servers
This is a follow-up to my origional message. <-- begin cut here --> Elias - Please post this message to BugTraq, I have been asked by highspeedweb to make a public appology and further explain my intentions. The origional message came off sounding like a complaint it seems, and I have no problems appologizing if I stepped on anyones toes as it was not my intention to do so. <-- end cut here --> Public Appology I would like to point out that it was not my intention at any time to humiliate, or publicly harm highspeedweb in any way. I use their services and if they weren't good in general I would not continue to do so. I have suggested many of my clients to use highspeedweb for their dedicated/colocated server solutions and I would not have done so if the service was bad. It has also come to my attention that someone other than highspeedweb may have removed the deny all:all line from the hosts.deny file. That being the case their configuration was secure when they released its administration to myself. Thank you, Brian Mueller ***** Brian Mueller President/CEO CreoTech "We are the future" www.creotech.com [EMAIL PROTECTED] 513.722.8645 *
Security Issues with HIGHSPEEDWEB.NET leased servers
Recently I started leased a dedicated server from HIGHSPEEDWEB.NET, it came preconfigured (somewhat) and I was told that it would be "secure" for telnet (only specifically stated IP address(s) could gain access), etc. However, I have found that this is not the case, it seems that they do not place limiting information in the host.deny file so anyone can still telnet into the server. Also, their mail configuration which allows users to add mail aliases either via a web interface or by editing a file called .mailalias in their home directories is faulty. Users may place _ANY_ valid local domain into this file and forward mail from that domain to their email address. The system works by running a cron script once per day and updating the sendmail virtual user database. The following is an example person A has a webhosting account on the HIGHSPEEDWEB.NET configured server, person B wishes to "steal" email from Person A, they are targeting the [EMAIL PROTECTED] as the attacked address and they are going to have that forwarded to [EMAIL PROTECTED], they add the following line to their .mailalias file [EMAIL PROTECTED][EMAIL PROTECTED] when the next update occurs any email sent to [EMAIL PROTECTED] will be forwarded to [EMAIL PROTECTED], this also works with wildcards i..e. @person-a-domain.com[EMAIL PROTECTED] would work if your entry is read into the sendmail virtual user database before the one that exists in Person A's directory. I notified HIGHSPEEDWEB.NET of the security issue well over a month ago and have not had any response from them regarding a fix. I however did instate one of my own my forcing users to call myself to have aliases added for the time being. Brian Mueller ***** Brian Mueller President/CEO CreoTech "We are the future" www.creotech.com [EMAIL PROTECTED] 513.722.8645 *
Re: XML in IE 5.0
On Fri, 14 Jan 2000, Ryan Russell wrote: > For Windows users, The MS guys gave an interesting talk at the NTBugtraq > Canada Day Party at Russ' house last year. NT2000 will include a feature that > is similar to su on unix, which will allow one to have different windows open > as different users on the same box... I believe it's an extension of the > terminal server concept. Anyway, once folks get NT2000, they should really > consider running their browsers as locked-down, non-priveledged users. Except that browsers have exchanges with the outside world that carry personalization with it, so at some level the browser needs to be tied with an identity, and compromising that identity will always be a concern. But that's another topic; just wanted to prove there's no easy solution, but it's good to see MS playing catchup with Unix on this, even if it has been 15-20 years. Brian
Re: Anyone can take over virtually any domain on the net...
Just some FYI, The ID number that network solutions uses in it's submission forms is used ONLY if you A) Have a problem and need to contact them via email about a specific transfer, etc. b) You have a problem and need to call them personally. What I mean is the contact number is used ONLY to lookup instances in their database (i.e. it's an ID number assiciated with an event) it is not used in any way for validation purposes, it never was used for validation purposes, and in its current form it never should be used for validation purposes. On another note, isn't it about time to kill this thread? What more can be said (other than examples?) Brian ***** Brian Mueller President/CEO CreoTech "We are the future" www.creotech.com [EMAIL PROTECTED] 513.722.8645 * - Original Message - From: <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, January 14, 2000 10:26 AM Subject: Re: Anyone can take over virtually any domain on the net... > I didn't think you could spoof a domain registration change so easily; > looking at this post: "http://www.sans.org/y2k/123199-1305.htm", It > says: > > "This is the Domain Name Registration Agreement you recently created. In > order to complete this modification, > YOU MUST E-MAIL THIS FORM TO: [EMAIL PROTECTED] > After you e-mail this form, you should receive an auto-reply with a > tracking number. You must use that number in the Subject of any future > messages you send regarding this registration action. Once this > registration action is completed you will receive a notification via > e-mail." > > This confims what I always thought; that there was a unique number in > the response that was needed for the ACK. You know- it is similar to > when you subscribe to an email mailing list and they request an ACK and > the ACK has to have a unique number in it. Those email messages you get > from Network Solutions have a funny number in the subject line- I > thought it was used as follows: > > For a domain alteration, I thought it was that > 1) Hostmaster/Domain owner sends Change Request --> > 2) NSolutions gets Change Request <-- > 3) NSolutions sends Ack Request w/ unique confimation number --> > 4) Hostmaster gets Ack Request w/ unique confimation number <-- > 5) Hostmaster must send Ack Reply w/ unique confimation number --> > 6) NSolutions gets Ack Reply, and checks that the unique identifier to > confirm it was a true response to the Ack Request. <-- > > I didn't think that the change would go through unless the Ack Reply had > that unique number. > > Now, that being said, I always had in my mind a way to do the spoof > anyway, because the numbers in the Internic email messages always looked > like they were generated with the time/date and some sequential number, > and there didn't seem to be anything random in them. > > So I'll mention how I figured you could go a step further to engineer a > working spoof. > > 1) Start with two or three domains that you have ownership of, > MyOne.com, MyTwo.COM and MyThree.COM, TakeOver.com (TakeOver.com is the > domain you want to capture DNS of) > > 2) Send an update for the domains in this order: > MyOne.COM > MyTwo.COM > TakeOver.COM <--the one you want to alter. > MyThree.COM > > 3) I figured that if you send the updates at a low traffic time (5AM?) > and send them immediately after one another... > > 4) You will get ACK requests for the ones that belong to you. The change > request for TakeOver.COM didn't come to you, but I figured that you > could look at the # in the header of your three and interpolate the > needed value for the ACK to change TakeOver.COM > > But if the number doesn't really matter, then I guess I was thinking too > hard... > > I thought this up a few years ago, but never had the time to give it a > try. > > -Rozz > > > -Original Message- > > From: Jonah Benton [mailto:[EMAIL PROTECTED]] > > Sent: Thursday, January 13, 2000 3:50 PM > > To: Adrian Goins; '[EMAIL PROTECTED]' > > Subject: FW: Anyone can take over virtually any domain on the net... > > > > > > > > Either of you hear about this? I thought there were tracking > > numbers in that > > email dialogue... > > > > -Original Message- > > From: Thomas Reinke [mailto:[EMAIL PROTECTED]] > > Sent: Wednesday, January 12, 2000 12:27 AM > > To: [EMAIL PROTECTED] > > Subject: Anyone can take over virtually any domain on the net... > > > > > > Wired recently ran an article on the fact that someone >
Re: Anyone can take over virtually any domain...
Actually, it goes MUCH farther than what has been mentioned here thus far. I run a commercial webserver, and I run my own DNS for that webserver. Once a while back we migrated all of our DNS information from a slower machine to a faster machine. Rather than renaming the hostname and IP address of the new machine we gave it a totally new hostname and IP address. Now I was faced with a problem. I had a *lot* of websites that needed to have their entries at network solutions changed to point to the new DNS servers. Well, I decided to give it a shot and I sent Network Solutions an e-mail stating my problem and my intended solution, along with a list of all of the domains which needed to be changed to a new DNS server. They did it without asking anymore questions, and without sending notification to all of my clients. This raises the question. What about stealing an entire DNS server and pointing it to your own box? I did it with my own servers, why couldn't anyone else? Brian Mueller * Brian Mueller President/CEO CreoTech "We are the future" www.creotech.com [EMAIL PROTECTED] 513.722.8645 *
Re: CuteFTP saved password 'encryption' weakness
* Nick FitzGerald ([EMAIL PROTECTED]) [01/05/00 12:14]: > This means that stealing of tree.dat not only allows the thief access > via CuteFTP to any 'secrets' that may be recorded in that file, but > they can also be easily decoded for other uses. The v3.x releases of > CuteFTP store this data in smdata.dat (the virus does not look for > that file) but it has a very similar appearing structure to tree.dat > and uses the same 'encryption' of stored passwords. This is a moot point anyways. Anyone who can grab your tree.dat or smdata.dat can have your passwords even if they were to be strongly encrypted. One would only have to download and install their own copy of cuteftp, stick the associated .dat file in it's path, run cuteftp, and hit connect. Your local machine or another on your network could easily run a sniffer and grab your plain text passwords as your client connects. If you don't want to tip off the admin of a remote site that you have one of their users passwords, than just replace the real servers IP with an ftp server you control. -bk
Re: Subscription bomb tracing - feature request.
Most systems have some option to log the IP address and/or hostname of the attacker. However it has been my exprience that when someone really wants to "attack" someone they will use one of the _very_ few email systems which still do not verify the user (i.e. no HELO and they accept anything you send them). It wouldn't be too hard for an attacker to use one of these such systems to make it seem that the request came from satan.hell.hot (666.666.666.666) or some-such. Also, I have a mailing list which I wrote in PHP3. It logs the applicants IP address and Hostname to the database when it receives a request, along with a randomly generated, unique 8 digit ID number. When someone signs-up for the list a confirmation mail is sent to them. At the bottom of this confirmation message is a short disclaimer/legal notice along with information on how to report abuse using the 8 digit number. I personally want to centralize all abuse cases with myself. The user reports abuse based on the 8 digit number and I look that up in the database to find out where the user was added from. In this way I can do much more than just stop a single user, I can see if a set of IP's is attacking often - and ban them, etc. I think this is the best setup because the burden shouldn't be placed on the user to find out who the abuser is. B - Original Message - From: "Alan Brown" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, January 03, 2000 9:15 PM Subject: Subscription bomb tracing - feature request. > There have been quite a few subscribe bombs tossed around recently. > > While it's nice to see that most mailing list admins use confirm > requests now, it would be a great help if the confirm requests contained > at least the headers of the original request, to aid victims in tracing > their attacker(s). > > One attack recently notified to ORBS attempted to sign the victim up to > 26,000 different lists via insecure email relays. > > The confirmation requests alone constituted a fairly substantial denial > of service attack, as did the huge number of bounces the victim got. > > I've only ever seen one mailing list which actually showed where the > signup request came from. Times are still changing and adding an audit > trail would make life easier all round. > > AB
Re: Groupewise Web Interface
<<>> >Here's the interesting bit: Modify the URL by removing the *.html file. Now >you can browse the directory structure of the web server. Go to the >/com/novell/webaccess directory and what do we find? The webacc.cfg file. >The file actually contains the version of the server, Novell paths, etc. >No passwords are contained here. The actual gateway password is stored >encrypted in the commgr.cfg file (which is stored in a location separate >from the actual web pages/servlets). <<>> This must be with Novell's Web Server? There is no "com" folder anywhere on my GroupWise 5.5 SP2 box with Netscape Enterprise Server. Novell's Web Server is not certified y2k compliant, and is not supported by Novell. I can't believe anyone is still using it... I have not found any way to read non-HTML files with the HELP vulnerability mentioned earlier (with my setup). I can, however, read any .htm or .html file within the Web root (default: sys:\novonyx\suitespot\) I too, experienced an "abend" with the ...HELP=very_long_string, but every service on the server continued to run normally. (each of the six times I tried it) Brian
Re: Groupewise Web Interface
This vulnerability exists on the Enterprise Web Server. Brian >>> Raymond Dijkxhoorn <[EMAIL PROTECTED]> 12/20/99 02:29PM >>> Hi! > 1. The help argument in GWWEB.EXE reveal full web path on the server > 2. anyone can read a .htm file on the system with the GWWEB.EXE and the HELP > argument. > This was tested on GroupWise 5.2 and 5.5 . Why didnt you upgrade to the one wich was shipped on 5.5 ?? The Netscape Enterprise server ??? As far as i know the Novell webserver is no longer in development and the new ones were builded under the 'Novonyx' flag Novell/Netscape. Bye, Raymond Dijkxhoorn
Re: Groupwise Web Interface
<<>> >1. The help argument in GWWEB.EXE reveal full web path on the server >2. anyone can read a .htm file on the system with the GWWEB.EXE and >the HELP agument. >by sending http://server/cgi-bin/GW5/GWWEB.EXE?HELP=../../../../../index >You will see the main web site interface. <<>> The above example will vary based on how your Web server is set up. The exact path listed above did not work for me, but modifying it to match my server set up did. Note that testing was done on NetWare 4.11 SP6 The vulnerability will also show the contents of .html files, but not .shtml Possible workaround: Change extension to .shtml - these are not shown Possible workaround: For each Web page, have two separate pages with the same name - one with .htm extension and one with .html extension. Use .htm for the pages with real content. When two pages with the same name, but these different extensions exist, this vulnerability will show .html instead of .htm. Possible workaround: Turn off WebAccess until Novell fixes it. Possible (recommended) solution: Use separate server for Web pages and GroupWise WebAccess. Apache seems to be a good choice... haven't seen it for NetWare though. Note that this DOES show pages that are in areas normally requiring authentication, without requiring such authentication, therefore making it a security risk. Relative-path links from this page will be broken; absolute paths will (of course) work normally. If you don't have any areas of the site that require authentication, this problem doesn't matter. Also - after deleting the page entirely from the server, and accessing it from another computer that did not have it in cache, I was still able to access the now non-existing page. I assume it's still in the server's cache... (I even purged it and still accessed it) Shift-reload did not change anything. Brian
Re: ISS Security Advisory: Buffer Overflow in Netscape Enterprise andFastTrack Authentication Procedure
>Buffer Overflow in Netscape Enterprise and FastTrack Authentication >Procedure <<>> >Affected Versions: >This vulnerability affects all supported platforms of Enterprise and >FastTrack web servers. Enterprise 3.5.1 through 3.6sp2 and FastTrack >3.01 >were found to be vulnerable. Earlier versions may be vulnerable but were >not >tested by ISS X-Force. >Description: >The buffer overflow is present in the HTTP Basic Authentication portion of >the server. When accessing a password protected portion of the >Administration or Web server, a username or password that is longer than >508 characters will cause the server to crash with an access violation >error. An attacker could utilize the Base64 encoded Authorization string >to execute arbitrary code as SYSTEM on Windows NT, or as root on Unix. >Attackers can use these privileges to gain full access to the server. <<>> A similar problem exists in the Enterprise Web Server for NetWare 4.x and 5.x. When a username >310 chars is sent to the Admin Server, the Admin server crashes. Authentication to other password protected areas of the Web Server is not affected. SPECIFICS: With the Enterprise Server for NetWare, the admin port on the server will allow a username of any length when authenticating. A username of more than 310 characters will cause the admserv.nlm to crash. The admin port then is not accessable again until the server is rebooted. An attempt to manually unload the nlm caused the server to lock up completely. An attempt to reload the nlm resulted in a message stated the nlm was already loaded. The offending process (admserv.nlm) does not appear to stop other services running on the server. The Web server continues to function normally, as does the LDAP authentication to other restricted areas. (I only tested restricted subdirectories within the web root) Regular directories within the Web site that require authentication are not vulnerable. Submitting a long username and/or password (somewhere over 1000 chars, I believe) will result in a message "Your browser sent a message this server could not understand." I tested on a 4.11 box with SP7. Not sure if priviledges can be gained... FIX: The Admin server can be turned off when not in use, or block that port with your firewall. I contacted an engineer at a local Novell office on Dec 2 with no response. Don't see a way on their site to report bugs :( Brian
Re: buffer overflow in HP JetDirect module (probably affects all HP printers with network support)
> Obviously it's a M680x0 CPU with 512 KB of RAM in our model, so > writing an exploit should be fairly easy. The nice point about it is > that most people wouldn't expect their printer to be compromised -- > and since there is no logging on the printer, you can't easily be > tracked down... HP JetDirects can have the web server turned off (a good idea) and use remote syslog to log all connections to the printer. The HP print server control software automaticly turns the web configuration back on, so I wouldn't use that, I would physicly go up to the printer and disable all services you don't need. If only one could add in ip allow ranges, then I would be happy. -cazz PGP signature
default permissions for tin
the default permissions for the tin (v 1.4.0) configuration directory allows users to read passwords [cazz@ruff:~]$ ls -la |grep .tin drwxr-xr-x 7 cazz cazz 1024 Nov 17 09:03 .tin [cazz@ruff:~/.tin]$ ls -la .inputhistory -rw-rw-r-- 1 cazz cazz 8192 Nov 17 09:21 .inputhistory if a user is using an authenticated news server, tin saves all keystrokes typed into tin in the file ~/.tin/.inputhistory simple solution, rm -f ~/.tin/.inputhistory touch ~/.tin/.inputhistory chmod 000 ~/.tin/.inputhistory -cazz PGP signature
Re: ssh-1.2.27 remote buffer overflow - exploitable (VD#7)
On Sat, 13 Nov 1999, Theo de Raadt wrote: > The upcoming OpenBSD 2.6 release contains/includes an ssh implimentation > which is derived from an earlier ssh 1 (and thus has no Datafellows > licencing issues). We are calling this ssh by the name "OpenSSH". > > Anyways, in the process of rewriting parts of ssh, the OpenSSH > developers accidentally fixed this bug. Whoops! :-) I'd like people to note that, in FreeBSD, you should be using the "OpenSSH-1.2" package, ports/security/openssh. This is a direct port of the OpenSSH source from the OpenBSD CVS, and as such is that much more secure than plain SSH, and OpenSSH should be used instead where possible. -- Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! / [EMAIL PROTECTED]`--'
Re: your mail
On Thu, 11 Nov 1999, Anonymous wrote: > Ooh, those pesky NXT records. Like I process those every day. > Fascinating read in RFC 2535, but suppose I don't have any NXT > records in my own zones, under what circumstances will my DNS server > commit the sin of "the processing of NXT records"? In other words, > are all of us vulnerable (even caching-only name servers if so, I > imagine!), or only people with NXT records? This makes a big difference! Caching-only servers are also vulnerable. The NXT record is no different that any other DNS record in this case. If someone is able to make your server fetch a maliciously-constructed NXT record, it will cause problems. A query to a caching server will force the server to send a recursive query, which makes the caching server vulnerable. Brian
bugtraq@securityfocus.com
When we last heard from you, the following words rang out across the 'Net: >I tested your script on my own Hotmail account, but the execution of the >Javascript failed. I'm using Netscape Communicator 4.05. >I also tested the same script using Internet Explorer 4.0 build 4.72.3110.4 >SP1, it didn't execute in IE. The Javascript alert works in IE5. I don't think the "first message in your mailbox part" does though. I had cobbled together a very basic HTML message consisting of: -YOUR FAVOURITE CODE HERE INCLUDING ASCII replacement for javascript- I can't see that Hotmail will ever be able to block javascript if this is the case...think..you could replace any letter, or any combination of letters. Major coding hassle. -- Brian P. Hampson ASL Analytical Service Laboratories Ltd System Administrator, Vancouver, BC (604)253-4188 - http://www.ASL.CA/ Speaking for myself, not ASL
socket buffer DoS/administrative limits (fwd)
-- Forwarded message --
Date: Fri, 17 Sep 1999 12:32:01 -0400 (EDT)
From: Brian F. Feldman <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: socket buffer DoS/administrative limits
Yes folks, it's that time again: time for more administrative limits!
I've worked out a resource limit (for FreeBSD in this case, but not
non-portable) which allows prevention of DoS by mbuf starvation. Others
are working on making the networking code more resilient, while this is
a general resource limit which can be used in any case.
I've chosen the name "sbsize" (RLIMIT_SBSIZE) for this. Here's what
happens with the limit in action (note that the pdksh in use has been
patched to include the ulimit):
{"/home/green"}$ ulimit -b 200 ; ulimit -a | grep sbsize
sbsize(bytes)200
{"/home/green"}$ ./testsockbuf
socketpair: No buffer space available
14 sockets had been allocated
And another DoS attempt has been foiled with administrative limits :)
I'm sorry for not having something working sooner, but I ran into the problem
of my KASSERT() being tripped, which ended up being caused by me not
grokking an evil local define (look for "#define (snd|rcv) "...) correctly.
After fixing that, everything is wonderful.
The patch, which applies to FreeBSD 4.0-CURRENT, and should be easily
portable or backportable, can be found at:
http://www.FreeBSD.org/~green/sbsize4.patch
--
Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! /
[EMAIL PROTECTED]`--'
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Cisco 675 password nonsense
On Fri, 6 Aug 1999, Dave Dittrich wrote: > > With good reason. In bridging mode with a Windows 9x/NT box, your network > > neighborhood will show everyone else's PC that has any file/print sharing > > enabled. So, it's trivially easy to connect to a non-passworded share. > > That depends on the DSL provider, I believe. On my USWest.net DSL > connection, I only see packets on my side of the bridge that are > destined for IP addresses I'm using, or broadcast ethernet/IP packets, > which seems to be the same as what @Home customers (at least the ones > in Seattle I've spoken with) see. I've heard from other DSL customers The broadcast packets are what are used for discovering other computers in the Network Neighborhood. US West may be filtering on port 139 to prevent this now. This was a problem with USWest.net, at least in the beginning of DSL. Brian
Re: Cisco 675 password nonsense
On Sat, 31 Jul 1999, DeMoNx wrote: > switching all non-business/special adsl accounts over to using PPP rather > than bridging mode for 'security reasons', I got a little suspicious. With With good reason. In bridging mode with a Windows 9x/NT box, your network neighborhood will show everyone else's PC that has any file/print sharing enabled. So, it's trivially easy to connect to a non-passworded share. Now, ideally, all these shares would be passworded, but we know that'll never happen. Not having the shares show up in network neighborhood is a bit of security by obscurity, but it's harder to connect to a share if it's not in your network neighborhood. > them. The problem is, *most* of these guys don't set passwords on the > 675's. It is very simple to compromise an unpassworded 675. simply hit > 'enter' at the password prompt after telnetting in, if you get a cbos> > promt you are half way there, NOT GOOD. If there is no exec mode password > set, then there most likely won't be an enable(superuser) mode password Cisco has recognized this as a problem. This is fixed in 2.1.0a or in 2.2.0 (2.2.0 out shortly). The 675 will react like classic IOS and not allow telnet if a exec password is not set. BTW, in US West land at least, 90 to 95% of all installs are self install where a tech never visits the customer. Brian
