Cisco ASR 920 Series Aggregation Services Router Model 12SZ-IM SNMP Denial of Service Vulnerability

A vulnerability in the Simple Network Management Protocol (SNMP) implementation in Cisco ASR 920 Series Aggregation Services Router model ASR920-12SZ-IM could allow an authenticated, remote attacker to cause the device to reload.

The vulnerability is due to incorrect handling of data that is returned for Cisco Discovery Protocol queries to SNMP. An attacker could exploit this vulnerability by sending a request for Cisco Discovery Protocol information by using SNMP. An exploit could allow the attacker to cause the affected device to reload, resulting in a denial of service (DoS) condition.

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

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

Security Impact Rating: Medium

CVE: CVE-2020-3232

Related:

Error “No Apps available at this time” on workspace for iOS app after upgrading to ADC 13.0 build 52.24

Version 13.0 build 52.24 do not set pwcount cookie in response to /vpn/index.html request as below.

HTTP/1.1 200 OK

Date: Fri, 08 May 2020 05:19:10 GMT

Server: Apache

X-Frame-Options: SAMEORIGIN

Last-Modified: Fri, 08 May 2020 04:56:44 GMT

Accept-Ranges: bytes

Content-Length: 3674

Cache-Control: no-cache, no-store, must-revalidate

Pragma: no-cache

Expires: 0

Keep-Alive: timeout=15, max=92

Connection: Keep-Alive

Content-Type: text/html; charset=UTF-8

Set-Cookie: pwcount=0;Secure;HttpOnly;Path=/;expires=Wednesday, 09-Nov-1999 23:12:40 GMT

Cache-Control: no-cache

Related:

Cisco Firepower Threat Defense Software SSL/TLS URL Category Bypass Vulnerability

A vulnerability in the Transport Layer Security version 1.3 (TLS 1.3) policy with URL category functionality for Cisco Firepower Threat Defense (FTD) Software could allow an unauthenticated, remote attacker to bypass a configured TLS 1.3 policy to block traffic for a specific URL.

The vulnerability is due to a logic error with Snort handling of the connection with the TLS 1.3 policy and URL category configuration. An attacker could exploit this vulnerability by sending crafted TLS 1.3 connections to an affected device. A successful exploit could allow the attacker to bypass the TLS 1.3 policy and access URLs that are outside the affected device and normally would be dropped.

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-ssl-bypass-O5tGum2n

Security Impact Rating: Medium

CVE: CVE-2020-3285

Related:

  • No Related Posts

Cisco IOS XR Software IPsec Packet Processor Denial of Service Vulnerability

A vulnerability in the IPsec packet processor of Cisco IOS XR Software could allow an unauthenticated remote attacker to cause a denial of service (DoS) condition for IPsec sessions to an affected device.

The vulnerability is due to improper handling of packets by the IPsec packet processor. An attacker could exploit this vulnerability by sending malicious ICMP error messages to an affected device that get punted to the IPsec packet processor. A successful exploit could allow the attacker to deplete IPsec memory, resulting in all future IPsec packets to an affected device being dropped by the device. Manual intervention is required to recover from this situation.

Cisco has released software updates that address the vulnerability described in this advisory. There are workarounds that address this vulnerability.

This advisory is available at the following link:
https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-iosxr-ipsec-dos-q8UPX6m

Security Impact Rating: Medium

CVE: CVE-2020-3190

Related:

Cisco NX-OS Software Border Gateway Protocol MD5 Authentication Bypass Vulnerability

A vulnerability in the implementation of Border Gateway Protocol (BGP) Message Digest 5 (MD5) authentication in Cisco NX-OS Software could allow an unauthenticated, remote attacker to bypass MD5 authentication and establish a BGP connection with the device.

The vulnerability occurs because the BGP MD5 authentication is bypassed if the peer does not have MD5 authentication configured, the NX-OS device does have BGP MD5 authentication configured, and the NX-OS BGP virtual routing and forwarding (VRF) name is configured to be greater than 19 characters. An attacker could exploit this vulnerability by attempting to establish a BGP session with the NX-OS peer. A successful exploit could allow the attacker to establish a BGP session with the NX-OS device without MD5 authentication.

The Cisco implementation of the BGP protocol accepts incoming BGP traffic only from explicitly configured peers. To exploit this vulnerability, an attacker must send the malicious packets over a TCP connection that appears to come from a trusted BGP peer. To do so, the attacker must obtain information about the BGP peers in the affected system’s trusted network.

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

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

Security Impact Rating: Medium

CVE: CVE-2020-3165

Related:

Can the management centre send a Radius “AVP” to the Radius server?

I need a solution

Hi;

Can the management centre send a Radius attribute “AVP” to the Radius server? I mean in the Radius Authentication Request?  ideally, I would like the Management Centre to send the IP address of the user device supplying the username and password on the Management Centres login page, which in turn will be sent to the Radius server.

So ideally, the MC should send the following to the Radius server:  “username+password+the IP address of the device of the user trying to authenticate”.

Kindly

Wasfi

0

Related:

Cisco IP Phone Remote Code Execution and Denial of Service Vulnerability

A vulnerability in the Cisco Discovery Protocol implementation for the Cisco IP Phone could allow an unauthenticated, adjacent attacker to remotely execute code with root privileges or cause a reload of an affected IP phone.

The vulnerability is due to missing checks when processing Cisco Discovery Protocol messages. An attacker could exploit this vulnerability by sending a crafted Cisco Discovery Protocol packet to the targeted IP phone. A successful exploit could allow the attacker to remotely execute code with root privileges or cause a reload of an affected IP phone, resulting in a denial of service (DoS) condition.

Note: Cisco Discovery Protocol is a Layer 2 protocol. To exploit this vulnerability, an attacker must be in the same broadcast domain as the affected device (Layer 2 adjacent).

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-20200205-voip-phones-rce-dos

Security Impact Rating: High

CVE: CVE-2020-3111

Related:

Remote Server returned/ Client was not authenticated to send anonymous mail during MAIL FROM [BN6PR12CA0048.namprd12.prod.outlook.com]>

I need a solution

Hello,

We cancled our Symantec account a couple of years ago and sicne then quite a few institutuions/business have been unable to email us as emails addressed to our domain are retunred undeliverable.  Recently we were advised that the issues appears to be that as a former Symantec customer that we did not terminate the service properly after we moved to Office 365. We were advised to contact Symantec to have the service compeletly terminated.  Below is a sample of the error message inclusive of the Diagnostic Info,  recieved by someone attemntting to email us.  A Symantec message does appear in the diagnotic in the diagnostic information: 

(using TLS with cipher AES128-SHA (128/128 bits))

        (Client did not present a certificate)

        by znpcpapbrg01i.bnymellon.com (Symantec Messaging Gateway) with SMTP id 18.7C.04270.F113C6C5; 

Below is the full error message.  Please advise if this can be reolved.  Many many thanks. 

Delivery has failed to these recipients or groups:

erogers@bradmer.com
Your message wasn’t delivered because the recipient’s email provider rejected it.

Diagnostic information for administrators:

Generating server: server-2.bemta.az-d.us-east-1.aws.symcld.net

erogers@bradmer.com
Remote Server returned ‘554 5.7.0 < #5.7.57 smtp; 530 5.7.57 SMTP; Client was not authenticated to send anonymous mail during MAIL FROM [BN6PR12CA0048.namprd12.prod.outlook.com]>’

Original message headers:

Return-Path: <george.gasson@bnymellon.com>

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bnymellon.com;

        s=BNY071018; t=1550594340; i=@bnymellon.com;

        bh=6CKn9+xMacgVsGmREMvRZd4vqsvhSI3dyrd8owANg1Y=;

        h=From:Subject:Date:Message-ID:Content-Type:MIME-Version:To;

        b=hDVm3hyZkP8nMSAIMHRKbKCHkfVy5CuolxDZMQgfL5c0ZG/8kPeRB5s6iGJy17ny0

        rSvDe2KQlABFBoFpw5do1kJCAOY2zSl7T6CL8bme4Z1HPDQwc1jyGojWI7R+8JO839

        lv8ZXnqSoW4gSfDH+WbyI6Jn1mX7Pq/LGTtJHXXn+Y0VcsI2e3WUUv9P7YcSCwWH53

        l1c87rxg1ZdCbNlL8DYi8j3IsU0jsrJNinG3z6NcF3jklLox0ngbGQtMjXY9TrVBjG

        sm5etZNEnqxZQeR380yZJWKQqc0/WvjttDEZsYB7rjr7cqwBv7wLiRyUvqSXKR1c4E

        ROsTtP5On/0Vw==

Received: from [67.219.247.54] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits))

        by server-2.bemta.az-d.us-east-1.aws.symcld.net id 4B/16-27512-4213C6C5; Tue, 19 Feb 2019 16:39:00 +0000

Authentication-Results: mx.messagelabs.com; spf=pass

  (server-29.tower-426.messagelabs.com: domain of bnymellon.com designates

  67.219.247.54 as permitted sender) smtp.mailfrom=bnymellon.com;

  dkim=none (message not signed); dmarc=none header.from=bnymellon.com

X-Brightmail-Tracker: H4sIAAAAAAAAA2VUe0xTdxT2d1+9IMXy0h+ELbPE7GU7cC47y8b

  ijHE3kC0LZiQ6oxZbabNSSFsmbMmCk7HBeIgQgQKF8X5GkOIEBIoPnmMghsFU3gWCCE7jY06B

  3XLBueyfk++c7zvfOecmv8uSrrUOXqwqyqjS6xRaKeNIVfhXn5D5+GkP+l4/7QCmxgEE46MXK

  VhOfUDCaE09Be02CwnTKfk0xD48Q8CfkxYG+lqsNKwMt9KQUmSjIXXwKg3t8cUkXH4wKII/ho

  Pgae9dBIkX8yiIyXwFruR5QsvVDhoqG7IRTJzspCF7cYyB/sk+CmYzx0hYav2OhNrZERLi0vx

  hfqaFghpLLQ0J/c8ouJdoFcGVLBMN15uLKWg+X4JguqMaQX9+G4LR8WYR9NSdoWDwUR4DdS0m

  ChbKlkQwP15FwoW/ykXw26W/CRjJshBwcrGQgIfTJgbi41cQzFTEELCUdwxKZ54gsHYskfDwa

  rUIOptvMDBcZmWge+FHAgZLivgri8YJSK1JJeBmRxfBf6YC/p65eBIscYnMLiWXXmAjuZqnY4

  gbayoXce0lrSTXOeTCdY7EkFzS3DLBxa40iriaqbM0l/WDmeTSpnIQZy18SnIZyc00d/1+C8U

  lxjfS3EzsPPHZtgO0RhcSHnWEVncV6yLMxSgqp6mejEF9GSgBObBYshM3Fw5TCciRdZW0Efhu

  kpkRkssI9zZlEELyDOEnifMiITnHMyeshL2f4ftrkstWvdwkcjz+u13kwLpL3sbnJ6sJAcvxY

  Osdvs6ylGQbHur/2F4WSz7Ad2qnSTtGks34cXfVqpyUbME3bHmEsJ47nrjWwwjYA89NLdMC9s

  EdxWWUoP8W19fdIwVPF9yVZaOEsd4481Teaq+r5DWcZR5a83kZV5+9R9tvwZLTG7HtRAF9Cm0

  2vTDb9IKv6QVfoX4U30oaYwS8Hec33V/Db+KSn+fJdfyrdYr4f307rhtoWPPZiuPis3mNI48L

  EW6qSiHWRXMLi/S6KP2nCVE+ElegnSF6TajaGKbQaGV+vr4yP78dsvdkfnLF1zKlPNIgUykMR

  nt63CA3RIcd1SrlOpXxHOIfqDLCAV1AltLQS8iTJaQe4szXtQddnUPCldFqhUF9WB+pVRkuIW

  +WlWLxbl+ec9GrQlVRxzRa/pWv05h1krqLx+202BChCDNoQgWqGwWyDY8nckm2azUm187w0TJ

  mj42rcbRtNpd0pXThOpXXFvFHdguJ3UIdqXs+YP1PMoBe8nITow0bNrg6Raj0YRrjf/nbaAuL

  pG7Cnk4anfH5Hrf5FQl+RdPKl/YVjYp/Ka8YlNx7oPf9gMGQPTnKkMmSQJ+iykMb31pxf8f8f

  blNseMrj0/V3p8776UOffLL8eTgrVB+q+dm+iNiVLn/m1mb/yZ9256gRbiWG8080zq+OyIrjS

  rb3V8bLJIu9Kk/rMoMIKdUQQEe+5zLX927b1e/T4X8sH9gZ3Bw36aiI5VfeJrTdu2XUga1wu8

  NUm9Q/ANRxQlcRAUAAA==

X-Env-Sender: george.gasson@bnymellon.com

X-Msg-Ref: server-29.tower-426.messagelabs.com!1550594311!2056042!25

X-Originating-IP: [170.61.173.129]

X-SYMC-ESS-Client-Auth: outbound-route-from=pass

X-StarScan-Received:

X-StarScan-Version: 9.31.5; banners=bnymellon.com,-,bradmer.com

Received: (qmail 8740 invoked from network); 19 Feb 2019 16:38:59 -0000

Received: from znpcpapbrg01o.bnymellon.com (HELO znpcpapbrg01i.bnymellon.com) (170.61.173.129)

  by server-29.tower-426.messagelabs.com with DHE-RSA-AES256-GCM-SHA384 encrypted SMTP; 19 Feb 2019 16:38:59 -0000

X-AuditID: 0aa06eb7-ff3ff700000010ae-64-5c6c311ff12f

Received: from WTPCPHTMEM02.ams.bnymellon.net (wtpcphtmem02.ams.bnymellon.net [160.254.249.175])

        (using TLS with cipher AES128-SHA (128/128 bits))

        (Client did not present a certificate)

        by znpcpapbrg01i.bnymellon.com (Symantec Messaging Gateway) with SMTP id 18.7C.04270.F113C6C5; Tue, 19 Feb 2019 11:38:55 -0500 (EST)

Received: from WTPCPEXMEM50.ams.bnymellon.net (10.88.250.171) by

WTPCPHTMEM02.ams.bnymellon.net (160.254.249.175) with Microsoft SMTP Server

(TLS) id 14.3.408.0; Tue, 19 Feb 2019 11:38:55 -0500

Received: from WTPCPEXMEM47.ams.bnymellon.net (10.88.250.168) by

WTPCPEXMEM50.ams.bnymellon.net (10.88.250.171) with Microsoft SMTP Server

(version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id

15.1.1531.3; Tue, 19 Feb 2019 11:38:54 -0500

Received: from WTPCPEXMEM47.ams.bnymellon.net ([10.88.250.168]) by

WTPCPEXMEM47.ams.bnymellon.net ([10.88.250.168]) with mapi id 15.01.1531.003;

Tue, 19 Feb 2019 11:38:54 -0500

From: “Gasson, George” <george.gasson@bnymellon.com>

Subject: Markets in review week ending 2/15/19

Thread-Topic: Markets in review week ending 2/15/19

Thread-Index: AdTIcZkQ+XuS/IPwQHKb7fmVvhjN7A==

Date: Tue, 19 Feb 2019 16:38:54 +0000

Message-ID: <ee9356a4afd54921b7587364d60ee53b@bnymellon.com>

Accept-Language: en-US

Content-Language: en-US

X-MS-Has-Attach: yes

X-MS-TNEF-Correlator:

x-originating-ip: [167.222.211.240]

Content-Type: text/plain

MIME-Version: 1.0

To: Undisclosed recipients:;

X-CFilter-Loop: Reflected NPC6

X-Brightmail-Tracker: H4sIAAAAAAAAA2WTa0ybZRTHfd5radb5DmF7xGVBdIm6UYduyUncjPGDe78YxUSNCwnr4N0l

        K6UpEwdG0wki7dgY2QK0ENpxE9iQIoVtsJYOgRaQAcOOOsO9BUkHygQncrPwQkLit98553/+

        55wneSRk8DwbJjmjOidoVAplBCOlpGZVXWR4lDLmQLr+WTA2PkAwMnSXgpWcORKGLPUUtHut

        JPiyzTSkz+cS8OeYlYEeu4OGVU8zDdmlXhpy3G00tOvKSPhpzs3Cr56PYLH7DwRZd00UaPPD

        odX0PNjbnDTcuFOAYDTNRUPBzDADvWM9FEzmD5Ow3PwNCbWTgyRkXD0C/gk7BRZrLQ363iUK

        ZrMcLLQajDT028oosDWUI/A5qxH0mu8hGBqxsdBVl0uB+28TA3V2IwXTFcss+EduknD7n0oW

        7rf8S8CgwUpA2kwJAfM+IwM63SqCiSotAcumk/D9xAICh3OZhPm2ahZctkcMeCocDHROZxLg

        Li8NXFk6QkCOJYeA35wdROCZigP3TOlIsGZkMe/E89eKvSRvWRxG/HBTJcu3lzeTvGtgB+8a

        1JL8pakVgk9fbWR5y3gNzRu+KyL5q+OFiHeULJJ83mUbzfc/sVN8lq6R5ifS/cSHe49JD8cL

        yjPJgub1t49LT7d39iO1qQKdL2yqJ7WoJw/pUZAEcwexrcRD6ZFUEsy1ErjeYybFoA3hbwvm

        kBisIlzz1y/sWkswZ0X4ln3PGjOBdsvlinWr5zg5HnnoX9eEcG/ihrFqQmQ5djc/DuQlEorb

        iwd6j66lZdxh/LjWR64x4nbip5031+Uktws/8poIcbsQPNrXxYgciqfGV2iRX8LOsor1rUlO

        i3C39iItmu7AHQYvJc7djfOvmBhx51ewoWhgw2gPrq6Zpa+gUOOWecatXsYtXqIoHnf5pwiR

        92Nz0xNG5H24/Lqf3OSfHePE//P7cd2DOxs+L+IMXcHGsDKEO39vR5uiqekZelN07eIoa0ay

        KhSWqlLHqRXqE5pTB6LkJ1QpCYJSmaiSxyUm/IjED3jrNhrNe7cFcRIUsU3moZQxwbQiOSkl

        oQW9HDAbs9zoRWGUKlElRITIoqSBsixekZIqaBJjNZ8rhaQW9IKEitglu278LCaYO6U4J5wV

        BLWg2awSkqAwLdJ1h+kbihZii79wGXuOedXPhA/fazv/1cclH3D1Lu7T+KfJZ/HS/diDDbPj

        ubYg+depF97q2x5tlO88Hlp56NK+aMOS+Yejvo6+hcaknpPbIj/pr+HeM+vnH7pS2PfjstyF

            8t2HYrZXDUyGgynywpeZr2a/saQ5MpdW5Bvodnozo2MiqKTTiqjXSE2S4j+oY7LtiA

0

Related:

  • No Related Posts

PVS Vdisk Inconsistency – Replication Status Shows Error ” Server Not Reachable” When NIC Teaming is Configured

  • Verify if NIC Teaming is configured as Active-Active. Reconfigure as Active-Passive.

Steps:

Open Network team configuration and make sure the team is Active Active.

Verify the NICs configured under Active Adaptors and confirm no Standby Adaptors are configured.

Reconfigure the Team and make sure Active and standby adaptors are configured.

Please note that NIC team configuration will differ for different adapter manufacturers, check the configuration guide to follow appropriate steps to reconfigure.

Reconfigure NIC teaming may interrupt the network connection. Please make sure to take proper actions to avoid production impact.


User-added image

  • Verify the MTU setting of NIC on all PVS servers

Since the status of the replication is synced via UDP on PVS port 6895, the communication failure over this udp port will also effects the status of the replications.

The different MTU of the NICs of PVS servers will also block this kind of UDP communication between them. For example, if one of the NIC has MTU of 1500(default) and the other NIC has MTU of 6000, the udp packets which is larger than 1500 will be lost due to the different fragmentation. From MTU of 6000, the udp packet larger than 1500 but less than 6000, so it will not be fragmented. But the peer has MTU of 1500, so it is unable to accepted this packet and causing packet loss.

You need to check the MTU value of all PVS servers by command:

netsh interface ipv4 show subinterface

If MTUs are different on all PVS servers, please change it to the same value (The default value 1500 is recommended):

netsh interface ipv4 set subinterface “ Ethernet ” mtu=1500 store=persistent

Please replace Ethernet with the NIC name of your PVS server.

Related:

  • No Related Posts

Configure StorageZone Controller for TLS v1.2 Inbound Connections

Due to known vulnerabilities in older SSL/TLS protocols, administrators are looking to limit inbound connections to StorageZone Controllers to TLS v1.2. The following steps provide guidance on setting up your StorageZone Controller to accept TLS v1.2 connections as well as steps to configure ShareFile clients to communicate over TLS v1.2

Support is available as of StorageZones Controller v4.0 or higher. Validation was performed with an external-facing NetScaler configured with TLS v1.2 only for in-bound connections to the ContentSwitching vServer.

If protocols earlier than TLS v1.2 are disabled on the StorageZones Controller, all client software components that interact with the StorageZone must also support TLS v1.2. Windows sync clients require Microsoft .NET Framework 4.5.2 and registry updates to support TLS v1.2. Mac sync clients do not support TLSv1.2. See below for details on how to configure Windows sync machines to use TLS v1.2.​

Setup – NetScaler Configuration

At the Content Switch Virtual Server, modify SSL Parameters and enable TLS v1.2. You can also disable all other protocols.

User-added image

User-added image

ShareFile Windows Client Configuration

Requirements:

  1. .NET 4.5.2 or higher
  2. The following registry key(s) must be applied to your Windows client operating system in order for the .NET applications to communicate over TLS v1.2 outbound. A client OS restart is required

IMPORTANT: The following registry setting allows .NET 4.0 applications to use TLS v1.2. This setting will apply to all .NET 4 applications installed, so please use caution when applying to ensure there will be no impacts to any other applications.

[HKEY_LOCAL_MACHINESOFTWAREMicrosoft.NETFrameworkv4.0.30319]

SchUseStrongCrypto=dword:00000001

For 64-Bit systems, also include:

[HKEY_LOCAL_MACHINESOFTWAREWow6432NodeMicrosoft.NETFrameworkv4.0.30319]

SchUseStrongCrypto=dword:00000001

Tested Windows Operating Systems

  1. Windows 7 32-bit/64-bit
  2. Windows 8.1 32-bit/64-bit
  3. Windows 10 32-bit/64-bit

Tested Windows Clients

  1. ShareFile Sync Client for Windows
  2. ShareFile Outlook Plugin
  3. ShareFile Desktop App
  4. ShareFile Drive Mapper
  5. ShareFile PowerShell client

Tested ShareFile Mobile Clients

  1. iOS 8/9
  2. Windows 10 Metro
  3. Android 4.4.2, 5.0.2, 6

Tested Web Browsers

  1. IE 10 / 11 / Edge
  2. Chrome
  3. Firefox
  4. Safari

NetScaler Tested

  1. NetScaler 11.0 63.16


Not Supported

  1. ShareFile Sync for Mac
  2. Windows 8.1 Metro
  3. SFCLI

Related:

  • No Related Posts