Cisco SIP inspection based DoS attack

Foreword:


At the end of Oct, Cisco announced a vulnerability in its ASA OS and Firepower FTP running products.

The vulnerability is based on the SIP inspection code that handles SIP signaling packets.

The vulnerability:


The FW do inspection on protocols for various reasons, NAT fixup, added security, discovery of dynamic port connections and allowing traffic to pass via the firewall etc. The SIP inspection is part of the default Global Inspection Policy that is enabled on the device, meaning all firewalls with default configuration for inspection are affected.

A bombardment of a high-rate specifically crafted SIP requests can impact the firewall (high CPU load) and cause legitimate traffic to cease hence causing a Denial of Service.

There is currently no software updates from Cisco to address this vulnerability. All mitigation options are based on additional configuration and listed below

Affected Products:


  • Vulnerable Products

This vulnerability affects Cisco ASA Software Release 9.4 and later and Cisco FTD Software Release 6.0 and later on both physical and virtual appliances if SIP inspection is enabled and the software is running on any of the following Cisco products. Worth noticing is that SIP inspection is enabled by default


  • 3000 Series Industrial Security Appliance (ISA)
  • ASA 5500-X Series Next-Generation Firewalls
  • ASA Services Module for Cisco Catalyst 6500 Series Switches and Cisco 7600 Series Routers
  • Adaptive Security Virtual Appliance (ASAv)
  • Firepower 2100 Series Security Appliance
  • Firepower 4100 Series Security Appliance
  • Firepower 9300 ASA Security Module
  • FTD Virtual (FTDv)

NOTE: Older (EOL) Cisco ASA 5500 series are NOT affected (due to older code). Also the Virtual ASA (ASA 1000V) is not affected

Determining if your product is vulnerable:


Check your current running software versions

For ASA:

ciscoasa# show version | include Version

If version is above 8.4 then it is vulnerable

For Firepower FTD:

> show version

If version is above 6.0 then it is vulnerable

Is my firewall under attack?


During an active attack you will be able to see large number of connections coming to your firewall on port 5060 (traditional SIP port and the one the Cisco devices are listening to in order to perform the inspection).

The following command will show the current SIP connections, they will be listed as incomplete as the source of the DoS only actively bombards the firewall without closing the SIP connection.

show conn port 5060

Another useful command is:

show processes cpu-usage non-zero sorted

This will show you the current cpu usage per process. Typical high CPU values will be observed during the attack. A continuous exploit of this vulnerability will cause continues high-CPU and could cause the device to crash and reload itself

Another indicator of compromise for this attack is a sudden reload after a network slowdown and the presence of a crashfile

show crashinfo

After the device boots up again, the output of show crashinfo will show an unknown abort of the DATAPATH thread

Workaround (Mitigation):


There are several options, all limiting the allowance of these SIP packets to reach or overwhelm the device

1. Disable SIP inspection

Have SIP inspection only if you are actively using it. Our experience with SIP inspection is that usually it is not required (not all customers are doing SIP trunks from inside the organization to a IP Telephony provider in the cloud). Even if SIP is in use, most SIP providers would actively ask you to disable the SIP inspection as Cisco is slow on updating it comparing to how fast SIP protocol changes. SIP providers would ask you just to open specific port ranges and not rely on this inspection due to multiple reasons.

To disable SIP inspection, configure the following:

For Cisco ASA Software 
policy-map global_policy
 class inspection_default
  no inspect sip

For Cisco FTD Software Releases
configure inspection sip disable

Note: This command is issued from the FTD CLI.

2. Actively block IP address(es) of the attackers

You can always actively block (by ACL) the offending IP address that you are seeing via the show conn port 5060. You need also to clear the existing connection issuing clear conn address

Other option is the old shun command that blocks all traffic from certain source IP

shun

This does not survice a reload

3. Filter out based on the SIP attributes

Most observed attacks use an SIP attribute of Sent-by Address that is set to 0.0.0.0. That is not typical behavior for a valid SIP communication, the attack can also be confirmed by doing a packet capture and noticing the amount of packets arriving from a SIP address you are not expecting. You can read the packet captures, check for the Sent-by address and if values are set to 0.0.0.0 and previous methods of mitigation are not valid for your environment then you can proceed and implement this change

regex VIAHEADER “0.0.0.0”

policy-map type inspect sip P1
parameters
match message-path regex VIAHEADER
drop

policy-map global_policy
class inspection_default
no inspect sip
inspect sip P1

4. Rate limit all SIP traffic

Not a great option as that could also influence legitimate traffic, however SIP is the signaling protocol for setting up voip connections, so in nature it should not be very chatty.

You can use the Cisco MPF (Modular Policy Framework) to create a policy and match the SIP traffic and then set a rate limit on this traffic so it would not cause the high cpu spike. Configuration can vary here, so it needs to be done by an expert on product or an external capable consultant.

Yet another critical vulnerability found for Cisco devices

Foreword:


On the 29th of March a company that deals with security in embedded devices, called Embedi published their discovery about a critical vulnerability in most Cisco Switch devices (both running IOS and XE).

The vulnerability (CVE-2018-0171) is based on stack buffer overflow and is possible due to improper validation of packet data in Smart Install Client, a plug-and-play configuration and image-management feature that helps administrators to deploy (client) network switches easily. The service is running on TCP 4786, opened by default and listening when service is enabled (which is by default).

Yet again a new functionality that is meant for easier deployment and potential less operational costs during deployment poses a serious security risk. The vulnerability is deemed as critical because it gives complete access to the device or be used to do a DoS on the device, meaning it can crash the device. What makes the case even worse is that the Smart Install Client functionality is enabled by default.

Initially researchers believed that the vulnerability could only be used for attacks inside an enterprise network due to the communication ports usually not exposed to the Internet or to the fact that many of switch or other devices are only internal, because in a securely configured networks because the recommendation is that Smart Install technology participants should not be accessible through the Internet.

However during a short scan of the Internet, researchers detected over 250,000 vulnerable devices and 8,5 million devices that have a vulnerable port open.

Which Cisco devices are affected:


The vulnerability was proven to work on the following devices: Catalyst 4500 Supervisor Engines, Cisco Catalyst 3850 Series Switches, and Cisco Catalyst 2960 Series Switches.

  • Cisco Catalyst 4500 Supervisor Engine 6L-E
    • Cisco IOS 15.2.2E6 (Latest, Suggested)
      • cat4500e-entservicesk9-mz.152-2.E6.bin (23-DEC-2016)
  • Cisco Catalyst 2960-48TT-L Switch
    • Cisco IOS 12.2(55)SE11 (Suggested)
      • c2960-lanbasek9-mz.122-55.SE11.bin (18-AUG-2016)
    • Cisco IOS 15.0.2-SE10a (Latest)
      • c2960-lanbasek9-mz.150-2.SE10a.bin (10-NOV-2016)
  • Cisco Catalyst 3850-24P-E Switch
    • Cisco IOS-XE 03.03.05.SE
      • cat3k_caa-universalk9.SPA.03.03.05.SE.150-1.EZ5.bin (03-NOV-2014)

And here are all devices that may fall into the Smart Install Client type and can be considered potentially vulnerable:

  • Catalyst 4500 Supervisor Engines
  • Catalyst 3850 Series
  • Catalyst 3750 Series
  • Catalyst 3650 Series
  • Catalyst 3560 Series
  • Catalyst 2960 Series
  • Catalyst 2975 Series
  • IE 2000
  • IE 3000
  • IE 3010
  • IE 4000
  • IE 4010
  • IE 5000
  • SM-ES2 SKUs
  • SM-ES3 SKUs
  • NME-16ES-1G-P
  • SM-X-ES3 SKUs

Cisco’s reaction:


The original researchers reached Cisco with their finding before going public with it and the vendor had enough time to patch their software. Official releases after March have been patches against the vulnerability and available for download.

How does the attack work?


The attackers send a large number of very small requests from a high-bandwidth pipe behind ISP(s), that allow ip spoofing, destined at a large list of publicly accessible application servers. The attacker is spoofing the source IP on all these requests to the target public IP address. All servers are made to respond with much larger packets to the requests, wrongfully directing all that traffic towards the unsuspecting target. The idea is to cripple either the target server/device or to congest its internet pipe, both causing Denial of Service.

How to determine if your device is affected:


Issue the following command:

show vstack config

If the output shows that SmartInstall is enabled then proceed with the checks

Check your current running software versions

show version

Use a Cisco official tool to check the vulnerabilities on your Cisco IOS/XE via the following link:

https://tools.cisco.com/security/center/softwarechecker.x

General recommendations:


  • Do not expose unnecessary any communication channels (services/ports) to unsecure networks such as the internet. Keep your devices behind firewalls in order to reduce the potential attack service.
  • Remember to patch your systems regularly

Data Centre for Cisco Network Security

Memcached – Newest amplification attack out there

Data Centre for Cisco Network Security

History:

In the last months and years we have seen multiple DDoS attacks based on amplification techniques (DNS, NTP, Chargen, SSDP)

A new amplification attack was spotted in the last week of February (25th – 27th of February).

It is, by far, the strongest amplification attack we had and it is based on the Memcached protocol running on UDP port 11211.

Sources at CloudFlare state the attack reached 257Gbps.

Why the Memcached Protocol?

The answer is simple, it supports UDP which is stateless (which is necessary for amplification attacks), it lacks any form of authentication, and when it turns out it provides excellent ratio in amplification (the difference between the size of the trigger packet and the response).

Amplification ratio in the attack was around x10000 times but the protocol itself is capable of x51200.

The attack stats detected on CloudFlare show UDP datagrams with 1400B size. The number of packets peaked to 23Mpps which measures to the reported total 257Gbps of bandwidth. And that is a lot, it can cause very serious outages.

How does an amplification attack work and how it can be prevented?

To successfully lunch an amplification attack you need 3 components:

  1. Capability to spoof IP packets, meaning access to a high-bandwidth pipe on ISP that does not do a solid job in securing anti-spoofing
  2. Application/Protocol that is amplification friendly – UDP based, no authentication, protocol allowing large responses to be created based on small requests
  3. Reflector servers running a suitable protocol – These are servers that are reachable from Internet and that are going to respond to requests

How does the attack work?

The attackers send a large number of very small requests from a high-bandwidth pipe behind ISP(s), that allow ip spoofing, destined at a large list of publicly accessible application servers. The attacker is spoofing the source IP on all these requests to the target public IP address. All servers are made to respond with much larger packets to the requests, wrongfully directing all that traffic towards the unsuspecting target. The idea is to cripple either the target server/device or to congest its internet pipe, both causing Denial of Service.

How can Amp Attacks be prevented?

If any of the three components outlined above is not available, then there is no way to perform a successful Amplification attack.

Simple steps can make a bit difference.

  1. ISP should always adhere to the strict anti-spoofing rules and allow outbound traffic only from sources belonging to their IP ranges.
  2. Developers should think about security when creating new applications and protocols. UDP should be avoided unless low-latency is needed, and if UDP is used, the protocol should have some form of authentication and should never allow a reply to a request ratio bigger than 1. Meaning all replies should be smaller or equal to the request that generate them.
  3. Administrators should correctly “firewall” their servers and allow access to the services to whomever needs them; and not the whole Internet. Certain types of responses might be blocked from within the application or at Firewall level.

Related articles:

https://blog.cloudflare.com/memcrashed-major-amplification-attacks-from-port-11211/

Cyber-security breach at Equifax

Equifax cyber-security breach – lessons to be learned

Cyber-security breach at Equifax

As you probably know the Equifax (one of the three big credit bureaus in North America and UK) announced it was breached (discovered unauthorized access) on the 29th of July. So far, the predictions are that this leak of sensitive personal data impacts over 143 Million American, Canadian and British citizens.

What is a credit bureau? – an organization that makes money by gathering and compiling huge amount of data (personal and financial) about customers and selling it to 3rd party marketers with the purpose of being able to provide a credit score for a certain individual to prove that customers’ financial capability when obtaining credit.

Obviously, these incredibly detailed dossiers contain tons of sensitive information that could be used to impersonate a person for either financial gain or to cause harm.

Historically speaking, all credit bureaus have encountered problems keeping their sensitive information secure, Experian for example had a breach in 2015 which exposed data for over 15 Million people.

Analysis of the breach:

As investigation is on the way (after the detection of the breach in July, Equifax has hired a security company to investigate all details of the breach and the depth of the data leakage and to do proper forensics), there are few released details on what really happened. But what is known so far is very troubling and does not look good for Equifax cyber-security posture. The official statement from Equifax is that the attackers broke into the company’s systems by exploiting an application vulnerability and then gained access to certain files. No mention of the exact vulnerability used which facilitated the breach. The fact that there is no mention of zero-day vulnerability (unknown flow), which could in fact make Equifax less culpable and makes sense for them to highlight, means that the vulnerability was known, meaning that Equifax were not patching on time their internet accessible public services nor had properly configured advanced IPS or security control in place, both are a must when you operate with such highly sensitive data. Other security best practices were obviously not followed by allowing the attackers to get real data after breaching an internet edge service.

Mistakes made:

  1. A long delay in announcing the breach. This could be explained with the ongoing internal investigation but still the delay could have been used by hackers to their advantage to harm Equifax customers.
  2. Equifax reaction after the announcement

Equifax came up with a plan to offer some kind of post factum sense of security to its customers and announced a new portal (www.equifaxsecurity2017.com) where its customers might be able to check if their personal and financial information was amongst the ones that were stolen. However, this portal did not give any such information but usually it was either not working (gave System Unavailable message probably due to high load) or was experiencing certificate issues and hence has been blocked by many web security solutions (such as Cisco OpenDNS) or when they finally got it to work – was giving unclear information, a possible scheduled date for enrolling to another service (credit protection) called TrustedID. On top of that some security researchers have noticed that this output is being presented whether the customer presents real data (the portal asks for Last name and last 6 digits of social security number) or fake made up one. Seems this portal is nothing but an attention diversion from the real problem.

  1. Equifax had problems with the company security vision/leadership

Equifax until recently was looking to hire a vice president of security (they see that position to fulfil the role of a CISO). This position is vital for a company which possess such sensitive information and should not be left vacant. Cyber-security is a mindset and it takes time and persistence to be built. It should always come from the top positions in a large company and have the backing of top managers.

Lessons to learn:

Some simple cyber-security lessons to learn

  1. Know your assets and their value, this will give you an idea on how much you need to invest in protecting these assets
  2. Know the risks to your assets and what impact would a damage or leakage have on your company
  3. Have a strategy/vision that is supported and driven by top management
  4. Take action to put that strategy in place
  5. Have a plan in case of a breach, that would help you react and restore your positions, gain back trust from your customers and do proper analysis/forensics of the breach

More materials:

https://krebsonsecurity.com/2017/09/breach-at-equifax-may-impact-143m-americans/

Cisco Umbrella image

Cisco Umbrella – light, easy to deploy and powerful

Cisco Umbrella image

Cisco currently has multiple endpoint security solutions in place – CWS (Cloud Web Security / Scansafe), Umbrella (OpenDNS) and AMP for endpoints are prime examples. AMP is a different breed of endpoint protection, it relies heavily on detection based on heuristics and cloud sandboxing, where as CWS and OpenDNS both concentrate very strongly on making sure your Internet browsing is secure and save.

A bit of history behind the story: when Cisco acquired Scansafe and then sometime later OpenDNS, a lot of people were wondering why Cisco needs two products that have such a large overlap in functionality. At first CWS looked like it was going to last, it had a large customer base, was heavily pushed by Cisco Sales and managed to get a big boost from existing Cisco customers that needed protections for this security gap which was opened by remote/roaming employees.

OpenDNS with most of its customers using the free version seemed like an outsider. It could only detect things based on DNS and was not tunneling any traffic back to the cloud, so it seems like it is not going to be a valid corporate level endpoint protections tool. People underestimated the power of DNS. OpenDNS has something very valuable, via its free version, it had the ability to see a large percentage of worldwide DNS request and using its strong security team it provided a more universal and complete protections that focuses on more than just web browsing. Almost all internet communication is based on DNS, the use of static IPs has been greatly reduced for couple of reasons – for non-malicious users the DNS provides first ease of use and flexibility that static IPs could not, for malicious users – the use of static IPs proved to be unwise as IPs were very quickly blocked (blacklisted) by ISPs and security tools. The result of massive DNS use was that your DNS provider could actively see where your traffic is going and block it (monitoring and enforcement) for all applications (not only Web based).

It was clear Cisco would have to make a choice and I believe they have made the correct one – Cisco is moving forward with the Umbrella and retiring the CWS.

What is Umbrella?

In short, the paid version of OpenDNS, which can support and integrate with other Cisco Products.

How does it work?

It works by forwarding DNS request to OpenDNS servers, either by registering your public IP with Umbrella and forwarding your internal DNS to OpenDNS servers, or by setting your network equipment (DHCP) to directly give out OpenDNS servers for DNS usage, in case the company does not have own internal DNS servers. That secures devices within the offices of the company. For Roaming devices, Umbrella has a Roaming Client (a small agent installed on endpoints, supports Windows and MACs, with vision to support Linux in the future) that makes sure all DNS requests are forwarded to the OpenDNS cloud.

It is very important to note that Umbrella does not work like a traditional Web Proxy, it does not send the all user traffic to the cloud for inspection, it only works and makes decisions based on the information from the DNS requests from the client. User traffic is send for inspection to the cloud only for gray/risky domains (traffic to malicious ones is blocked straight away). Furthermore, this redirection of traffic works for both Agent and Agentless deployments by using the DNS reply to forward the traffic to the Umbrella Cloud proxy service called Umbrella Intelligent Proxy.

The result is a better user experience (instantaneous decision to allow and block traffic to majority of traffic based on good and bad domains), lower deployment complexity and lower operational costs.

How is it configured?

Umbrella is one of the easiest deployments we have seen. It has excellent documentation and simple steps to help you redirect your office traffic to the cloud and deploy Roaming clients to your endpoints. All the management is done via portal in the web (https://dashboard.umbrella.com/). It has a very simple and effective portal layout with intuitive access to both management entities (managed identities and policies) but also monitoring and reporting. A typical simple implementation of Umbrella can be done in a matter of hours, without the need of any on-premise hardware installations (except when AD integration is needed, a lightweight virtual server needs to be installed)

Does it support AD integration for enhanced user visibility?

Yes, it does, it needs a VA (Virtual Appliance, a lightweight virtual server running on either ESX or Hyper-V). The VA servers allows Umbrella to see internal information such as private IP addresses of users and further performs an AD integration with MS AD (servers as a connector) so Umbrella Dashboard can see AD names and be able to define policies based on groups and create reports that include clients AD username (very handy if you want to know who exactly is making all of these malicious outbound requests (such as Command and Control traffic et).

Can it block based on connections that do not use DNS?

Yes, it can, there is a functionality called IP Layer Enforcement that builds IPSEC tunnels to the Umbrella cloud and forward requests to it in case the connection has a suspicious (flagged as malicious) IP address. This is possible only if the client is using Roaming Agent (either the Umbrella one or Anyconnect one).

Does it have integration with other Cisco products?

Umbrella has a module for Anyconnect (Cisco Umbrella Roaming Security module is available for Anyconnect version 4.3 MR1 and newer), which means if the customer has Anyconnect already deployed, there is no need to install Umbrella Roaming Agent. Also, OpenDNS security team is now part of Cisco Talos so OpenDNS both feeds Talos with DNS information but also benefits from Talos to device either certain domain or IP address are deemed risky.

Does it support SSL decryption?

Yes, Umbrella supports SSL decryption so it can do deep inspection for traffic destined for risky/suspicious domains. The configuration of the SSL decryption is very straight-forward, administrators are prompted to download Umbrella (OpenDNS) certificated from the Dashboard and then these certificates need to be installed as trusted on endpoint machines. Next step is just to enable the SSL decryption.

Conclusion:

Umbrella provides enterprise level endpoint security with lower latency than traditional proxies, low capex and deployment costs.

References:

http://www.cisco.com/c/en/us/products/collateral/security/cloud-web-security/eos-eol-notice-c51-738244.html

https://support.umbrella.com/hc/en-us/articles/231246528-Umbrella-Intelligent-Proxy-FAQs

https://umbrella.cisco.com/products/features/intelligent-proxy

https://deployment-umbrella.readme.io/docs/1-introduction

https://deployment-umbrella.readme.io/docs/1-ad-integration-setup-overview

https://deployment-umbrella.readme.io/docs/anyconnect-umbrella-roaming-security-client-administrator-guide

Data Centre for Cisco Network Security

VTI VPNs introduced to Cisco ASA 9.7.x

Data Centre for Cisco Network Security

Virtual Private Networks constitute a hot topic in networking because they provide low cost and secure communications between sites (site-to-site VPNs) whilst improving productivity by extending corporate networks to remote users (remote access VPNs). Naturally the VPN technology is widely deployed on all internet edge devices and most ASAs.

Cisco is very proud of its VPN solutions. It’s one of the few vendors that support such a wide range of VPN technologies with so many features and flexibility. Cisco Routers and Cisco ASA Firewalls are the two types of devices that are used most often to build Cisco Virtual Private Networks.  Cisco has been very strict about the way its routers and firewalls should be used and what technologies are available to them – routers will do the full range of Site-To-Site of VPNs: Traditional (Policy-based) IPsec VPNs, but also GRE IPsec VPNs, DMVPNs, GET VPNs, and have limited capabilities for the remote access VPNs: IPsec and SSL based. However, the ASA is very different so far it could do just traditional policy based L2L IPsec VPN but will have the full functionality for remote based VPNs. The message was very clear, for large organization and ISP use Routers for remote access VPN and static traditional Site-to-Site use the ASAs.

Things changed, Cisco very recently introduced a new feature with its 9.7.x code in the VPN module of the ASA – the VTI (Virtual Tunnel Interface). VTI were long available in Cisco Routers but never in Cisco Firewalls but similar technologies (Route-Based VPNs) were available in most competitors and the demand for that features finally took effect on Cisco and they introduced it.

Now before understanding why VTI are so important we will do a quick comparison between the traditional Site-to-Site IPsec VPN (Policy Based VPNs) and the VTI (Route-Based VPNs)

Policy Based VPNs

They rely on static (policy based) configuration of the encryption domain (usually by ACLs) and do not pass multicasts, not great for dynamic routing and voice/video and other multicast applications and requires re-configuration on both sides if the networks that traverse the VPN should change. The configuration is quite complex involving many steps that need to be same or mirrored (encryption domains/ACL config) and that is prone to mistakes.

However, the benefits are that this is a well matured configuration process and the IPsec VPN is a IETF standard which means all vendors must implement it according to the specifications of the standard, hence in theory it should always work between in multivendor scenarios. This is important because the two main uses of L2L (Site-to-Site) VPNs is connecting same company sites over internet thus replacing more expensive intranets or connecting one company to another company/partner/provider of services over Internet in a secure manner. In that second case, there is a big chance that both companies will use different vendors for VPN devices.

Route-Based VPNs

A route-based VPN configuration uses Layer3 routed tunnel interfaces (either GRE based or VTI based) as the endpoints of the VPN. Instead of selecting a static subset of traffic to pass through the VPN tunnel using an Access List, all traffic passing through the special Layer3 tunnel interface is placed into the VPN. Therefore, you need to configure routing accordingly. Either a dynamic routing protocol (such as EIGRP or OSPF) or static routing must be configured to divert VPN traffic through the special Layer3 tunnel interface. That makes the selection of interesting traffic dynamic and you have the flexibility to perform changes and introduce new traffic to the VPN without redoing the VPN configuration (only by changing the routing so new traffic gets routed to the interface). Another benefit is that this type of VPN can pass multicast traffic thus allowing dynamic routing protocols and enabling multicast applications to work.

There are some limitation and considerations that need to be taken in mind. First VTI is a proprietary to Cisco technology, despite other vendors having similar route-based VPN technology, there is no guarantee these will work between each other. Also, the tunnel interface itself does not provide inherited security, IPsec protection is an add-on and needs to be configured on top for encryption/security of traffic.

Summary and conclusions:

Introducing VTIs in ASAs is a big step forward in making the firewall an even more versatile network edge device. The VTI capability to provide security and encryption on multicast traffic and its flexibility for tunneling the traffic via dynamic routing with zero reconfiguration on the VPN, means that any small or middle-sized organization with ASA on network edge can now benefit very strongly from that functionality and would not need to purchase additional hardware thus maximizing its return on investment value.

References:

Release notes:

http://www.cisco.com/c/en/us/td/docs/security/asa/asa97/release/notes/asarn97.html#ID-2172-00000128

Configuration:

http://www.cisco.com/c/en/us/td/docs/security/asa/asa97/configuration/vpn/asa-97-vpn-config/vpn-vti.html

What is Cisco Unified Threat Defense (FTD)?

Cisco has finally decided to merge its two major network security products – the ASA and FirePOWER. These two have been living on the same hardware (5500X) model for years now but they required separate management which increased the deployment and operational costs for a Cisco FirePOWER implementation. Now Cisco has decided to merge these two platforms by removing the logical separation in hardware and the full separation in software by creating a merged OS that combines the features of both worlds, hence lowering the time/costs for deployment and running.

A bit of History

Cisco is a major player in the Firewall Market since the PIX. With the introduction of the first gen ASA, the PIX was given a polish, new features (such as dynamic routing, QoS, new RFC based protocol inspections/fixup and a few more), but ASA’s were and still are a traditional stateful packet firewall positioned at the Internet Edge. The demands to introduce firewalls also in the DC drove the change from IP based object to Name based object and totally different way of doing NAT (including the introduction of the Any as interface) in versions 8.3+. Still the ASA was purely a stateful firewall and the IDS/IPS module that Cisco was offering was quite outdated in technology and had a less than excellent catch-rate. Cisco knew that and purchased the best IPS/IDS vendor out there – SourceFire.

Now Cisco had two flagmen in the network security and naturally decided to offer them as one box – hence the NX 5500X Firewalls were created, no modules needed, all you need to run both ASA and FirePOWER was an upgrade to SSD drives. However, the management, logging, operation of the ASA and FirePOWER was still independent – ASA was managed and monitored by either ASDM or CSM, where FirePOWER was using – FireSight (pre-version 6) and now FMC (Firepower Management Center). Most competitors (Palo Alto and Check Point) did not need nor have separate management platforms to configure their advanced Next-Gen capabilities and frankly speaking users/admins were not happy with having to do double amount of work to enable a Cisco Next Gen Firewall – interfaces, licensing, configuration, policies, monitoring etc.

In 2015 Cisco hinted about the concept of having one unified management OS that would combine the features of both FirePOWER and ASA. The FirePOWER was chosen as a base for that new image, so from day one the FTD image had almost a 100% of the FirePOWER functionality but a very small percentage of the ASA functionality. The first release (6.0) for testing and Cisco partners was in 2016 and then the FTP had about 20% of the features of the ASA – basic features of course were migrated first, but shockingly there was lack of some major features such as – HA, VPNs (both site-to-site and Anyconnect), dynamic routing protocols, virtualization/contexts, QoS.  A quick introduction of 6.0.1 and 6.1 introduced HA failover so the FTD was now ready to go public.

The Situation today

Latest version release early 2017 is 6.2.0

Cisco continued its work to close the gap between the current ASA and FTD functionality. New major functionality added: Clustering for ASA, Site-To-Site IPSec VPN with certificates (6.1 supported Site-to-Site VPN but only with Pre-Shared-Key), PKI support, SGT without Realm, Migration tool (from traditional ASA to FTD), REST API, Packet Tracer and Capture functionality.

On top of the migrated in 6.1 functionalities such as integrations with Cisco ISE, Threat Grip, on-box management for some model, the 6.2 is looking more and more enterprise ready (not only SOHO as the 6.0 and 6.1). Also, adding the tools for automated migration, the FTD becomes more easily available when doing migration. The user base is also enlarging quite quickly (good for discovering of bugs and security/stability issues).  Version 6.2.1 is just around the corner and will close the gap even further introducing the Anyconnect Remote Access functionality and many improvements/new features in NAT, Dynamic Routing, Multicast and QoS, HA, Site-To-Site VPN and interestingly an option for conversion back to ASA image.

This all points that soon there will be a major swift in the Cisco Security community and more and more clients will start using FTD. Naturally after break-point Cisco will start the phase out of the traditional ASA image (functionality gap will be in favor of the FTD) and clients will be forced to switch. Of course, that process will take time but why not be ahead of the curve?

Resources:

http://www.cisco.com/c/en/us/td/docs/security/firepower/620/relnotes/Firepower_System_Release_Notes_Version_620/new_features_and_functionality.html

Bad News VPN Users – SHA-1 is Dead!

The breakthrough

SHA-1 is dead, from a security point of view, but has been a long time coming. A combined research collaboration between CWI and Google, published a paper on 23th of February 2017 that proved deliberate collisions can be created for SHA-1 (Secure Hash Algorithm -1). The researchers managed to forge a PDF doc so I have the same SHA-1 value as completely different document (aka collision).

OK, why is that such a big deal?

Background information and the risk

Hash functions are widely used in the cryptography and hence in the VPN world. They are used to verify the presence of a piece of information on the other peer (for example a pre-shared-key) that matches perfectly with yours (that is authentication) and to confirm that data has not been tampered with during transit (integrity), hash functions are used in the Public Key Infrastructure to verify integrity and sign the certificates (aka to verify that certain a person with a certain name has a certain public key).

The ability for someone to create a forged data string so that it matches the computed hash of another data string nullifies the security and the idea of using hash functions in cryptography.

Widespread

SHA-1 is still widely used for integrity/signing in IPsec IKEv1 (and sometimes IKEv2) and some PKI still support it so there are a multitude of certificates using it.

Furthermore, why is that important for Cisco VPN users?

IPsec IKEv1 does not support newer SHA algorithms (SHA-2) and the predominance of IPsec VPN is still built on IKEv1.

Even if you are using IKEv2 there could also be hardware restrictions preventing you from using modern hash functions (SHA-2) – legacy Cisco ASA devices (5505, 5510, 5520, 5540, 5550) cannot support newer hash functions in hardware and Cisco has not implemented the functionality into their software.

Recommendations

If your company is using a VPN and you need to audit them then ensure they are not using SHA-1 anymore. For expert VPN Security advice, contact 4CornerNetworks today.

Sources of Information:

https://shattered.io/static/shattered.pdf

https://arstechnica.com/security/2017/02/at-deaths-door-for-years-widely-used-sha1-function-is-now-dead/

http://www.cisco.com/c/en/us/td/docs/security/asa/asa91/configuration/vpn/asa_91_vpn_config/vpn_ike.html#pgfId-1042794

Network Security

The Importance of Retrospective Network Security

Network Security

We are experiencing a new phase in our vision of network security. There is currently no quick fix solution, no 100% proof network security protection/prevention tool or product. There is always zero-day or purposely built (very focused, low spread) APT malware that current vendors are unable to detect at the time of the breach.

Hence total prevention is a myth.

Most of the current network security solutions offer only Point-In-Time detection/prevention. Namely they inspect the traffic when the traffic goes via the firewall and if they deem the traffic is clean  or unknown, at that exact time, they will allow it and forget about it. That could lead to malware passing through and being undetected for long periods of time. All vendors rely on intercepting the C&C communication to the botnet servers but not all malware uses such a centralized operation method so that cannot be considered a proven method of detection. That is why most of the vendors will apply their own sandboxing solution, namely send all files of unknown malware type to the cloud where they will be detonated in a controlled environment and the result of their execution will be deemed malicious or not by machines or sometimes humans. Upon discovery of malicious actions, the file is marked as malware and an update is shot out to all vendor appliances out there so they can intercept and drop such files. That process however takes time (typically more than 8 hours) and usually stops more than 96% of the malware spread (it depends on how quickly the different vendors discover that the file is malicious and how quickly the update is sent out) and that percentage was deemed high-enough for most companies.

What about that 4% though? I am sure any business owner would not like to be in this position and would like greater protection and value for their money. When a mere 4% can cause 100% of your security problems, you’re not protected.

Cisco is the only vendor in the NGFW market that currently has its vision also set on the retrospective side of the network security, the so-called After-The-Attack phase. Cisco uses the combination between Firepower and AMP for both network and endpoint to be able to provide threat context and to pinpoint the progress and spread of the malware in historical time so you will know exactly when and how the malware moved in your network, which hosts were infected so that you can immediately deploy mitigation techniques. First restrict the malware, block the effect of the malware and finally remove the malware that has already breached your network. Without this continuous analysis, the attack can run rampant on the network and it will be extremely difficult to determine the scope of the outbreak and the root cause or provide on-time/adequate response. Here is an example of such an event and how Firepower and AMP deal with it.

The following 4 simple steps represent how Firepower and Amp works with zero-day malware files:

  1. Unknown file gets downloaded to a client ip (1.2.3.4 for example) via http application with Firefox, the file is then allowed to reach the endpoint. The unknown file is sent to the cloud to be detonated and given a verdict.
  2. The Firepower tracks the movement/copying of the file within the network so it sees the file being propagated via any protocol at any time. For example, the file gets copied to another host 1.2.3.5 via SMB at 12:41 AM on the 1st of Dec 2016.
  3. Within 30min the same file gets replicated to 5 more devices within the internal range, all via SMB. The Firepower has a map of the file trajectory with hosts and timing of the movements.
  4. Two hours since the file was first seen, Cisco Security Intelligence Cloud had reached a verdict that the file in question is in fact malicious. From now on all Cisco AMP and Firepower enabled devices will drop that file upon encounter and alarm/log, but here comes the difference between Cisco and other vendors, namely the retrospective part. In our example, all future transfer of the files will be blocked and the file itself will be quarantined on all endpoints that have this file (requires AMP for endpoint), even more the administrators can leverage the trajectory map and verify the malicious file has been quarantined/removed and hosts have been remediated.

Abbreviations:

APT – Advanced Persistent Threats

C&C – Command and Control

NGFW – Next-Generation Firewall

Network Security, Cyber Security

8 Steps to Secure Your Organization against Cyber-Attacks

Network Security, Cyber Security

There is not a single industry anywhere in the world who are immune from the threat of some form of cyber-attack. Any attacks on your organization’s IT Network will be unpredictable in terms of the exact method of attack, but you can at least be poised to deflect and protect your company from such cyber-attacks with these 8 easy to follow steps.

1. Implement your CyberSecurity strategy from the top-down

Devise a security strategy, make sure Directors and Management understand the importance of your organization’s IT Network Security. The fundamental thing about security is knowing the risks involved and understanding what needs to be secured, namely what are your valuables/assets.

Only after a thorough risk assessment has been carried out can a proper security strategy then be formed and implemented. The importance of cyber-security should be something that senior management understands and supports, resulting in a top-down approach to implementation.

2. Create polices for the allocation of internal IT Resources

Once the importance of security issues is fully understood by management, organizations can then begin to create and implement polices on how to use, manage and allocate company resources to tackle cyber security.

It is vital to then develop and enforce policies and procedures for employees to follow, this will impact:

  • The allocation of company IT resources – allowed and prohibited expenditure
  • Change management procedures to be implemented across all IT systems and related policies
  • Reevaluate risk and security posture at regular intervals

3. Network Security

Have a network design with a strong focus on cyber-security. Segment your network on logical system based zones so you can isolate/segregate critical business systems and be able to apply network security controls to them – firewall/inspect traffic between those zones. Protect your Internet Edge but also internal traffic (east-west), cover the most used vectors of attack (email, web)

Pay special attention to wireless connectivity – use strong authentication based on individual credentials or personal certificates, strong encryption (AES) and proper guest/BYOD access. Plan carefully, home and remote users access – they should have equal security controls as users on corporate networks.

Have a central point for system monitoring (SIEM) that is integrated within your environment and provides a single point that holds all relative logs/events for your systems. Monitor your network/user activity with qualified staff. Fine tune your IPS systems to use relative to your network environment security rules/signatures and to produce relevant alarms. Act on the alarms promptly.

Secure both user/management and physical access to your network assets. Apply only secure configuration using the vendor/standard recommended best practices. Have a lifecycle policy in place – aka review/renew security controls/equipment at regular intervals. Finally, ensure you have an up to date network diagram with HLD/LLD documents.

4. Protect your endpoints/servers

Always use legitimately supported software and hardware. Create and maintain a policy for patching and updates – keep up to date with patches and security updates.

Devise and maintain a hardware and software repository – know what you have in your network. Centrally manage your endpoint from OS and software point of view. Limit user rights to make changes to endpoint security:

  • Never give normal users full access (admin)
  • Limit execution controls/change configuration
  • Create safe-lists of allowed software
  • Disable unnecessary services
  • Disable unnecessary peripheral devices and removable media access
  • Disable auto-run capability if removable media access is deemed necessary

Accessing sensitive information should be done in a secure manner – proper access controls should be in place – secure and robust authentication mechanisms, use two-factor authentication for sensitive access, encryption for data in transit and rest. Monitoring of how sensitive data is handled and transferred should also be in place.

Use endpoint protection mechanism (Anti-Virus, Anti-Spyware, Software, Firewalls) which support centralised management and can be integrated with your network security controls and monitoring tools. Regularly backup all important data in a safe manner (encrypt and secure data in rest in motion) – this mitigates the effects of ransomware attacks. In case of a breach, have a plan to restore normal network operations for different scenarios but also remember to include steps for gathering data for forensic investigations to take place in the aftermath.

5. Train your personnel

Users should be aware of the ideas behind the implementation of security

measures, what threats are out there and what should raise their suspicion – simple things like:

  • Non-solicited mails with strange hidden links – aka “Think before you click campaign”
  • File attachment with general but well-sounding names
  • Plugging/connecting unapproved media or personal devices into the network

Users should undergo training on:

  • How to handle sensitive information
  • Social Engineering training and be aware of the techniques used
  • Report any strange activities or security incidents

The training and development of personnel should be a continuous process not a one-off occurrence to ensure topics are relevant, minimise any potential threats and so staff training can be scaled.

6. Remote/Home Users controls

Access risks for remote corporate users and create a policy on how to mitigate their usage. Use strong/two-factor authentication. Educate remote users on the importance of security and how to work with all security control mechanisms without sacrificing productivity.

Create and regularly update manuals on how to use and configure different security controls (aka VPN Clients etc.) Have a support and escalation procedure in place – this is done so users can work with all security controls in place and do not try to circumvent them. Protect data in transit and rest. Use a common security build for all remote workers – more secure, easier to operate and troubleshoot.

7. Monitoring

We cannot stress enough on the importance of constant monitoring. No environment is bullet proof and buying best of breed products does not guarantee top level of security. There is a lot of factors in play in every complex environment that has many cogs and bolts. The only predictable aspect about security is the unpredictability of the threats they pose (for example the human factor or administrator laziness). A link as strong as its weakest chain. A company should concentrate on having all protection/prevention mechanisms in place but should never forget to have visibility and monitoring tools in place.

Detect attacks and abnormal behaviour – both from outside and inside attacks. React to attacks – in a timely response to stop the spread of damage, can ensure that the attack is blocked in the future and could assist with a forensic investigation. Account for activity – you should have a complete understanding of how systems run, and how data and information is being used by users. Only then will you be able to detect deviations from the norm and act on them.

8. Test, test and test!

The only way to really know your security level is protecting your organization, is to regularly test it!

Security tests should cover all parts of your environment and should be performed on procedures/processes, network equipment, endpoint systems and personnel.

  • Formal security audits that look at procedures and if they are being followed/enforced
  • Automated vulnerability assessments – usually performed every 2-3 months and done internally
  • Penetration tests – external annual security tests that usually give the most accurate information for the company’s security posture and effectiveness of all security measures deployed
  • Social engineering tests on personnel – attempts to get employees to discard sensitive information to none-authorised people either via phone or in person or to get physical access to company restricted areas.

Jargon Buster

  1. HLD – High Level Design
  2. LLD – Low Level Design
  3. IT – Information Technology
  4. IPS – Intrusion Prevention System
  5. SIEM – combination of the SIM (Security Information Management) and SEM (Security Event Management) abbreviations
  6. OS – Operating System
  7. AES – Advanced Encryption Standard
  8. BYOD – Bring Your Own Device
  9. Social Engineering – a method in Penetration Testing when the security experts are trying to exploit the human personality into giving out sensitive information that could lead to a breach in security

References:

https://www.ncsc.gov.uk/guidance/10-steps-cyber-security https://www.gov.uk/government/uploads/system/uploads/attachment_data/file/317481/Cyber_Essentials_Requirements.pdf