main

Attack MitigationDDoSDDoS Attacks

Is It Legal to Evaluate a DDoS Mitigation Service?

March 27, 2019 — by Dileep Mishra — 2

ddostesting-960x640.jpg

A couple of months ago, I was on a call with a company that was in the process of evaluating DDoS mitigation services to protect its data centers. This company runs mission critical applications and were looking for comprehensive coverage from various types of attacks, including volumetric, low and slow, encrypted floods, and application-layer attacks.

During the discussion, our team asked a series of technical questions related to their ISP links, types of applications, physical connectivity, and more. And we provided an attack demo using our sandbox lab in Mahwah.

Everything was moving along just fine until the customer asked us for a Proof of Concept (PoC), what most would consider a natural next step in the vendor evaluation process.

About That Proof of Concept…

How would you do a DDoS POC? You rack and stack the DDoS mitigation appliance (or enable the service if it is cloud based), set up some type of management IP address, configure the protection policies, and off you go!

Well, when we spoke to this company, they said they would be happy to do all of that–at their disaster recovery data center located within a large carrier facility on the east coast. This sent my antenna up and I immediately asked a couple of questions that would turn out to be extremely important for all of us: Do you have attack tools to launch DDoS attacks? Do you take the responsibility to run the attacks?  Well, the customer answered “yes” to both.

[You may also like: DDoS Protection Requires Looking Both Ways]

Being a trained SE, I then asked why they needed to run the PoC in their lab and if there was a way we could demonstrate that our DDoS mitigation appliance can mitigate a wide range of attacks using our PoC script. As it turned out, the prospect was evaluating other vendors and, to compare apples to apples (thereby giving all vendors a fair chance), were already conducting a PoC in their data center with their appliance.

We shipped the PoC unit quickly and the prospect, true to their word, got the unit racked and stacked, cabled up ready to go. We configured the device then gave them the green light to launch attacks.  And then the prospect told us to launch the attacks; that they didn’t have any attack tools.

A Bad Idea

Well, most of us in this industry do have DDoS testing tools, so what’s the big deal? As vendors who provide cybersecurity solutions, we shouldn’t have any problems launching attacks over the Internet to test out a DDoS mitigation service…right?

[You may also like: 8 Questions to Ask in DDoS Protection]

WRONG! Here’s why that’s a bad idea:

  • Launching attacks over the Internet is ILLEGAL. You need written permission from the entity being attacked to launch a DDoS attack. You can try your luck if you want, but this is akin to running a red light. You may get away with it, but if you are caught the repercussions are damaging and expensive.
  • Your ISP might block your IP address. Many ISPs have DDoS defenses within their infrastructure and if they see someone launching a malicious attack, they might block your access. Good luck sorting that one out with your ISP!
  • Your attacks may not reach the desired testing destination. Well, even if your ISP doesn’t block you and the FBI doesn’t come knocking, there might be one or more DDoS mitigation devices between you and the customer data center where the destination IP being tested resides. These devices could very well mitigate the attack you launch preventing you from doing the testing.

Those are three big reasons why doing DDoS testing in a production data center is, simply put, a bad idea. Especially if you don’t have a legal, easy way to generate attacks.

[You may also like: 5 Must-Have DDoS Protection Technologies]

A Better Way

So what are the alternatives? How should you do DDoS testing?

  • With DDoS testing, the focus should be on evaluating  the mitigation features – e.g. can the service detect attacks quickly, can it mitigate immediately, can it adapt to attacks that are morphing, can it report accurately on the attack it is seeing, and what is being mitigated, how accurate is the mitigation (what about false positives). If you run a DDoS PoC in a production environment, you will spend most of your resources and time on testing the connectivity and spinning the wheels on operational aspects (e.g. LAN cabling, console cabling, change control procedures, paperwork, etc.). This is not what you want to test; you want to test DDoS mitigation! It’s like  trying to test how fast a sports car can go on a very busy street. You will end up testing the brakes, but you won’t get very far with any speed testing.
  • Test things out in your lab. Even better, let the vendor test it in their lab for you. This will let both parties focus on the security features rather than get caught up with the headaches of logistics involved with shipping, change control, physical cabling, connectivity, routing etc.
  • It is perfectly legal to use test tools like Kali Linux, Backtrack etc. within a lab environment. Launch attacks to your heart’s content, morph the attacks, see how the DDoS service responds.
  • If you don’t have the time or expertise to launch attacks yourself, hire a DDoS testing service. Companies like activereach, Redwolf security or MazeBolt security do this for a living, and they can help you test the DDoS mitigation service with a wide array of customized attacks. This will cost you some money, but if you are serious about the deployment, you will be doing yourself a favor and saving future work.
  • Finally, evaluate multiple vendors in parallel. You can never do this in a production data center. However, in a lab you can keep the attacks and the victim applications constant, while just swapping in the DDoS mitigation service. This will give you an apples-to-apples comparison of the actual capabilities of each vendor and will also shorten your evaluation cycle.

Read “The Trust Factor: Cybersecurity’s Role in Sustaining Business Momentum” to learn more.

Download Now

Attack MitigationDDoSSecurity

DDoS Protection Requires Looking Both Ways

March 26, 2019 — by Eyal Arazi — 0

ddos-960x540.jpg

Service availability is a key component of the user experience. Customers expect services to be constantly available and fast-responding, and any downtime can result in disappointed users, abandoned shopping carts, and lost customers.

Consequently, DDoS attacks are increasing in complexity, size and duration. Radware’s 2018 Global Application and Network Security Report found that over the course of a year, sophisticated DDoS attacks, such as burst attacks, increased by 15%, HTTPS floods grew by 20%, and over 64% of customers were hit by application-layer (L7) DDoS attacks.

Some Attacks are a Two-Way Street

As DDoS attacks become more complex, organizations require more elaborate protections to mitigate such attacks. However, in order to guarantee complete protection, many types of attacks – particularly the more sophisticated ones – require visibility into both inbound and outbound channels.

Some examples of such attacks include:

Out of State Protocol Attacks: Some DDoS attacks exploit weaknesses in protocol communication processes, such as TCP’s three-way handshake sequence, to create ‘out-of-state’ connection requests, thereby drawing-out connection requests in order to exhaust server resources. While some attacks of this type, such as a SYN flood, can be stopped by examining the inbound channel only, others require visibility into the outbound channel, as well.

An example of this is an ACK flood, whereby attackers continuously send forged TCP ACK packets towards the victim host. The target host then tries to associate the ACK reply to an existing TCP connection, and if none such exists, it will drop the packet. However, this process consumes server resources, and large numbers of such requests can deplete system resources. In order to correctly identify and mitigate such attacks, defenses need visibility to both inbound SYN and outbound SYN/ACK replies, so that they can verify whether the ACK packet is associated with any legitimate connection request.

[You may also like: An Overview of the TCP Optimization Process]

Reflection/Amplification Attacks: Such attacks exploit asymmetric responses between the connection requests and replies of certain protocols or applications. Again, some types of such attacks require visibility into both the inbound and outbound traffic channels.

An example of such attack is a large-file outbound pipe saturation attack. In such attacks, the attackers identify a very large file on the target network, and send a connection request to fetch it. The connection request itself can be only a few bytes in size, but the ensuing reply could be extremely large. Large amounts of such requests can clog-up the outbound pipe.

Another example are memcached amplification attacks. Although such attacks are most frequently used to overwhelm a third-party target via reflection, they can also be used to saturate the outbound channel of the targeted network.

[You may also like: 2018 In Review: Memcache and Drupalgeddon]

Scanning Attacks: Large-scale network scanning attempts are not just a security risk, but also frequently bear the hallmark of a DDoS attack, flooding the network with malicious traffic. Such scan attempts are based on sending large numbers of connection requests to host ports, and seeing which ports answer back (thereby indicating that they are open). However, this also leads to high volumes of error responses by closed ports. Mitigation of such attacks requires visibility into return traffic in order to identify the error response rate relative to actual traffic, in order for defenses to conclude that an attack is taking place.

Server Cracking: Similar to scanning attacks, server cracking attacks involve sending large amounts of requests in order to brute-force system passwords. Similarly, this leads to a high error reply rate, which requires visibility into both the inbound and outbound channels in order to identify the attack.

Stateful Application-Layer DDoS Attacks: Certain types of application-layer (L7) DDoS attacks exploit known protocol weaknesses or order to create large amounts of spoofed requests which exhaust server resources. Mitigating such attacks requires state-aware bi-directional visibility in order to identify attack patterns, so that the relevant attack signature can be applied to block it. Examples of such attacks are low-and-slow and application-layer (L7) SYN floods, which draw-out HTTP and TCP connections in order to continuously consume server resources.

[You may also like: Layer 7 Attack Mitigation]

Two-Way Attacks Require Bi-Directional Defenses

As online service availability becomes ever-more important, hackers are coming up with more sophisticated attacks than ever in order to overwhelm defenses. Many such attack vectors – frequently the more sophisticated and potent ones – either target or take advantages of the outbound communication channel.

Therefore, in order for organizations to fully protect themselves, they must deploy protections that allow bi-directional inspection of traffic in order to identify and neutralize such threats.

Read “The Trust Factor: Cybersecurity’s Role in Sustaining Business Momentum” to learn more.

Download Now

Attack MitigationDDoSDDoS Attacks

What Do Banks and Cybersecurity Have in Common? Everything.

February 7, 2019 — by Radware — 0

bank-960x640.jpg

New cyber-security threats require new solutions. New solutions require a project to implement them. The problems and solutions seem infinite while budgets remain bounded. Therefore, the challenge becomes how to identify the priority threats, select the solutions that deliver the best ROI and stretch dollars to maximize your organization’s protection. Consultants and industry analysts can help, but they too can be costly options that don’t always provide the correct advice.

So how best to simplify the decision-making process? Use an analogy. Consider that every cybersecurity solution has a counterpart in the physical world. To illustrate this point, consider the security measures at banks. They make a perfect analogy, because banks are just like applications or computing environments; both contain valuables that criminals are eager to steal.

The first line of defense at a bank is the front door, which is designed to allow people to enter and leave while providing a first layer of defense against thieves. Network firewalls fulfill the same role within the realm of cyber security. They allow specific types of traffic to enter an organization’s network but block mischievous visitors from entering. While firewalls are an effective first line of defense, they’re not impervious. Just like surreptitious robbers such as Billy the Kid or John Dillinger, SSL/TLS-based encrypted attacks or nefarious malware can sneak through this digital “front door” via a standard port.

Past the entrance there is often a security guard, which serves as an IPS or anti-malware device. This “security guard,” which is typically anti-malware and/or heuristic-based IPS function, seeks to identify unusual behavior or other indicators that trouble has entered the bank, such as somebody wearing a ski mask or perhaps carrying a concealed weapon.

[You may also like: 5 Ways Malware Defeats Cyber Defenses & What You Can Do About It]

Once the hacker gets past these perimeter security measures, they find themselves at the presentation layer of the application, or in the case of a bank, the teller. There is security here as well. Firstly, authentication (do you have an account) and second, two-factor authentication (an ATM card/security pin). IPS and anti-malware devices work in
concert with SIEM management solutions to serve as security cameras, performing additional security checks. Just like a bank leveraging the FBI’s Most Wanted List, these solutions leverage crowd sourcing and big-data analytics to analyze data from a massive global community and identify bank-robbing malware in advance.

A robber will often demand access to the bank’s vault. In the realm of IT, this is the database, where valuable information such as passwords, credit card or financial transaction information or healthcare data is stored. There are several ways of protecting this data, or at the very least, monitoring it. Encryption and database
application monitoring solutions are the most common.

Adapting for the Future: DDoS Mitigation

To understand how and why cyber-security models will have to adapt to meet future threats, let’s outline three obstacles they’ll have to overcome in the near future: advanced DDoS mitigation, encrypted cyber-attacks, and DevOps and agile software development.

[You may also like: Agile, DevOps and Load Balancers: Evolution of Network Operations]

A DDoS attack is any cyber-attack that compromises a company’s website or network and impairs the organization’s ability to conduct business. Take an e-commerce business for example. If somebody wanted to prevent the organization from conducting business, it’s not necessary to hack the website but simply to make it difficult for visitors to access it.

Leveraging the bank analogy, this is why banks and financial institutions leverage multiple layers of security: it provides an integrated, redundant defense designed to meet a multitude of potential situations in the unlikely event a bank is robbed. This also includes the ability to quickly and effectively communicate with law enforcement. In the world of cyber security, multi-layered defense is also essential. Why? Because preparing for “common” DDoS attacks is no longer enough. With the growing online availability of attack tools and services, the pool of possible attacks is larger than ever. This is why hybrid protection, which combines both on-premise and cloud-based mitigation services, is critical.

[You may also like: 8 Questions to Ask in DDoS Protection]

Why are there two systems when it comes to cyber security? Because it offers the best of both worlds. When a DDoS solution is deployed on-premise, organizations benefit from an immediate and automatic attack detection and mitigation solution. Within a few seconds from the initiation of a cyber-assault, the online services are well protected and the attack is mitigated. However, on-premise DDoS solution cannot handle volumetric network floods that saturate the Internet pipe. These attacks must be mitigated from the cloud.

Hybrid DDoS protections aspire to offer best-of-breed attack mitigation by combining on-premise and cloud mitigation into a single, integrated solution. The hybrid solution chooses the right mitigation location and technique based on attack characteristics. In the hybrid solution, attack detection and mitigation starts immediately and automatically using the on-premise attack mitigation device. This stops various attacks from diminishing the availability of the online services. All attacks are mitigated on-premise, unless they threaten to block the Internet pipe of the organization. In case of pipe saturation, the hybrid solution activates cloud mitigation and the traffic is diverted to the cloud, where it is scrubbed before being sent back to the enterprise.

[You may also like: Choosing the Right DDoS Solution – Part IV: Hybrid Protection]

An ideal hybrid solution also shares essential information about the attack between on-premise mitigation devices and cloud devices to accelerate and enhance the mitigation of the attack once it reaches the cloud.

Inspecting Encrypted Data

Companies have been encrypting data for well over 20 years. Today, over 50% of Internet traffic is encrypted. SSL/TLS encryption is still the most effective way to protect data as it ties the encryption to both the source and destination. This is a double-edged sword however. Hackers are now leveraging encryption to create new, stealthy attack vectors for malware infection and data exfiltration. In essence, they’re a wolf in sheep’s clothing. To stop hackers from leveraging SSL/TLS-based cyber-attacks, organizations require computing resources; resources to inspect communications to ensure they’re not infected with malicious malware. These increasing resource requirements make it challenging for anything but purpose built hardware to conduct inspection.

[You may also like: HTTPS: The Myth of Secure Encrypted Traffic Exposed]

The equivalent in the banking world is twofold. If somebody were to enter wearing a ski mask, that person probably wouldn’t be allowed to conduct a transaction, or secondly, there can be additional security checks when somebody enters a bank and requests a large or unique withdrawal.

Dealing with DevOps and Agile Software Development

Lastly, how do we ensure that, as applications become more complex, they don’t become increasingly vulnerable either from coding errors or from newly deployed functionality associated with DevOps or agile development practices? The problem is most cyber-security solutions focus on stopping existing threats. To use our bank analogy again, existing security solutions mean that (ideally), a career criminal can’t enter a bank, someone carrying a concealed weapon is stopped or somebody acting suspiciously is blocked from making a transaction. However, nothing stops somebody with no criminal background or conducting no suspicious activity from entering the bank. The bank’s security systems must be updated to look for other “indicators” that this person could represent a threat.

[You may also like: WAFs Should Do A Lot More Against Current Threats Than Covering OWASP Top 10]

In the world of cyber-security, the key is implementing a web application firewall that adapts to evolving threats and applications. A WAF accomplishes this by automatically detecting and protecting new web applications as they are added to the network via automatic policy generation. It should also differentiate between false positives and false negatives. Why? Because just like a bank, web applications are being accessed both by desired legitimate users and undesired attackers (malignant users whose goal is to harm the application and/or steal data). One of the biggest challenges in protecting web applications is the ability to accurately differentiate between the two and identify and block security threats while not disturbing legitimate traffic.

Adaptability is the Name of the Game

The world we live in can be a dangerous place, both physically and digitally. Threats are constantly changing, forcing both financial institutions and organizations to adapt their security solutions and processes. When contemplating the next steps, consider the following:

  • Use common sense and logic. The marketplace is saturated with offerings. Understand how a cybersecurity solution will fit into your existing infrastructure and the business value it will bring by keeping yourorganization up and running and your customer’s data secure.
  • Understand the long-term TCO of any cyber security solution you purchase.
  • The world is changing. Ensure that any cyber security solution you implement is designed to adapt to the constantly evolving threat landscape and your organization’s operational needs.

Read “The Trust Factor: Cybersecurity’s Role in Sustaining Business Momentum” to learn more.

Download Now

Attack Types & VectorsDDoSDDoS Attacks

Top 3 Cyberattacks Targeting Proxy Servers

January 16, 2019 — by Daniel Smith — 0

Proxy-960x540.jpg

Today, many organizations are now realizing that DDoS defense is critical to maintaining an exceptional customer experience. Why? Because nothing diminishes load times or impacts the end user’s experience more than a cyberattack.

As a facilitator of access to content and networks, proxy servers have become a focal point for those seeking to cause grief to organizations via cyberattacks due to the fallout a successful assault can have.

Attacking the CDN Proxy

New vulnerabilities in content delivery networks (CDNs) have left many wondering if the networks themselves are vulnerable to a wide variety of cyberattacks. Here are five cyber “blind spots” that are often attacked – and how to mitigate the risks:

Increase in dynamic content attacks. Attackers have discovered that treatment of dynamic content requests is a major blind spot in CDNs. Since the dynamic content is not stored on CDN servers, all requests for dynamic content are sent to the origin’s servers. Attackers are taking advantage of this behavior to generate attack traffic that contains random parameters in HTTP GET requests. CDN servers immediately redirect this attack traffic to the origin—expecting the origin’s server to handle the requests. However, in many cases the origin’s servers do not have the capacity to handle all those attack requests and fail to provide online services to legitimate users. That creates a denial-of-service situation. Many CDNs can limit the number of dynamic requests to the server under attack. This means they cannot distinguish attackers from legitimate users and the rate limit will result in legitimate users being blocked.

SSL-based DDoS attacks. SSL-based DDoS attacks leverage this cryptographic protocol to target the victim’s online services. These attacks are easy to launch and difficult to mitigate, making them a hacker favorite. To detect and mitigate SSL-based attacks, CDN servers must first decrypt the traffic using the customer’s SSL keys. If the customer is not willing to provide the SSL keys to its CDN provider, then the SSL attack traffic is redirected to the customer’s origin. That leaves the customer vulnerable to SSL attacks. Such attacks that hit the customer’s origin can easily take down the secured online service.

[You may also like: SSL Attacks – When Hackers Use Security Against You]

During DDoS attacks, when web application firewall (WAF) technologies are involved, CDNs also have a significant scalability weakness in terms of how many SSL connections per second they can handle. Serious latency issues can arise. PCI and other security compliance issues are also a problem because they limit the data centers that can be used to service the customer. This can increase latency and cause audit issues.

Keep in mind these problems are exacerbated with the massive migration from RSA algorithms to ECC and DH-based algorithms.

Attacks on non-CDN services. CDN services are often offered only for HTTP/S and DNS applications.  Other online services and applications in the customer’s data center, such as VoIP, mail, FTP and proprietary protocols, are not served by the CDN. Therefore, traffic to those applications is not routed through the CDN. Attackers are taking advantage of this blind spot and launching attacks on such applications. They are hitting the customer’s origin with large-scale attacks that threaten to saturate the Internet pipe of the customer. All the applications at the customer’s origin become unavailable to legitimate users once the internet pipe is saturated, including ones served by the CDN.

[You may also like: CDN Security is NOT Enough for Today]

Direct IP attacks. Even applications that are served by a CDN can be attacked once attackers launch a direct hit on the IP address of the web servers at the customer’s data center. These can be network-based flood attacks such as UDP floods or ICMP floods that will not be routed through CDN services and will directly hit the customer’s servers. Such volumetric network attacks can saturate the Internet pipe. That results in degradation to application and online services, including those served by the CDN.

Web application attacks. CDN protection from threats is limited and exposes web applications of the customer to data leakage and theft and other threats that are common with web applications. Most CDN- based WAF capabilities are minimal, covering only a basic set of predefined signatures and rules. Many of the CDN-based WAFs do not learn HTTP parameters and do not create positive security rules. Therefore, these WAFs cannot protect from zero-day attacks and known threats. For companies that do provide tuning for the web applications in their WAF, the cost is extremely high to get this level of protection. In addition to the significant blind spots identified, most CDN security services are simply not responsive enough, resulting in security configurations that take hours to manually deploy. Security services are using technologies (e.g., rate limit) that have proven inefficient in recent years and lack capabilities such as network behavioral analysis, challenge-response mechanisms and more.

[You may also like: Are Your Applications Secure?]

Finding the Watering Holes

Waterhole attack vectors are all about finding the weakest link in a technology chain. These attacks target often forgotten, overlooked or not intellectually attended to automated processes. They can lead to unbelievable devastation. What follows is a list of sample watering hole targets:

  • App stores
  • Security update services
  • Domain name services
  • Public code repositories to build websites
  • Webanalytics platforms
  • Identity and access single sign-on platforms
  • Open source code commonly used by vendors
  • Third-party vendors that participate in the website

The DDoS attack on Dyn in 2016 has been the best example of the water-holing vector technique to date. However, we believe this vector will gain momentum heading into 2018 and 2019 as automation begins to pervade every aspect of our life.

Attacking from the Side

In many ways, side channels are the most obscure and obfuscated attack vectors. This technique attacks the integrity of a company’s site through a variety of tactics:

  • DDoS the company’s analytics provider
  • Brute-force attack against all users or against all of the site’s third-party companies
  • Port the admin’s phone and steal login information
  • Massive load on “page dotting”
  • Large botnets to “learn” ins and outs of a site

Read the “2018 C-Suite Perspectives: Trends in the Cyberattack Landscape, Security Threats and Business Impacts” to learn more.

Download Now

Attack Types & VectorsDDoSDDoS Attacks

2018 In Review: Memcache and Drupalgeddon

December 20, 2018 — by Daniel Smith — 0

AdobeStock_199421574-960x640.jpg

Attackers don’t just utilize old, unpatched vulnerabilities, they also exploit recent disclosures at impressive rates. This year we witnessed two worldwide events that highlight the evolution and speed with which attackers will weaponize a vulnerability: Memcache and Druppalgeddon.

Memcached DDoS Attacks

In late February, Radware’s Threat Detection Network signaled an increase in activity on UDP port 11211. At the same time, several organizations began alerting to the same trend of attackers abusing Memcached servers for amplified attacks. A Memcached amplified DDoS attack makes use of legitimate third-party Memcached servers to send spoofed attack traffic to a targeted victim. Memcached, like other UDP-based services (SSDP, DNS and NTP), are Internet servers that do not have native authentication and are therefore hijacked to launch amplified attacks against their victims. The Memcached protocol was never intended to be exposed to the Internet and thus did not have sufficient security controls in place. Because of this exposure, attackers are able to abuse Memcached UDP port 11211 for reflective, volumetric DDoS attacks.

On February 27, Memcached version 1.5.6 was released which noted that UDP port 11211 was exposed and fixed the issue by disabling the UDP protocol by default. The following day, before the update could be applied, attackers leveraged this new attack vector to launch the world’s largest DDoS attack, a title previously held by the Mirai botnet.

There were two main concerns with regards to the Memcached vulnerability. The first is centered around the number of exposed Memcached servers. With just under 100,000 servers and only a few thousand required to launch a 1Tbps attack, the cause for concern is great. Most organizations at this point are likely unaware that they have vulnerable Memcached servers exposed to the Internet and it takes time to block or filter this service. Memcached servers will be vulnerable for some time, allowing attackers to generate volumetric DDoS attacks with few resources.

[You may also like: Entering into the 1Tbps Era]

The second concern is the time it took attackers to begin exploiting this vulnerability. The spike in activity was known for several days prior to the patch and publication of the Memcached vulnerability. Within 24 hours of publication, an attacker was able to build an amplification list of vulnerable MMemcached servers and launch the massive attack.

Adding to this threat, Defcon.pro, a notorious stresser service, quickly incorporated Memcache into their premium offerings after the disclosure. Stresser services are normally quick to utilize the newest attack vector for many reasons. The first reason being publicity. Attackers looking to purchase DDoS-as-a-service will search for a platform offering the latest vectors. Including them in a service shows demand for the latest vectors. In addition, an operator might include the Memcache DDoS-as-a-service so they can provide their users with more power. A stresser service offering a Memcache DDoS-as-a-service will likely also attract more customers who are looking for volume and once again plays into marketing and availability.

[You may also like: The Rise of Booter and Stresser Services]

DDoS-as-a-service operators are running a business and are currently evolving at rapid rates to keep up with demand. Oftentimes, these operators are using the public attention created by news coverage similar to extortionists. Similarly, ransom denial-of-service (RDoS) operators are quick to threaten the use of new tools due to the risks they pose. DDoS-as-a-service will do the same, but once the threat is mitigated by security experts, cyber criminals will look for newer vectors to incorporate  into their latest toolkit or offerings.

This leads into the next example of Drupalgeddon campaign and how quickly hacktivists incorporated this attack vector into their toolkit for the purpose of spreading messages via defacements.

Drupalgeddon

In early 2018, Radware’s Emergency Response Team (ERT) was following AnonPlus Italia, an Anonymous-affiliated group that was engaged in digital protests throughout April and May. The group–involved in political hacktivism as they targeted the Italian government–executed numerous web defacements to protest war, religion, politics and financial power while spreading a message about their social network by abusing the content management systems (CMS).

On April 20, 2018 AnonPlus Italia began a new campaign and defaced two websites to advertise their website and IRC channel. Over the next six days, AnonPlus Italia would claim responsibility for defacing 21 websites, 20 of which used the popular open-source CMS Drupal.

[You may also like: Hacking Democracy: Vulnerable Voting Infrastructure and the Future of Election Security]

Prior to these attacks, on March 29, 2018, the Drupal security team released a patch for a critical remote code execution (RCE) against Drupal that allowed attackers to execute arbitrary code on unpatched servers as a result of an issue affecting multiple subsystems with default or common module configurations. Exploits for CVE-2018-7600 were posted to Github and Exploit-DB under the guise of education purposes only. The first PoC was posted to Exploit DB on April 13, 2018. On April 14, Legion B0mb3r, a member of the Bangladesh-based hacking group Err0r Squad, posted a video to YouTube demonstrating how to use this CVE-2018-7600 to deface an unpatched version of Drupal. A few days later, on April 17, a Metasploit module was also released to the public.

In May, AnonPlus Italia executed 27 more defacements, of which 19 were Drupal.

Content management systems like WordPress and Joomla are normally abused by Anonymous hacktivists to target other web servers. In this recent string of defacements, the group AnonPlus Italia is abusing misconfigured or unpatched CMS instances with remote code exploits, allowing them to upload shells and deface unmaintained websites for headline attention.

Read “Radware’s 2018 Web Application Security Report” to learn more.

Download Now

DDoSDDoS AttacksSecurityWAF

What Can We Learn About Cybersecurity from the Challenger Disaster? Everything.

December 5, 2018 — by Radware — 0

AdobeStock_115308434-960x640.jpg

Understanding the potential threats that your organization faces is an essential part of risk management in modern times. It involves forecasting and evaluating all the factors that impact risk. Processes, procedures and investments can all increase, minimize or even eliminate risk.

Another factor is the human element. Often times, within an organization, a culture exists in which reams of historical data tell one story, but management believes something entirely different. This “cognitive dissonance” can lead to an overemphasis and reliance on near-term data and/or experiences and a discounting of long-term statistical analysis.

Perhaps no better example of this exists than the space shuttle Challenger disaster in 1986, which now serves as a case study in improperly managing risk. In January of that year, the Challenger disintegrated 73 seconds after launch due to the failure of a gasket (called an O-ring) in one of the rocket boosters. While the physical cause of the disaster was caused by the failure of the O-ring, the resulting Rogers Commission that investigated the accident found that NASA had failed to correctly identify “flaws in management procedures and technical design that, if corrected, might have prevented the Challenger tragedy.”

Despite strong evidence dating back to 1977 that the O-ring was a flawed design that could fail under certain conditions/temperatures, neither NASA management nor the rocket manufacturer, Morton Thiokol, responded adequately to the danger posed by the deficient joint design. Rather than redesigning the joint, they came to define the problem as an “acceptable flight risk.” Over the course of 24 preceding successful space shuttle flights, a “safety culture” was established within NASA management that downplayed the technical risks associated with flying the space shuttle despite mountains of data, and warnings about the O-ring, provided by research and development (R & D) engineers.

As American physicist Richard Feynman said regarding the disaster, “For a successful technology, reality must take precedence over public relations, for nature cannot be fooled.”

Truer words have never been spoken when they pertain to cybersecurity. C-suite executives need to stop evaluating and implementing cybersecurity strategies and solutions that meet minimal compliance and establish a culture of “acceptable risk” and start managing to real-world risks — risks that are supported by hard data.

Risk Management and Cybersecurity

The threat of a cyberattack on your organization is no longer a question of if, but when, and C-suite executives know it. According to C-Suite Perspectives: Trends in the Cyberattack Landscape, Security Threats and Business Impacts, 96% of executives were concerned about network vulnerabilities and security risks resulting from hybrid computing environments. Managing risk requires organizations to plan for and swiftly respond to risks and potential risks as they arise. Cybersecurity is no exception. For any organization, risks can be classified into four basic categories:

The Challenger disaster underscores all four of these risk categories. Take strategic risk as an example. Engineers from Morton Thiokol expressed concerns and presented data regarding the performance of the O-rings, both in the years prior and days leading up to the launch, and stated the launch should be delayed. NASA, under pressure to launch the already delayed mission and emboldened by the 24 preceding successful shuttle flights that led them to discount the reality of failure, pressured Morton Thiokol to supply a different recommendation. Morton Thiokol management decided to place organizational goals ahead of safety concerns that were supported by hard data. The recommendation for the launch was given, resulting in one of the most catastrophic incidents in manned space exploration. Both Morton Thiokol and NASA made strategic decisions that placed the advancements of their respective organizations over the risks that were presented.

[You may also like: The Million-Dollar Question of Cyber-Risk: Invest Now or Pay Later?]

This example of strategic risk serves as a perfect analogy for organizations implementing cybersecurity strategies and solutions. There are countless examples of high-profile cyberattacks and data breaches in which upper management was warned in advance of network vulnerabilities, yet no actions were taken to prevent an impending disaster. The infamous 2018 Panera Bread data breach is one such example. Facebook is yet another. Its platform operations manager between 2011 and 2012 warned management at the social tech giant to implement audits or enforce other mechanisms to ensure user data extracted from the social network was not misused by third-party developers and/or systems. These warnings were apparently ignored.

So why does this continually occur? The implementation of DDoS and WAF mitigation solutions often involves three key components within an organization: management, the security team/SOC and compliance. Despite reams of hard data provided by a security team that an organization is either currently vulnerable or not prepared for the newest generation of attack vectors, management will often place overemphasis on near-term security results/experiences; they feel secure in the fact that the organization has never been the victim of a successful cyberattack to date. The aforementioned Facebook story is a perfect example: They allowed history to override hard data presented by a platform manager regarding new security risks.

Underscoring this “cognitive dissonance” is the compliance team, which often seeks to evaluate DDoS mitigation solutions based solely on checkbox functionality that fulfills minimal compliance standards. Alternatively, this strategy also drives a cost-savings approach that yields short-term financial savings within an organization that often times views cybersecurity as an afterthought vis-à-vis other strategic programs, such as mobility, IoT and cloud computing.

The end result? Organizations aren’t managing real-world risks, but rather are managing “yesterday’s” risks, thereby leaving themselves vulnerable to new attack vectors, IoT botnet vulnerabilities, cybercriminals and other threats that didn’t exist weeks or even days ago.

The True Cost of a Cyberattack

To understand just how detrimental this can be to the long-term success of an organization requires grasping the true cost of a cyberattack. Sadly, these data points are often as poorly understood, or dismissed, as the aforementioned statistics regarding vulnerability. The cost of a cyberattack can be mapped by the four risk categories:

  • Strategic Risk: Cyberattacks, on average, cost more than one million USD/EUR, according to 40% of executives. Five percent estimated this cost to be more than 25 million USD/EUR.
  • Reputation Risk: Customer attrition rates can increase by as much as 30% following a cyberattack. Moreover, organizations that lose over four percent of their customers following a data breach suffer an average total cost of $5.1 million. In addition, 41% of executives reported that customers have taken legal action against their companies following a data breach. The Yahoo and Equifax data breach lawsuits are two high-profile examples.
  • Product Risk: The IP Commission estimated that counterfeit goods, pirated software and stolen trade secrets cost the U.S. economy $600 billion annually.
  • Governance Risk: “Hidden” costs associated with a data breach include increased insurance premiums, lower credit ratings and devaluation of trade names. Equifax was devalued by $4 billion by Wall Street following the announcement of its data breach.

[You may also like: Understanding the Real Cost of a Cyber-Attack and Building a Cyber-Resilient Business]

Secure the Customer Experience, Manage Risk

It’s only by identifying the new risks that an organization faces each and every day and having a plan in place to minimize them that enables its executives to build a foundation upon which their company will succeed. In the case of the space shuttle program, mounds of data that clearly demonstrated an unacceptable flight risk were pushed aside by the need to meet operational goals. What lessons can be learned from that fateful day in January of 1986 and applied to cybersecurity? To start, the disaster highlights the five key steps of managing risks.

In the case of cybersecurity, this means that the executive leadership must weigh the opinions of its network security team, compliance team and upper management and use data to identify vulnerabilities and the requirements to successfully mitigate them. In the digital age, cybersecurity must be viewed as an ongoing strategic initiative and cannot be delegated solely to compliance. Leadership must fully weigh the potential cost of a cyberattack/data breach on the organization versus the resources required to implement the right security strategies and solutions. Lastly, when properly understood, risk can actually be turned into a competitive advantage. In the case of cybersecurity, it can be used as a competitive differentiator with consumers that demand fast network performance, responsive applications and a secure customer experience. This enables companies to target and retain customers by supplying a forward-looking security solution that seamlessly protects users today and into the future.

So how are executives expected to accomplish this while facing new security threats, tight budgets, a shortfall in cybersecurity professionals and the need to safeguard increasingly diversified infrastructures? The key is creating a secure climate for the business and its customers.

To create this climate, research shows that executives must be willing to accept new technologies, be openminded to new ideologies and embrace change, according to C-Suite Perspectives: Trends in the Cyberattack Landscape, Security Threats and Business Impacts. Executives committed to staying on top of this ever-evolving threat must break down the silos that exist in the organization to assess the dimensions of the risks across the enterprise and address these exposures holistically. Next is balancing the aforementioned investment versus risk equation. All executives will face tough choices when deciding where to invest resources to propel their companies forward. C-suite executives must leverage the aforementioned data points and carefully evaluate the risks associated with security vulnerabilities and the costs of implementing effective security solutions to avoid becoming the next high-profile data breach.

According to the same report, four in 10 respondents identified increasing infrastructure complexity, digital transformation plans, integration of artificial intelligence and migration to the cloud as events that put pressure on security planning and budget allocation.

The stakes are high. Security threats can seriously impact a company’s brand reputation, resulting in customer loss, reduced operational productivity and lawsuits. C-suite executives must heed the lessons of the space shuttle Challenger disaster: Stop evaluating and implementing cybersecurity strategies and solutions that meet minimal compliance and start managing to real-world risks by trusting data, pushing aside near-term experiences/“gut instincts” and understanding the true cost of a cyberattack. Those executives who are willing to embrace technology and change and prioritize cybersecurity will be the ones to win the trust and loyalty of the 21st-century consumer.

Read the “2018 C-Suite Perspectives: Trends in the Cyberattack Landscape, Security Threats and Business Impacts” to learn more.

Download Now

DDoSSecurity

Disaster Recovery: Data Center or Host Infrastructure Reroute

October 11, 2018 — by Daniel Lakier — 3

disaster-recovery-data-center-host-infrastructure-reroute-blog-960x540.jpg

Companies, even large ones, haven’t considered disaster recovery plans outside of their primary cloud providers own infrastructure as regularly as they should. In March of this year, Amazon Web Services (AWS) had a massive failure which directly impacted some of the world’s largest brands, taking them offline for several hours. In this case, it was not a malicious attack but the end result was the same— an outage.

When the organization’s leadership questioned their IT departments on how this outage could happen, most received an answer that was somehow acceptable:  It was AWS. Amazon failed, not us. However, that answer should not be acceptable.

AWS implies they are invulnerable, but the people running IT departments are running it for a reason. They are meant to be skeptics, and it is their job to build redundancies that protect the system against any one point of failure.  Some of those companies use AWS disaster recovery services, but if the data center and all the technology required to turn those fail-safes on crashes, then you’re down. This is why we need to treat the problem with the same logic that we use for any other system. Today it is easier than ever to create a resilient DoS resistant architecture that not only takes traditional malicious activity into account but also critical business failures. The solution isn’t purely technical either, it needs to be based upon sound business principles using readily available technology.

[You might also like: DDoS Protection is the Foundation for Application, Site and Data Availability]

In the past enterprise disaster recovery architecture revolved around having a fully operational secondary location. If we wanted true resiliency that was the only option. Today although that can still be one of the foundation pillars to your approach it doesn’t have to be the only answer. You need to be more circumspect about what your requirements are and choose the right solution for each environment/problem.  For example:

  • A) You can still build it either in your own data center or in a cloud (match the performance requirements to a business value equation).
  • B) Several ‘Backups-as-a-Service’ will offer more than just storage in the cloud. They offer resources for rent (servers to run your corporate environments in case of an outage). If your business can sustain an environment going down just long enough to turn it back on (several hours), this can be a very cost-effective solution.
  • C) For non-critical items, rely on the cloud provider you currently use to provide near-time failure protection.

The Bottom Line

Regardless of which approach you take, even if everything works flawlessly, you still need to address the ‘brownout’ phenomenon or the time it takes for services to be restored at the primary or to a secondary location. It is even more important to automatically send people to a different location if performance is impaired. Several people have heard of GSLB, and while many use it today, it is not part of their comprehensive DoS approach.  But it should be. If your goal with your DDoS mitigation solution is to ensure an uninterrupted service in addition to meeting your approved performance SLA; then dynamic GSLB or infrastructure based performance load balancing has to be an integral part of any design.

We can deploy this technology purely defensively, as we have traditionally done with all DoS investments or we change the paradigm and deploy the technology to help us exceed expectations. This allows us to give each individual user the best experience possible. Radware’s dynamic performance-based route optimization solution (GSLB) allows us to offer a unique customer experience to each and every user regardless of where they are coming from, how they access the environment or what they are trying to do. This same technology allows us to reroute users in the event of a DoS event that takes down an entire site be it from malicious behavior, hardware failure or simple human error. This functionality can be procured as a product or a service as it is environment/cloud agnostic and relatively simple to deploy. It is not labor intensive and may be the least expensive part of an enterprise DOS architecture.

What we can conclude is that any company that blames the cloud provider for a down site in the future should be asked the hard questions because solving this problem is easier today than ever before.

Read “Radware’s 2018 Web Application Security Report” to learn more.

Download Now

BotnetsDDoSSecurityWAF

Protecting Sensitive Data: A Black Swan Never Truly Sits Still

October 10, 2018 — by Mike O'Malley — 2

protecting-sensitive-data-never-sit-still-960x540.jpg

The black swan – a rare and unpredictable event notorious for its ability to completely change the tides of a situation.

For cybersecurity, these nightmares can take the form of disabled critical services such as municipal electrical grids and other connected infrastructure networks, data breaches, application failures, and DDoS attacks. They can range from the levels of Equifax’s 2018 Breach Penalty Fines (estimated close to $1.5 billion), to the bankruptcy of Code Spaces following their DDoS attack and breach (one of the 61% of SMBs companies that faced bankruptcy per service provider Verizon’s investigations), to a government-wide shutdown of web access in public servants’ computers in response to a string of cyberattacks.

Litigation and regulation can only do so much to reduce the impact of black swans, but it is up to companies to prepare and defend themselves from cyberattacks that can lead to rippling effects across industries.

[You might also like: What a Breach Means to Your Business]

If It’s So Rare, Why Should My Company Care?

Companies should concern themselves with black swans to understand the depth of the potential long-term financial and reputation damage and suffering. Radware’s research on C-Suite Perspectives regarding the relationship between cybersecurity and customer experience shows that these executives prioritize Customer Loss (41%), Brand Reputation (34%), and Productivity/Operational Loss (34%). Yet, a majority of these same executives have not yet integrated security practices into their company’s security infrastructure such as their application DevOps teams.

The long-term damage on a company’s finances is note-worthy enough. IT provider CGI found that for technology and financial companies alone, they can lose 5-8.5% in enterprise value from the breach. What often goes unreported, however, is the increased customer onboarding costs to combat against large-scale customer churn following breaches.

For the financial sector, global accounting firm KPMG found that consumers not only expect institutions to act quickly and take responsibility, but 48% are willing to switch banks due to lack of responsibility and preparation for future attacks, and untimely notification of the breaches. News publication The Financial Brand found that banking customers have an average churn rate of 20-40% in 12 months, while a potential onboarding cost per customer can be within the $300-$20,000 range. Network hardware manufacturer Cisco estimates as high as 20% of customers and opportunities could be lost.

Just imagine the customer churn rate for a recently-attacked company.

How does that affect me personally as a business leader within my company?

When data breaches occur, the first person that typically takes the blame is the CISO or CSO. A common misconception, however, is that everyone else will be spared any accountability. But the damage is not limited to just security leadership. Due to the wide array of impacts that result from a cyberattack, nearly all C-level executives are at risk; examples include but are not limited to Equifax’s CEO, Richard Smith, Target CEO Gregg Steinhafel and CIO Beth Jacob. This results in a sudden emptiness of C-Suite level employees. Suddenly, there’s a lack of leadership and direction, causing its own internal combination of instability.

Today’s business leaders need to understand that a data breach is no longer limited to the company’s reputation, but the level of welfare of its customers. Just the event of a data breach can shatter the trust between the two entities. CEOs are now expected to be involved with managing the black swan’s consequences; in times of these hardships, they are particularly expected to continue being the voice of the company and to provide direction and assurance to vulnerable customers.

A business leader can be ousted from the company for not having taken cybersecurity seriously enough and/or not understanding the true costs of a cyberattack – that is, if the company hasn’t filed for bankruptcy yet.

Isn’t this something that my company’s Public Relations department should be handling?

One of the biggest contributors to the aftermath chaos of a black swan is the poor/lack of communication from the public relations team. By not disclosing a data breach in a timely manner, companies incur the wrath of the consumer and suffer an even bigger loss in customer loyalty because of delays. A timely announcement is expected as soon as the company discovers the incident, or according to the GDPR, within 72 hours of the discovery.

A company and its CEO should not solely depend on their public relations department to handle a black swan nightmare. Equifax revealed its data breach six weeks after the incident and still hadn’t directly contacted those that were affected, instead of creating a website for customer inquiries. Equifax continues to suffer from customer distrust because of the lack of guidance from the company’s leadership during those critical days in 2017. At a time of confusion and mayhem, a company’s leader must remain forthcoming, reassuring and credible through the black swan’s tide-changing effects.

Following the cybersecurity black swan, a vast majority of consumers must also be convinced that all the security issues have been addressed and rectified, and the company has a plan in place for any future repeated incidents. Those that fail to do so are at risk of losing at least every 1 in 10 customers, exhibiting the potential reach of impact a black swan can have within a company alone, beyond financial aspects.

How Do You Prepare for When the Black Swan Strikes?

When it comes to the black swan, the strategic method isn’t limited to be proactive or reactive, but to be preemptive, according to news publication ComputerWeekly. The black swan is primarily feared for its unpredictability. The key advantage of being preemptive is the level of detail that goes into planning; instead of reacting in real-time during the chaos or having a universal one-size fits all type of strategy, companies should do their best to develop multiple procedures for multiple worst-case scenarios.

Companies cannot afford to be sitting ducks waiting for the black swan to strike, but must have prepared mitigation plans in place for the likelihood. The ability to mitigate through extreme cyber threats and emerging cyberattack tactics is a dual threat to the company, depending on the level of cybersecurity preparation a company possesses. By implementing a strong cybersecurity architecture (internal or third-party), companies can adapt and evolve with the constant-changing security threats landscape; thereby minimizing the opportunities for hackers to take advantage.

In addition to having a well-built security system, precautions should be taken to further strengthen it including WAF Protection, SSL Inspections, DDoS Protection, Bot Protection, and more. Risk management is flawed due to its nature of emphasis on internal risks only. What’s been missing is companies must do more to include the possibilities of industry-wide black swans, such as the Target data breach in 2013 that later extended to Home Depot and other retailers.

It’s Time To Protect Sensitive Data

In the end, the potential impact of a black swan on a company comes down to its business owners. Cybersecurity is no longer limited to a CISO or CSO’s decision, but the CEO. As the symbol and leader of a company, CEOs need to ask themselves if they know how their security model works. Is it easily penetrated? Can it defend against massive cyberattacks?  What IP and customer data am I protecting?  What would happen to the business if that data was breached?

Does it protect sensitive data?

Read “Radware’s 2018 Web Application Security Report” to learn more.

Download Now

Attack Types & VectorsBotnetsDDoSSecurity

The Evolution of IoT Attacks

August 30, 2018 — by Daniel Smith — 12

iot_botnet_emerge-960x636.jpg

What is the Internet of Things (IoT)? IoT is the ever-growing network of physical devices with embedded technologies that connect and exchange data over the internet. If the cloud is considered someone else’s computer, IoT devices can be considered the things you connect to the internet beyond a server or a PC/Laptop. These are items such as cameras, doorbells, light bulbs, routers, DVRs, wearables, wireless sensors, automated devices and just about anything else.

IoT devices are nothing new, but the attacks against them are. They are evolving at a rapid rate as growth in connected devices continues to rise and shows no sign of letting up. One of the reasons why IoT devices have become so popular in recent years is because of the evolution of cloud and data processing which provides manufacturers cheaper solutions to create even more ‘things’. Before this evolution, there weren’t many options for manufacturers to cost-effectively store and process data from devices in a cloud or data center.  Older IoT devices would have to store and process data locally in some situations. Today, there are solutions for everyone and we continue to see more items that are always on and do not have to store or process data locally.

[You might also like: The 7 Craziest IoT Device Hacks]

Cloud and Data Processing: Good or Bad?

This evolution in cloud and data processing has led to an expansion of IoT devices, but is this a good or a bad thing? Those that profit from this expansion would agree that this is positive because of the increase in computing devices that can assist, benefit or improve the user’s quality of life. But those in security would be quick to say that this rapid rise in connected devices has also increased the attack landscape as there is a lack of oversight and regulation of these devices. As users become more dependent on these IoT devices for daily actives, the risk also elevates. Not only are they relying more on certain devices, but they are also creating a much larger digital footprint that could expose personal or sensitive data.

In addition to the evolution of IoT devices, there has been an evolution in the way attacker’s think and operate. The evolution of network capabilities and large-scale data tools in the cloud has helped foster the expansion of the IoT revolution. The growth of cloud and always-on availability to process IoT data has been largely adopted among manufacturing facilities, power plants, energy companies, smart buildings and other automated technologies such as those found in the automotive industry. But this has increased the attack surfaces for those that have adopted and implemented an army of possible vulnerable or already exploitable devices. The attackers are beginning to notice the growing field of vulnerabilities that contain valuable data.

In a way, the evolution of IoT attacks continues to catch many off guard, particularly the explosive campaigns of IoT based attacks. For years, experts have warned about the pending problems of a connected future, with IoT botnets as a key indicator, but very little was done to prepare for it.  Now, organizations are rushing to identify good traffic vs malicious traffic and are having trouble blocking these attacks since they are coming from legitimate sources.

As attackers evolve, organizations are still playing catch up. Soon after the world’s largest DDoS attack, and following the publication of the Mirai source code, began a large battle among criminal hackers for devices to infect. The more bots in your botnet, the larger the attack could be.  From the construction of a botnet to the actual launch an attack, there are several warning signs of an attack or pending attack.

As the industry began monitoring and tracking IoT based botnets and threats, several non-DDoS based botnets began appearing. Criminals and operators suddenly shifted focus and began infecting IoT devices to mine for cryptocurrencies or to steal user data. Compared to ransomware and large-scale DoS campaigns that stem from thousands of infected devices, these are silent attacks.

Unchartered Territory

In addition to the evolving problems, modern research lacks standardization that makes analyzing, detecting and reporting complicated. The industry is new, and the landscape keeps evolving at a rapid rate causing fatigue in some situations. For instance, sometimes researchers are siloed, and research is kept for internal use only which can be problematic for the researcher who wants to warn of the vulnerability or advise on how to stop an attack. Reporting is also scattered between tweets, white papers, and conference presentations. To reiterate how young this specialty is, my favorite and one of the most respected conferences dedicated to botnets, BotConf, has only met 6 times.

EOL is also going to become a problem when devices are still functional but not supported or updated. Today there are a large number of connected systems found in homes, cities and medical devices that at some point will no longer be supported by the manufacturers yet will still be functional. As these devices linger unprotected on the internet, they will provide criminal hackers’ a point of entry into unsecured networks. Once these devices pass EOL and are found online by criminals, they could become very dangerous for users depending on their function.

In a more recent case, Radware’s Threat Research Center identified criminals that were targeting DLink DSL routers in Brazil back in June. These criminals were found to be using outdated exploits from 2015. The criminals were able to leverage these exploits against vulnerable and unpatched routers 4 years later. The malicious actors attempted to modify the DNS server settings in the routers of Brazilian residents, redirecting their DNS request through a malicious DNS server operated by the hackers. This effectively allowed the criminals to conduct what’s called a man in the middle attack, allowing the hackers to redirect users to phishing domains for local banks so they could harvest credentials from unsuspecting users.

[You might also like: IoT Hackers Trick Brazilian Bank Customers into Providing Sensitive Information]

Attackers are not only utilizing old and unpatched vulnerabilities, but they are also exploiting recent disclosures. Back in May, vpnMentor published details about two critical vulnerabilities impacting millions of GPON gateways. The two vulnerabilities allowed the attackers to bypass authentication and execute code remotely on the targeted devices. The more notable event from this campaign was the speed at which malicious actors incorporated these vulnerabilities. Today, actors are actively exploiting vulnerabilities within 48 hours of the disclosure.

What Does the Future Hold?

The attack surface has grown to include systems using multiple technologies and communication protocols in embedded devices. This growth has also led to attackers targeting devices for a number of different reasons as the expansion continues. At first hackers, mainly DDoS’er would target IoT devices such as routers over desktops, laptops, and servers because they are always on, but as devices have become more connected and integrated into everyone’s life, attackers have begun exploring their vulnerabilities for other malicious activity such as click fraud and crypto mining. It’s only going to get worse as authors and operators continue to look towards the evolution of IoT devices and the connected future.

If anything is an indication of things to come I would say it would be found in the shift from Ransomware to crypto mining. IoT devices will be the main target for the foreseeable future and attackers will be looking for quieter ways to profit from your vulnerabilities. We as an industry need to come together and put pressure on manufacturers to produce secure devices and prove how the firmware and timely updates will be maintained. We also need to ensure users are not only aware of the present threat that IoT devices present but also what the future impact of these devices will be as they approach end of life. Acceptance, knowledge, and readiness will help us keep the networks of tomorrow secured today.

Download “When the Bots Come Marching In, a Closer Look at Evolving Threats from Botnets, Web Scraping & IoT Zombies” to learn more.

Download Now

DDoSSecurityWeb Application Firewall

Security Risks: How ‘Similar-Solution’ Information Sharing Reduces Risk at the Network Perimeter

August 23, 2018 — by Thomas Gobet — 1

security_network_perimeter-960x540.jpg

We live in a connected world where we have access to several tools to assist in finding any information we need. If we choose to do something risky, there is often some type of notification that warns us of the risk.

The same holds true in IT departments. When a problem occurs, we search for answers that allow us to make decisions and take action. What problem created the outage? Do I need to increase the bandwidth or choose a CDN offering? Do I need to replace my devices or add a new instance to a cluster?

Connected Security

We all know that connected IT can help us make critical decisions. In the past, we have depended on standalone, best-of-breed security solutions that detect and mitigate locally but do not share data with other mitigation solutions across the network.

[You might also like: Web Application in a Digitally Connected World]

Even when information is shared, it’s typically between identical solutions deployed across various sites within a company. While this represents a good first step, there is still plenty of room for improvement. Let us consider the physical security solutions found at a bank as an analogy for cybersecurity solutions.

A robber enters a bank. Cameras didn’t detect the intruder wearing casual clothes or anything identifying him or her as a criminal. The intruder goes to the first teller and asks for money. The teller closes the window. Next, the robber moves to a second window, demanding money and that teller closes the window. The robber moves to the third window, and so on until all available windows are closed.

Is this the most effective security strategy? Wouldn’t it make more sense if the bank had a unified solution that shared information and shut down all of the windows after the first attempt? What if this robber was a hacker who is trying to penetrate your system? Would you allow the hacker to try and break into more than one network silo after the first attempt?

Comprehensive Security Via An Enterprise-Grade Suite Solution

As we’ve seen in the example above, having mitigation solutions that can share attack information allows an organization to block a new “signature” when you see the request. But this only applies when the traffic reaches the solution. How could the bank better protect itself from the robber?

  • Should they do active verification at the entrance?
    • No, it would be time-consuming for customers who may consider not coming back.
  • Should they keep a list of customers allowed?
    • No, otherwise they would turn off new customers.
  • Should they signal the risk to other desks and entrance security?
    • Yes, that way all windows would be closed simultaneously and security guards would be able to catch the intruder and any future attempts to enter.

Imagine these windows are your different sites and the security guard placed at the entrance is your security solution at the perimeter of your network. Identifying abnormal behavior from normal behavior requires you to perform analysis of network traffic. The more advanced the analysis is the closer to the backend application the solution is. That way we can ensure only traffic allowed by prior solutions doing first security barriers gets through. Being close to the application means that analyzed traffic went through: router, firewalls, switches, IPs, anti-virus, anti-DLP and many other solutions (in classic architectures).

Organizations require a fully integrated WAF and DDoS mitigation appliance that can communicate effectively to allow WAF solutions (deployed close to the application) to warn anti-DDoS systems (deployed at the perimeter) that an attacker is trying to penetrate the perimeter.

In the blog “Accessing Application With A Driving License,” Radware recommends blocking any requests coming from clients with abnormal behavior. This mechanism was only applied to the WAF, but with this added communication, it goes even one step further and blocks bad requests and/or bad clients who are trying to access your network.

[You might also like: Accessing Application With a Driving License]

With a fully integrated WAF and DDoS detection and mitigation solution that communicates with one another, these devices will save you time and processing power and they will be more effective in blocking intrusions to your network.

Download “Web Application Security in a Digitally Connected World” to learn more.

Download Now

Older Posts