Cisco Elastic Services Controller Service Portal Authentication Bypass Vulnerability

A vulnerability in the authentication functionality of the web-based service portal of Cisco Elastic Services Controller Software could allow an unauthenticated, remote attacker to bypass authentication and execute arbitrary actions with administrator privileges on an affected system.

The vulnerability is due to improper security restrictions that are imposed by the web-based service portal of the affected software. An attacker could exploit this vulnerability by submitting an empty password value to an affected portal when prompted to enter an administrative password for the portal. A successful exploit could allow the attacker to bypass authentication and gain administrator privileges for the web-based service portal of the affected software.

Cisco has released software updates that address this vulnerability. There are no workarounds that address this vulnerability.

This advisory is available at the following link:
https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20180221-esc

Security Impact Rating: Critical

CVE: CVE-2018-0121

Related:

  • No Related Posts

Cannot connect to company network” when accessing O365 accounts

Secure Mail for iOS supports modern authentication (OAuth token-based authentication with User name and password) with Microsoft Office 365.

Prerequisites:

1.Enable modern authentication (OAuth) for Microsoft Office 365For details, see https://technet.microsoft.com/en-us/library/dn594521(v=exchg.150).aspx

2.Migrate your on-premises mailboxes to Microsoft Office 365For details, see https://technet.microsoft.com/en-IN/library/o365e_hrcmoverequest_fl312271(v=exchg.150).aspx

Next, ensure that you have configured the following MDX policies in the XenMobile console listed under OAuth Support for Office 365:

Office 365 authentication mechanism. This policy indicates the OAuth mechanism used for authentication while configuring an account on Office 365.

Do not use OAuth. OAuth is not used and Secure Mail uses basic authentication (username and password) for Office 365 Exchange account configuration. This is the default setting.

Use OAuth with Username and Password. The user must provide their email, password, and a multi-factor authentication code on the Secure Mail authentication screen for Microsoft. Then, on the next screen, the user must grant Secure Mail permission to access the Office 365 mailbox.

•Trusted Exchange Online Hostnames. Define a list of trusted Exchange Online hostnames that use the OAuth mechanism for authentication while configuring an account. This is a comma-separated format, such as server.example.com,server.example.co.uk. If the list is empty, Secure Mail uses basic authentication for account configuration. Default value is outlook.office365.com.

•Trusted AD FS Hostnames. Define a list of trusted AD FS hostnames for webpages where the password populates during Office 365 OAuth authentication. This is a comma-separated format such as sts.examplename.com, sts.example.co.uk . If the list is empty, Secure Mail does not auto populate passwords. Secure Mail matches the listed hostnames with the hostname of the webpage encountered during Office 365 authentication and checks if the page uses HTTPS protocol. For instance, when sts.example.com is a listed hostname, if the user navigates to https://sts.example.com, Secure Mail populates the password if the page has a password field. Default value is login.microsoftonline.com.

Secure Mail for iOS is now enabled with modern authentication when the policies are refreshed on the device.

Related:

  • No Related Posts

How to convert UPN logon name (username@domain) to 'domainusername'.

Resolution:

Achieved using n-factor, following are the configurations that are performed:

1.Configure Authentication Vserver:

  • add authentication vserver nFactor_Radius

2.Configure Authentication Profile:

  • add authnProfile nfactor_prof -authnVsName nFactor_Radius

3.Set the vpn server with the profile:

  • set vpn vserver <> -authnprofile nfactor_prof

4.Configure two Authentication policies: upn_no_auth (to take care of Case 1) and Radius_Pol (to take care of Case2).

upn_no_auth

  • add authentication Policy upn_no_auth -rule “HTTP.REQ.BODY(1000).TYPECAST_NVLIST_T(‘=’,’&’).VALUE(“login”).CONTAINS(“%40″)” -action NO_AUTHN
  • bind authentication vserver nFactor_Radius -policy upn_no_auth -priority 90 -nextFactor second_factor_Radius -gotoPriorityExpression NEXT

Radius_pol

  • add authentication radiusPolicy Radius_Policy ns_true Radius_server
  • add authentication Policy Radius_Pol -rule true -action Radius_server
  • bind authentication policylabel second_factor_Radius -policyName Radius_Pol -priority 100 -gotoPriorityExpression NEXT
  • bind authentication vserver nFactor_Radius -policy Radius_Pol -priority 100 -gotoPriorityExpression NEXT

second_factor_Radius

  • add authentication policylabel second_factor_Radius -loginSchema second_factor_schema
  • bind authentication policylabel second_factor_Radius -policyName Radius_Pol -priority 100 -gotoPriorityExpression NEXT
  • bind authentication vserver nFactor_Radius -policy upn_no_auth -priority 90 -nextFactor second_factor_Radius -gotoPriorityExpression NEXT

Note:

  • ‘upn_no_auth’ policy is to bypass authentication to the next factor if user enters UPN i.e in case1. Configured upn_no_auth policy is checking for ‘%40’ as ‘@’ is being encoded by browser.
  • Radius_Pol is the first factor (case2).
  • Second_factor_Radius is the second factor and will be used for UPN.

Related:

  • No Related Posts

Cisco Firepower Management Center Disk Utilization Denial of Service Vulnerability

A vulnerability in the Shell Access Filter feature of Cisco Firepower Management Center (FMC), when used in conjunction with remote authentication, could allow an unauthenticated, remote attacker to cause high disk utilization, resulting in a denial of service (DoS) condition.

The vulnerability occurs because the configuration of the Shell Access Filter, when used with a specific type of remote authentication, can cause a system file to have unbounded writes. An attacker could exploit this vulnerability by sending a steady stream of remote authentication requests to the appliance when the specific configuration is applied. Successful exploitation could allow the attacker to increase the size of a system log file so that it consumes most of the disk space. The lack of available disk space could lead to a DoS condition in which the device functions could operate abnormally, making the device unstable.

There are no workarounds that address this vulnerability.

This advisory is available at the following link:
https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20190109-fpwr-mc-dos

Security Impact Rating: Medium

CVE: CVE-2018-15458

Related:

  • No Related Posts

Citrix forces password reset to protect against credential stuffing

From https://www.citrix.com/blogs/2018/12/04/citrix-forces-password-reset-to-protect-against-credential-stuffing/

2018 has seen an unprecedented number of records breached by hackers. According to the Breach Level Index, in just the first half of 2018, more records were compromised than in all of 2017. The number of records compromised in 2018 is in the multi billions. It’s staggering. With the credentials harvested from these attacks, and the bad guys knowing that people will use the same password for multiple systems and websites, “credential stuffing” — a type of cyber-attack where stolen emails and passwords obtained through these types of breaches are used to try and gain unauthorized access to other systems — has become a serious threat facing businesses and individuals.

Late last week, not long after new high profile security breaches were revealed, in the course of our ongoing security monitoring, we saw incidences in ShareFile that had some of the characteristics of credential stuffing. After further analysis, we became very concerned that indeed perpetrators were using credentials obtained from breaches unrelated to ShareFile to attempt to gain access to individual accounts. We do not believe that this issue resulted from a compromise of our systems.

We made an immediate decision to limit the risk to our ShareFile customers by forcing a password reset. We knew the timing over the weekend was not ideal, but felt it far more important to help our customers by fundamentally stopping the credential stuffing effort. We acknowledge it has been inconvenient to customers, and regret the inconvenience, but we were acting in our customers’ best interests. It was the most expeditious way to end the attack, and proactively help our customer protect their data.

To be clear, if there is any misunderstanding, the users of the ShareFile service were experiencing a credential stuffing attack. We moved quickly and decisively to end it for the benefit of our users.

ShareFile supports multi-factor authentication, a security mechanism that requires more than one method of authentication (for instance a password and security code received as a SMS). We strongly recommend multi-factor authentication as a best practice, and it is an optional setting within ShareFile that administrators can turn-on.

In the interim, we are working to help our customers with their password resets, even bringing on extra help to process calls and tickets faster. We do point administrators to the support page first, which provides a wealth of direction and tips, as wait times for the help desk are lengthy at the moment but expected to improve. Please refer to the articles “Modify ShareFile Security Settings” https://support.citrix.com/article/CTX227767 which will assist you in Password Management, and “ShareFile Password Management” https://support.citrix.com/article/CTX208278 which will assist you with the Forgot Password functionality, which is needed to reset your password.

Related:

  • No Related Posts