main

DDoS Attacks

The Normalization of DDoS Attacks

July 18, 2019 — by Daniel Smith — 1

SystemFailure-960x672.jpg

In June, I traveled to Israel to attend BsidesTLV and Cyber Week. Both of these events included incredible presentations, workshops, and networking opportunities. They also provided many unique opportunities to discuss research, privacy, and policy on many different levels with industry leaders and government officials from around the world.

Some of my preferred events during Cyber Week included Exploring The Grey Zone of Cyber Defense, Cyber Attacks Against Nations, and Academic Perspective’s on Cybersecurity Challenges.

One of the expert lectures during the Academic Perspective’s event struck a chord with me. The speech was titled, ‘Normalization as an Approach to Norms,’ and was presented by Prof. Martin Libicki, Professor at the U.S. Naval Academy.

At a high level, the talk was about the use of normalization as an approach to determining what cyber behaviors, carried out by governments, could be considered social norms in the cyber domain and who gets to set this gold standard. (If you would like to watch it for yourself, it can be found here on YouTube).

The part that resonated with me is when Prof. Libicki started talking about who might set the gold standard and what is considered normal cyber behaviors from different countries. For example, North Korea is known for robbing banks, and Russia is known for election interference and targeting the energy sector. Are these activities we want to accept as normal behavior? Of course not.

[You may also like: Protecting Enterprises From State-Sponsored Hackers]

What about China’s behaviors that include launching DDoS attacks on dissidents? Are we, the security industry, the gold standard, comfortable with allowing others to use denial of service attacks as a way to silence others?

This lecture was focused on nation-state attacks and real cyber warfare, but it left me connecting dots and wondering, hasn’t the security industry already accepted denial of service attacks as normalized behavior?

Are Denial of Service Attacks a Social Norm?

In my opinion, yes, denial of service attacks and assisting the behaviors are now accepted and expected on all levels. But why has this happened? Why have denial of service attacks become tolerated? The sad truth is we, the security and tech industry, allowed this to happen by accepting specific actions within the community and not speaking up about others.

[You may also like: Are Darknet Take-Downs Effective?]

One of the main reasons why denial of service attacks became a social norm is because of their popularity, and the attention paid to them earlier in the decade among hacktivist and gamers. With this came the availability for anyone to freely access source codes, tools, and resources need to conduct an attack of their own.

In general, no one prevents the availability of the source code and tools from being publicly accessible. In fact, criminals AND researchers do their fair share in propagating these tools and scripts used to launch denial of service attacks by hosting them on code repository sites.

Another reason why denial of service attacks became a social norm is that legitimate companies like hosting providers and social media outlets allowed the activity for one reason or another. For example, social media platforms enable criminals to not only post operational details but also to advertise their malicious services publicly. At the same time, the hosting providers turn a blind eye for profit and allow criminals to host and mask their infrastructure with their services.  

[You may also like: Here’s How You Can Better Mitigate a Cyberattack]

Also, at this point, you could almost say manufactures and some ISPs are co-conspirators. Manufacturers are building and shipping vulnerable IoT devices with no intention of patching or providing software updates for known exploits thus contributing to the number of possible devices that could be leveraged by a botherder for a denial of service attack. You also have ISPs that know they are significant offenders and the main source of the malicious traffic, yet do very little to mitigate the activity, let alone respond to abuse reports.

So, are we comfortable allowing others to use denial of service attacks as a way to silence people? From my perspective, it seems like we do a lot to support the activity.

Acceptance is a Slippery Slope

To be clear, in no way am I saying that a denial of service attack is nothing to worry about now that they have become a norm. But I believe most of us have grown to accept denial of service attacks, specifically temporary network outages, as a regular occurrence or have written it off as the cost of doing business in the digital era, which has led to this path of acceptance and normalization.

At any rate, if China’s use of denial of service attacks against foreign platforms used by Chinese dissidents is acceptable, or something we allow to happen without any action, then the average denial of service attack against your corporate network is considered normal behavior as well.

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

Under this current environment of acceptance, it becomes harder to look at the average botherder and say their behavior is not normal or acceptable, while simultaneously taking a passive approach on nation-states that use the same attack vector. 

If we want to reduce the number of denial of service attacks by non-government actors, then we have to lead by example as the gold standard. We have to make sure people know that nation-states use of denial of service attack is unacceptable. We also have to do more to prevent malicious actors from gaining access to the tools used to launch these attacks.

Hosting attack services and code should not be acceptable behavior from the security community.

How Much More Will We Tolerate?

This is a question I don’t have an answer for. At the moment, we tolerate a lot. At this rate, almost every teenager, at some point, will be involved in or know someone who is engaged in launching a DDoS attack. And while some will write it off as child’s play to just knock their friend offline, we all know they likely got the code from one of our public repositories or used different services that some of us manage to mask their origin.

Remember, we as the security industry set the golden standard, and when we tolerate specific behavior for long enough, it becomes socially acceptable.

DDoS

Why You Still Need That DDoS Appliance

July 2, 2019 — by Eyal Arazi — 0

AdobeStock_229146668-960x532.jpeg

More and more organizations are adopting cloud-based DDoS defenses and substituting them for their old, premise-based DDoS appliances. Nonetheless, there are still a number of reasons why you might want to keep that DDoS appliance around.

The Rise of Cloud Protection

More and more organizations are deploying cloud-based DDoS mitigation services. Indeed, Frost & Sullivan estimated that by 2021, cloud-based mitigation service will account for 70% of spending on DDoS protection.

The reasons for adopting cloud-based protections are numerous. First and foremost, is capacity. As DDoS attacks keep getting bigger, high-volume DDoS attacks capable of saturating the inbound communication pipe are becoming more common. For that reason, having large-scale cloud-based scrubbing capacity to absorb such attacks is indispensable.

[You may also like: Does Size Matter? Capacity Considerations When Selecting a DDoS Mitigation Service]

Moreover, cloud-based DDoS defenses are purchased on a pay-as-you-go SaaS subscription model, so organizations can quickly scale up or down, and don’t need to allocate large amounts of capital expenditure (CAPEX) far in advance. In addition, cloud services usually provide easier management and lower overhead than on-prem equipment, and don’t require dedicated staff to manage.

It is no surprise, then, that more and more organizations are looking to the cloud for DDoS protection.

The benefits of the cloud notwithstanding, there are still several key reasons why organizations would still want to maintain their hardware appliances, alongside cloud-based services.

[You may also like: Managing Security Risks in the Cloud]

Two-Way Traffic Visibility

Cloud-based services, by definition, only provide visibility into ingress – or inbound – traffic into the organization. They inspect traffic as it flows through to the origin, and scrub-out malicious traffic it identifies. While this is perfectly fine for most types of DDoS attacks, there are certain types of DDoS attacks that require visibility into both traffic channels in order to be detected and mitigated.

Examples of attacks that require visibility into egress traffic in order to detect include:

  • Out-of-State Protocol Attacks: These attacks exploit weaknesses in protocol communication process (such as TCP’s three-way handshake) to create “out-of-state” connection requests which exhaust server resources. Although some attacks of this type – such as SYN floods – can be mitigated solely with visibility into ingress traffic only, other types of out-of-state DDoS attacks – such as an ACK flood – require visibility into the outbound channel, as well. Visibility into the egress channel will be required to detect that these ACK responses are not associated with a legitimate SYN/ACK response, and can therefore be blocked.

[You may also like: 5 Key Considerations in Choosing a DDoS Mitigation Network]

  • Reflection/Amplification Attacks: These attacks take advantage of the asymmetric nature of some protocols or request types in order to launch attacks that will exhaust server resources or saturate the outbound communication channel. An example of such an attack is a large file download attack. In this case, visibility into the egress channel is required to detect the spike in outbound traffic flowing from the network.
  • Scanning attacks: Such attacks frequently bare the hallmarks of a DDoS attack, since they flood the network with large numbers of erroneous connection requests. Such scans frequently generate large numbers of error replies, which can clog-up the outbound channel. Again, visibility into the outbound traffic is required to identify the error response rate relative to legitimate inbound traffic, so that defenses can conclude that an attack is taking place.

Application-layer Protection

Similarly, relying on a premise-based appliance has certain advantages for application-layer (L7) DDoS protection and SSL handling.

Certain types of application-layer(L7) DDoS attacks exploit known protocol weaknesses in order to generate large numbers of forged application requests that exhaust server resources. Examples of such attacks are low-and-slow attacks or application-layer SYN floods, which draw-out TCP and HTTP connections to continuously consume server resources.

[You may also like: Layer 7 Attack Mitigation]

Again, although some such attacks can be mitigated by cloud scrubbing service, mitigating some types of attacks requires application state-awareness that cloud-based mitigation services usually do not possess.

Using a premise-based DDoS mitigation appliance with application-layer DDoS protection capabilities allows organizations to have this.

SSL DDoS Protection

Moreover, SSL encryption is adding another layer of complexity, as the encryption layers makes it difficult to inspect traffic contents for malicious traffic. In order to inspect traffic contents, cloud-based services must decrypt all traffic, inspect it, scrub-out bad traffic, and re-encrypt it, before forwarding it to the customer origin.

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

As a result, most cloud-based DDoS mitigation services either provide no protection at all for SSL-based traffic, or use full-proxy SSL offloading which require that customers upload their certificates to the service provider’s cloud infrastructure.

However, performing full SSL offloading in the cloud is frequently a burdensome process which adds latency to customer communications and violates user privacy. That is why many organizations are hesitant – or don’t have the capability – of sharing their SSL keys with third party cloud service providers.

[You may also like: How to (Securely) Share Certificates with Your Cloud Security Provider]

Again, deploying a premise-based appliance allows organizations to protect against SSL DDoS floods while keeping SSL certificates in-house.

Layered Protection

Finally, using a premise-based hardware appliance in conjunction with a cloud service allows for layered protection in case attack traffic somehow gets through the cloud protection.

Using a premise-based appliances allows the organization control directly over device configuration and management. Although many organizations prefer that this be handled by cloud-based managed services, some organizations (and some security managers) prefer to have this deeper level of control.

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

This control also allows security policy granularity, so that security policies can be fine-tuned exactly to the needs of the organizations, and cover attack vectors that the cloud-layer does not – or cannot – cover.

Finally, this allows for security failover, so that if malicious traffic somehow gets through the cloud mitigation, the appliance will handle it.

The Best Practice: A Hybrid Approach

Ultimately, it is up to each organization to decide what is the optimal solution for them, and what type of deployment model (appliance, pure cloud, or hybrid) is best for them.

Nonetheless, more and more enterprises are adopting a hybrid approach, combining the best of both worlds between the security granularity of hardware appliances, and the capacity and resilience of cloud services.

In particular, an increasingly popular option is an always-on hybrid solution, which combines always-on cloud service together with a hardware DDoS mitigation appliance. Combining these defenses allows for constant, uninterrupted protection against volumetric protection, while also protecting against application-layer and SSL DDoS attacks, while reducing exposure of SSL keys and improving handling of SSL traffic.

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

Download Now

SecurityService Provider

Out of the Shadows, Into the Network

April 9, 2019 — by Radware — 1

darkness-960x540.jpg

Network security is a priority for every carrier worldwide. Investments in human resources and technology solutions to combat attacks are a significant part of carriers’ network operating budgets.

The goal is to protect their networks by staying a few steps ahead of hackers. Currently, carriers may be confident that their network security solution is detecting and mitigating DDoS attacks.

All the reports generated by the solution show the number and severity of attacks as well as how they were thwarted. Unfortunately, we know it’s a false sense of well-being because dirty traffic in the form of sophisticated application attacks is getting through security filters. No major outages or data breaches have been attributed to application attacks yet, so why should carriers care?

Maintaining a Sunny Reputation

The impact of application attacks on carriers and their customers takes many forms:

  • Service degradation
  • Network outages
  • Data exposure
  • Consumption of bandwidth resources
  • Consumption of system resources

[You may also like: How Cyberattacks Directly Impact Your Brand]

A large segment of carriers’ high-value customers have zero tolerance for service interruption. There is a direct correlation between service outages and user churn.

Application attacks put carriers’ reputations at risk. For customers, a small slowdown in services may not be a big deal initially. But as the number and severity of application attacks increase, clogged pipes and slow services are not going to be acceptable. Carriers sell services based on speed and reliability. Bad press about service outages and data compromises has long-lasting negative effects. Then add the compounding power of social networking to quickly spread the word about service issues, and you have a recipe for reputation disaster.

[You may also like: Securing the Customer Experience for 5G and IoT]

Always Under Attack

It’s safe for carriers to assume that their networks are always under attack. DDoS attack volume is escalating as hackers develop new and more technologically sophisticated ways to target carriers and their customers In 2018, attack campaigns were primarily composed of multiple attacks vectors, according to the Radware 2018–2019 Global Application & Network Security Report.

The report finds that “a bigger picture is likely to emerge about the need to deploy security solutions that not only adapt to changing attack vectors to mitigate evolving threats but also maintain service availability at the same time.”

[You may also like: Here’s How Carriers Can Differentiate Their 5G Offerings]

Attack vectors include:

  • SYN Flood
  • UDP Flood
  • DNS Flood
  • HTTP Application Flood
  • SSL Flood
  • Burst Attacks
  • Bot Attacks

Attackers prefer to keep a target busy by launching one or a few attacks at a time rather than firing the entire arsenal all at once. Carriers may be successful at blocking four or five attack vectors, but it only takes one failure for the damage to be done.

2018 Mobile Carrier Ebook

Read “Creating a Secure Climate for your Customers” today.

Download Now

Attack MitigationDDoSSecurity

DDoS Protection Requires Looking Both Ways

March 26, 2019 — by Eyal Arazi — 1

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

Cloud ComputingCloud SecuritySecurity

Security Pros and Perils of Serverless Architecture

March 14, 2019 — by Radware — 2

serverless-960x544.jpg

Serverless architectures are revolutionizing the way organizations procure and use enterprise technology. This cloud computing model can drive cost-efficiencies, increase agility and enable organizations to focus on the essential aspects of software development. While serverless architecture offers some security advantages, trusting that a cloud provider has security fully covered can be risky.

That’s why it’s critical to understand what serverless architectures mean for cyber security.

What Serverless Means for Security

Many assume that serverless is more secure than traditional architectures. This is partly true. As the name implies, serverless architecture does not require server provisioning. Deep under the hood, however, these REST API functions are still running on a server, which in turn runs on an operating system and uses different layers of code to parse the API requests. As a result, the total attack surface becomes significantly larger.

When exploring whether and to what extent to use serverless architecture, consider the security implications.

[You may also like: Protecting Applications in a Serverless Architecture]

Security: The Pros

The good news is that responsibility for the operating system, web server and other software components and programs shifts from the application owner to the cloud provider, who should apply patch management policies across the different software components and implement hardening policies. Most common vulnerabilities should be addressed via enforcement of such security best practices. However, what would be the answer for a zero-day vulnerability in these software components? Consider Shellshock, which allowed an attacker to gain unauthorized access to a computer system.

Meanwhile, denial-of-service attacks designed to take down a server become a fool’s errand. FaaS servers are only provisioned on demand and then discarded, thereby creating a fast-moving target. Does that mean you no longer need to think about DDoS? Not so fast. While DDoS attacks may not cause a server to go down, they can drive up an organization’s tab due to an onslaught of requests. Additionally, functions’ scale is limited while execution is time limited. Launching a massive DDoS attack may have unpredictable impact.

[You may also like: Excessive Permissions are Your #1 Cloud Threat]

Finally, the very nature of FaaS makes it more challenging for attackers to exploit a server and wait until they can access more data or do more damage. There is no persistent local storage that may be accessed by the functions. Counting on storing attack data in the server is more difficult but still possible. With the “ground” beneath them continually shifting—and containers re-generated—there are fewer opportunities to perform deeper attacks.

Security: The Perils

Now, the bad news: serverless computing doesn’t eradicate all traditional security concerns. Code is still being executed and will always be potentially vulnerable. Application-level vulnerabilities can still be exploited whether they are inherent in the FaaS infrastructure or in the developer function code.

Whether delivered as FaaS or just based on a Web infrastructure, REST API functions are even more challenging code than just a standard web application. They introduce security concerns of their own. API vulnerabilities are hard to monitor and do not stand out. Traditional application security assessment tools do not work well with APIs or are simply irrelevant in this case.

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

When planning for API security infrastructure, authentication and authorization must be taken into account. Yet these are often not addressed properly in many API security solutions. Beyond that, REST APIs are vulnerable to many attacks and threats against web applications: POSTed JSONs and XMLs injections, insecure direct object references, access violations and abuse of APIs, buffer overflow and XML bombs, scraping and data harvesting, among others.

The Way Forward

Serverless architectures are being adopted at a record pace. As organizations welcome dramatically improved speed, agility and cost-efficiency, they must also think through how they will adapt their security. Consider the following:

  • API gateway: Functions are processing REST API calls from client-side applications accessing your code with unpredicted inputs. An API Gateway can enforce JSON and XML validity checks. However, not all API Gateways support schema and structure validation, especially when it has to do with JSON. Each function deployed must be properly secured. Additionally, API Gateways can serve as the authentication tier which is critically important when it comes to REST APIs.
  • Function permissions: The function is essentially the execution unit. Restrict functions’ permissions to the minimum required and do not use generic permissions.
  • Abstraction through logical tiers: When a function calls another function—each applying its own data manipulation—the attack becomes more challenging.
  • Encryption: Data at rest is still accessible. FaaS becomes irrelevant when an attacker gains access to a database. Data needs to be adequately protected and encryption remains one of the recommended approaches regardless of the architecture it is housed in.
  • Web application firewall: Enterprise-grade WAFs apply dozens of protection measures on both ingress and egress traffic. Traffic is parsed to detect protocol manipulations, which may result in unexpected function behavior. Client-side inputs are validated and thousands of rules are applied to detect various injections attacks, XSS attacks, remote file inclusion, direct object references and many more.
  • IoT botnet protection: To avoid the significant cost implications a DDoS attack may have on a serverless architecture and the data harvesting risks involved with scraping activity, consider behavioral analysis tools and IoT botnet solutions.
  • Monitoring function activity and data access: Abnormal function behavior, expected access to data, non-reasonable traffic flow and other abnormal scenarios must be tracked and analyzed.

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

Download Now

Attack Types & VectorsSecurity

The Rise in Cryptomining

January 29, 2019 — by Radware — 1

cryptomining-960x255.jpg

There are four primary motivations for cyberattacks: crime, hacktivism, espionage and war. Setting aside nation-state sponsored groups, the largest faction of attackers are cybercriminals, individuals or well-established organizations looking to turn a profit.

For the last several years, ransom-based cyberattacks and ransomware had been the financial modus operandi for hackers, but 2018 flipped the coin to unveil a new attack vector: cryptomining.

Always Crypto

Radware’s Malware Threat Research Group monitored this phenomenon throughout the year and identified two recurring trends. Some groups use cryptomining to score a quick, easy profit by infecting machines and mining cryptocurrencies. Other groups use cryptomining as an ongoing source of income, simply by reselling installations on infected machines or selling harvested data.

While there is no definitive reason why cryptomining has become popular, what is clear are some of the advantages it has over older attacks methods:

  • It’s easy – There’s no need to develop a cryptomining tool or even buy one. An attacker can just download a free tool into the victim’s machine and run it with a simple configuration that instructs it to mine the pool.
  • CPU – While Bitcoin requires a graphic processing unit (GPU) to perform effective mining, other cryptocurrency, such as Monero, require only CPU to effectively mine a machine. Since every machine has a CPU, including web cameras, smartphones, smart TVs and computers, there many potential targets.
  • Minimal footprint — Other attack types require the hackers to market their “goods” or to actively use the information they acquired for malicious purposes. In cryptomining, the money moves directly to the attacker.
  • Value — The value of cryptocurrencies skyrocketed in late 2017 and early 2018. The outbreak quickly followed. More recently, as monetary value declined, so has the number of incidences.
  • Multipurpose hack — After successfully infecting a machine, hackers can leverage the installation of the malware program for multiple activities. Stealing credentials from machines? Why not use those machines to cryptomine as well (and vice versa)? Selling data mining installations on machines to other people? Add a cryptomining tool to run at the same time.

[You may also like: Top Cryptomining Malware. Top Ransomware.]

The Malware Ecosystem

There are a few popular ways for cybercriminals to launch cryptomining attacks:

  • Information stealing — By distributing a data harvesting malware, attackers steal access credentials or files (photos, documents, etc.), and even identities found on an infected machine, its browser or inside the network. Then, the cybercriminals generally use the stolen data to steal. In the case of bank credentials, the hackers use the information to steal money from accounts. They may also sell the stolen data through an underground market on the dark web to other hackers. Credit cards, social security numbers and medical records go for just a few dollars. Social media accounts and identities are popular, as well. Facebook and Instagram accounts have been hijacked and used for propagation.
  • Downloaders — Malware is distributed with simple capabilities to download additional malware and install on other systems.The motivation is to infect as many machines as possible. The next step is to sell malware installations on those machines. Apparently, even infected machines enjoy brand premium fees — machines from a Fortune 500 company cost a lot more.
  • Ransomware — Machines are infected with a malware that encrypts files, which are usually valuable to the victim, such as photos, Microsoft files (.xlsx,.docx) and Adobe Acrobat files. Victims are then asked to pay a significant amount of money in order to get a tool to decrypt their files. This attack was first introduced against individuals but grew exponentially when hackers figured out that organizations can pay a higher premium.
  • DDoS for ransom (RDoS) — Attackers send targets a letter that threatens a DDoS attack on a certain day and time unless the organization makes a payment, usually via Bitcoin. Often hackers know the IP address of the targeted server or network and launch a small-scale attack as a preview of what could follow.

[You may also like: Malicious Cryptocurrency Mining: The Road Ahead]

Social Propagation

Malware protection is a mature market with many competitors. It is a challenge for hackers to create a one-size-fits-all zero-day attack that will run on as many operating systems, servers and endpoints as possible, as well as bypass most, if not all, security solutions. So in addition to seeking ways to penetrate protection engines, hackers are also looking for ways to bypass them.

During the past year, Radware noticed several campaigns where malware was created to hijack social network credentials. That enabled hackers to spread across the social network accessing legitimate files on the machine and private information (or computing resources, in the context of cryptomining).

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

Here are a few examples:

  • Nigelthorn – Radware first detected this campaign, which involved a malicious chrome extension, in a customer’s network. The hackers bypassed Google Chrome native security mechanisms to disguise the malware as a legitimate extension. The group managed to infect more than 100,000 machines. The purpose of the extension was cryptomining Monero currency by the host machine, as well as stealing the credentials of the victim’s Facebook and/or Instagram accounts. The credentials were abused to propagate the attack through the Facebook user’s contact network. It is also possible that the credentials were later sold on the black market.
  • Stresspaint — In this spree, hackers used a benign-looking drawing application to hijack Facebook users’ cookies. They deceived victims by using an allegedly legitimate AOL.net URL, which was actually a unicode representation. The true address is “xn--80a2a18a.net.” The attackers were building a database of users with their contact
    network, business pages and payment details. Radware suspects that the ultimate goal was to use this information to fund public opinion influence campaigns on the social network.
  • CodeFork — This campaign was also detected in some of Radware’s customers’ networks when the infected machines tried to communicate with their C&C servers. Radware intercepted the communication and determined that this group was infecting machines in order to sell their installations. The group has been active for several years during which time we have seen them distributing different malware to the infected machines. The 2018 attack included an enhancement that distributes
    cryptomining malware.

Moving Forward

Radware believes that the cryptomining trend will persist in 2019. The motivation of financial gain will continue, pushing attackers to try to profit from malicious malware. In addition, hackers of all types can potentially add cryptomining capabilities to the infected machines that they already control. Our concern is that during the next phase, hackers will invest their profits to leverage machine-learning capabilities to find ways to access and exploit resources in networks and applications.

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

Download Now

Botnets

Bot or Not? Distinguishing Between the Good, the Bad & the Ugly

January 8, 2019 — by Anna Convery-Pelletier — 1

bot_management-960x460.jpg

Bots touch virtually every part of our digital lives. They help populate our news feeds, tell us the weather, provide stock quotes, control our search rankings, and help us comparison shop. We use bots to book travel, for online customer support, and even to turn our lights on and off and unlock our doors.

Yet, for every ‘good’ bot, there is a nefarious one designed to disrupt, steal or manipulate. Indeed, at least one third of all Internet traffic is populated by a spectrum of ‘bad’ bots. On one end, there are the manipulative bots, like those designed to buy out retailers’ inventory to resell high-demand goods at markup (like limited edition sneakers or ticket scalping) or simulate advertiser click counts. On the other, more extreme end, malicious bots take over accounts, conduct API abuse and enslave our IoT devices to launch massive DDoS attacks.

Equally troubling is the speed at which the bot ecosystem is evolving. Like most criminal elements, threat actors are singularly focused in their goals: They constantly update, mutate, and modify their tool sets to work around the various protections companies put in place.

[You may also like: The Evolution of IoT Attacks]

In other words, what protected your organization against bots last year may not work today. Research from Radware’s 2018 State of Web Application Security Report shows that most organizations rely on tools like Captcha to detect their bot traffic, but modern, sophisticated bots can easily bypass those tools, making it difficult to even detect bot traffic, let alone identify the bot’s intentions.

Organizations need to look for bot management solutions that not only effectively detect and mitigate bot attacks but can also distinguish between ‘good’ and ‘bad’ bots in real-time.

Yesterday, Radware announced its intent to acquire ShieldSquare, which is a pioneer in the bot mitigation industry and one of three recognized solution leaders by Forrester with strong differentiation in the Attack Detection, Threat Research, Reporting, and Analytics categories.

The strong technology synergy between the two companies around advanced machine learning and the opportunity to extend Radware’s existing cloud security services bring a tremendous advantage to our customers and partners.

[You may also like: 9 Ways to Ensure Cloud Security]

This acquisition allows Radware to expand our portfolio with more robust bot management solutions that can stand alone as product offerings as well as integrate into our suite of attack mitigation solutions. Radware will offer ShieldSquare’s bot management and mitigation product under the new Radware Bot Management product line. It enhances Radware’s advanced anti-bot capabilities from multi-protocol IoT DDoS attacks to more crafted e-commerce attacks affecting six emerging problems:

  • Data harvesting and Scraping Attacks
  • Account creation and Account Takeover Attacks
  • Denial of Inventory
  • Application DDoS & Brute Force Attacks
  • Brand Image / Reputation Attacks

It also provides ShieldSquare’s customers with access to the full suite of Radware security and availability solutions both on-prem and in the cloud, including our Cloud WAF services for comprehensive protection of applications.

We look forward to welcoming the ShieldSquare team into the Radware family and joining forces to offer some of the world’s best bot management solutions.

Read “Radware’s 2018 Web Application Security Report” 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

Attack Types & VectorsDDoSSecurity

Eliminating Single Points of Failure, Part 2

July 6, 2017 — by Louis Scialabba — 0

ddos-primer-part-2-960x640.jpg

The Risk DDoS Attacks Pose to Enterprises

What is the impact of a DDoS Attack?

Denial of Service attacks affect enterprises from all sectors (e-gaming, Banking, Government etc.), all sizes (mid/big enterprises) and all locations. They target the network layer up through the application layer, where attacks are more difficult to detect since they can easily get confused with legitimate traffic.
A denial of service attack generates high or low rate attack traffic exhausting computing resources of a target, therefore preventing legitimate users from accessing the website. A DDoS attack can always cause an outage, but often they have the stealth impact of slowing down network performance in way that enterprise IT teams do not even realize the network is under attack and simply think the network is congested, not knowing the congestion is actually caused by an attack.

Cloud SecurityDDoSSecurity

Automated Attacks Are Here to Stay

October 18, 2016 — by Dennis Usle — 0

automated-attacks-2-960x720.jpg

It seems the future is upon us. Some of you may have heard about the attacks on Brian Krebs’ security researcher and journalist, as well as the attacks on OVH French hosting company. The attacks are accounting for the world’s largest DDoS attacks ever on record, 620Gbps and 1+Tbps respectively. If you’ve read up on these attacks, you’ll also be familiar with the fact that automated bot armies are being leveraged by booter or stresser services. These services are offered by “entrepreneurs” for a nominal fee to their paying clientele. Booter services are not new to the realm of DDoS. What’s changed over the years is the scale and scope these automation engines are achieving. The services command and control networks have grown in number of pwn’d bots and increased capabilities of advanced and effective attack tactics. The exponential population growth of insecure internet-connected devices has enabled this. The Internet of Things (IoT) aka IP-enabled cameras, printers, TVs, refrigerators, etc. have certainly contributed in part because these devices were not developed with security in mind.

Older Posts