Malicious Bots

Malicious bots are rogue devices that pose a growing risk to modern web applications. The flexibility, increasing sophistication, and power of malicious bots make them formidable threats to your application security. Malicious bots can perform account takeovers, account creations, credit card fraud, DDoS attacks, and more. Malicious bots can exploit application vulnerabilities as well as attack via APIs and mobile applications. Moreover, malicious bots are responsible for launching the world’s largest DDoS attacks on record as well as spreading malware and exploit kits. All of these activities can affect performance, availability, and ultimately your bottom line.

Malicious bots are increasingly being utilized to infiltrate enterprise web applications at the network or cloud edge. This particular threat is what poses likely the most significant threat to your web applications. As a result, we cover this topic in more detail in Chapter 3, where you’ll learn how malicious bots work, how they circumvent your security posture, and, more importantly, how they can affect your business.

DDoS Attacks

DDoS attacks occur when multiple devices consume and overwhelm the bandwidth of an organization’s internet resources, encumber network routing and switching devices, melt down border firewalls and other security appliances, or overload the resources of one or more web services. DDoS attacks are often the result of multiple compromised devices or systems, operating in sizable botnets and flooding the targeted system with bogus traffic. DDoS attacks can also take advantage of protocols that can return a large amount of data in response to a small query; for example, sending a simple DNS request from a spoofed IP address that returns a large amount of data to that spoofed IP.

Recently, the size of DDoS attacks has grown exponentially due to newly discovered reflective and amplification techniques, most notably in use by malicious bots. The sophisticated use of bots is the catalyst that drives the multiterabyte DDoS attacks we’re seeing today and expect we’ll see well into the future. Attackers are now abusing malicious bots to drive DDoS attacks more than 51,000 times more powerful than their original strength. This invariably results in failed internet infrastructure, wreaking havoc on major websites, and bringing your ability to do business to a halt.

One of the factors driving the current proliferation of malicious bots and corresponding DDoS attacks is the Mirai malware. Mirai works by using a list of default usernames and passwords to take control of IoT devices. Mirai is self-propagating—each infected device has the ability to scan the internet to find similar devices and subsequently infect them.

Unfortunately, Mirai has also inspired copycat attacks that work by exploiting vulnerabilities in the underlying code on IoT devices instead of relying on default usernames and passwords. When a vulnerability is discovered, attackers quickly develop exploit codes to take advantage of the vulnerabilities. As a result, copycat botnets—like Reaper, Satori, and Okiru—are fueling increasingly powerful attacks themselves, exceeding the power of the original Mirai botnet.

By employing malicious bots, recent attacks have surpassed 1.7 Tbps, a truly massive display of power. According to Arbor Networks, one of the observed attacks targeted the customer of an unnamed US-based internet service provider (ISP). Fortunately, the ISP had proper DDoS defenses in place and no outages were reported, reinforcing the fact that strong defenses are both necessary and possible, even in the face of these colossal attacks. Many DDoS subject-matter experts believe that attacks will continue to grow in size, and multiterabit attacks will become the norm.

DDoS attacks can also easily divert or mask your security team’s attention from other malicious activity. For example, decoy attacks frequently employ the use of short-duration attacks that begin and end, over and over again, yet don’t completely take your organization offline. These attacks distract your team from other nefarious actions, such as infiltrating networks or systems to steal data.

Malware

Malware is defined as software that has malicious intent that is usually hidden from computer users. Common types of malware include viruses, worms, Trojans, adware, spyware, ransomware, and key loggers. Malware can perform a variety of malicious operations including stealing, encrypting or deleting sensitive data, altering or hijacking core computing functions, and monitoring users’ computer activity without their permission.

Although often targeting end points, malware is also a continuing security problem that can target web applications and the servers they run on. Malware infections often are triggered by computer users themselves and often spread through simple and necessary business activities. Malware infecting your web applications and servers normally does so due to poor coding practices, questionable file downloads, malicious links, or malicious file uploads. For example, many of today’s websites allow customers and visitors to upload files for a variety of business reasons, like a photo of a recent accident sent to an auto insurer or a document with e-signatures. These files can contain malware that can affect your website and applications or, worse, use your websites and applications to host and distribute malware. This has the potential to unknowingly infect customers on your site and spread exponentially from there. Of even greater concern, exploit kits can bombard your visitors with malicious code, targeting their operating systems, browsers, and media players.

Clearly, there are business implications if your organization’s sites or applications are identified sources of malware. Unfortunately, without proper security vigilance, websites and web applications can unintentionally serve as hosts to malware for significant periods of time (think months or years). Undetected, malware can be responsible for damages due to spiking network traffic, the loss of critical data, and the erosion of trust by customers infected by malware residing within your web applications.

Application Vulnerabilities

Application vulnerabilities are flaws in code or application design that create a possible point of compromise and potentially allow entry for attackers. These flaws can be newly identified by attackers (unannounced) or known by third-party software vendors (announced) and often leave edge apps at risk to security breaches, as attackers fervently write exploits to take advantage of previously discovered and unpatched vulnerabilities. This in turn can lead to serious data breaches that harm your customers, lead to loss of intellectual property, and otherwise damage your business. Common examples of web application vulnerabilities include injection vulnerabilities, cross-site scripting (XSS), broken authentication and session management, insecure direct object references, and security misconfiguration.

A prime example of the impact of unpatched application vulnerabilities is the much-publicized Equifax breach, in which a flaw in the open source Apache Struts framework used to build its web applications left the credit reporting agency vulnerable, resulting in the exposure of personal information for 143 million US consumers. Although the Equifax breach gained notoriety for its application flaws, this is a common problem that affects organizations of all sizes. Organizations increasingly rely on complex third-party web applications to deliver services to their customers. This leaves security teams heavily dependent on these third parties to release patches in a timely manner when new security flaws are discovered. Unfortunately, this means that at any given time, there are millions of vulnerable hosts available to exploit.

The sprawl of modern distributed systems exacerbates this already significant problem. Modern enterprises have hundreds or thousands of different systems and applications that must be monitored, patched, and otherwise managed in a secure manner. In any given week, a dozen or more patches need to be installed by a limited staff with limited time to addresses these issues, all without affecting usability for customers or internal teams. As a result, web applications with known vulnerabilities might go unpatched for months, depending on the severity of the vulnerability when it is first announced, the available staff resources, and the asset management policies of the enterprise in question.

The other reason that this problem continues to grow is the ease of access to infrastructure-on-demand services. Five years ago, procuring a new service usually meant your staff would go through a process to deploy servers in an organization-controlled datacenter. In today’s age of cloud computing, that is no longer the case. Now, nearly any employee with a corporate credit card can feasibly initiate infrastructure deployment. For example, if your marketing team wants to set up a website for a contest, it could simply request the domain it needs and deploy the new website. Although this allows for more employee ownership and reduced necessity of IT resources, it can be a nightmare for security teams. Simply stated, they cannot secure systems they don’t know about. That newly procured site could be running an outdated version of WordPress or JBOSS that could be easily exploited, and presumably no one would be monitoring it to mitigate these risks.

It’s useful to know that newly announced vulnerabilities are recorded in the National Vulnerability Database (NVD) maintained by NIST. When a new vulnerability is released, NIST includes important information such as the CVE (Common Vulnerability and Exposures) number; affected systems, also known as Common Platform Enumeration (CPE); and the risk of the vulnerability denoted by the Common Vulnerability Scoring System (CVSS) number.

CVSS is important, because it helps your organization determine patch prioritization. For example, a new vulnerability with a CVSS score of 2 is going to be a lower priority than one with a CVSS score of 10. Although helpful, this scoring system is inherently imperfect. The problem with this methodology is that just because a vulnerability has a low score today doesn’t mean it always will. So, if a new vulnerability is announced that affects an internet-facing system but has a low CVSS score, it will often be low on the patch priority scale and might stay that way for a long period of time, even if someone figures out how to exploit it and starts automatically scanning and exploiting vulnerable systems.

According to the Veracode State of Software Security 2017 report, vulnerabilities appear in previously untested software at alarming rates—with 77% of applications having at least one vulnerability on initial scan. The report also notes that even the most severe flaws take a long time to fix, with only 14% of very high severity flaws closed in 30 days or less. Increased vigilance is clearly needed.

Malicious bots come into play here, as well. When a vulnerability is found by researchers or attackers, exploit code can often be found in the dark net within days or hours of a vulnerability being discovered. In turn, attackers can modify or reprogram existing bots to continuously scan the internet to find and capitalize on these newly discovered vulnerabilities. A prime example of this is WordPress, which has had its share of vulnerabilities over the years and, more importantly, has thousands of available plugins that are especially prone to vulnerabilities. Attackers program bots to comb through the directory structure of WordPress sites looking to exploit these known vulnerabilities.

APIs and Mobile Application Risks

The majority of web applications use multiple APIs to connect with other applications and keep the online community connected. APIs decrease development time and generally make app development easier. If not used securely, though, unprotected APIs can pose serious risks to data security, leading to data breaches and denial-of-service (DoS) outages. Another challenge with APIs is that inexperienced developers often leave API keys exposed on the internet, either on paste sites or technical support forums. If an attacker stumbles upon an API key, they can use it to extract sensitive information from your applications or push services to the vendor, possibly incurring thousands of dollars in fees that are charged to the victim organization.

The ubiquity of mobile apps poses serious risks, as well. Consider apps on smartphones that are used to make purchases or book travel reservations. These apps sit on the network edge, often in the internet public domain. Attackers can easily find and reverse engineer them to create havoc and threaten data security.

Mobile apps usually communicate directly with your backend APIs. Mobile devices communicating with servers in these machine-to-machine transactions provide fertile ground for attackers to access private or proprietary data. These automated interactions are prime targets for harmful data breaches, DoS outages, and man-in-the-middle attacks. In a mobile environment, limiting traffic from a single IP address doesn’t work to thwart this kind of malicious activity due to Network Address Translation (NAT), which is a way to remap one IP address space into another by modifying network address information in the IP header of packets while they are in transit across a traffic routing device.