According to Accenture’s ninth annual Cost of Cybercrime study, the number of cyberattacks continues to rise and take more time to resolve. Organizations participating in the study saw an average of 145 attacks in 2018, up from 130 in 2017. The good news in the report was that prioritizing technologies to improve cybersecurity protection can reduce the consequences of attacks and “unlock future economic value as higher levels of trust encourage more business from customers.”
However, technology can take you only so far. “Whether by accident or intent, many employees are often the root cause of successful cyberattacks,” the report noted. As demonstrated by several recently publicized data breaches, a key area of concern is how developers deploy their databases, creating completely unnecessary vulnerabilities that let adversaries stroll into their networks with little effort. To mitigate this threat, companies must reduce the potential for human error, react quickly and appropriately to breach notifications, and embrace the security research community.
Human Error and Data Breaches
Examples of common breaches likely caused by developer errors include those at Verifications.io and Lumin PDF.
In the case of Verifications.io, security researcher Bob Diachenko discovered a non-password-protected 150GB MongoDB instance that included four databases containing plain text entries. He confirmed that the database was owned by Verifications.io, an email verification company that helped clients remove inactive addresses from their bulk email lists. The breach exposed between 800 million and 1 billion records (depending on how they are counted), including verified emails, phone numbers, addresses, dates of birth, social media account details, and financial information.
Lumin PDF, a cloud-based service that lets users view, edit, and share PDF files, recently confirmed that a third party gained access to its system and stole user information, including email addresses and encrypted passwords. The adversary then published a download link to the company’s entire user database, a 2.25GB ZIP file that holds a 4.06GB CSV file containing the user records of 24,386,039 Lumin PDF users. Writing on a forum, the adversary claimed to have obtained the data from a MongoDB database that was accessible online without a password.
While it would be reckless to assume that we know exactly how and why these companies left themselves so vulnerable, there are some common reasons that such breaches are occurring. One is that developers, under pressure from above to rapidly bring a product to market, quickly spin up a database to meet their needs and then put it into production without adequate forethought regarding how the database should be configured or isolated.
Another reason is the popularity of MongoDB and Elasticsearch. While these are certainly good products and easy to use, certain options in their default configurations, if not modified, could lead to the exposure of data. MongoDB, for example, has no default authentication set, so if a developer spins up a database and never changes this setting, the database will be accessible without authentication. In versions 2.6 or later, MongoDB does not bind to all interfaces by default, meaning users must change the configuration to bind to external IP addresses in order to function. Users should consider adding authentication at this stage as a matter of course. Elasticsearch now has X-Pack, which, at the appropriate paid-for tier, provides an authentication layer and other security-related features, built in. However, businesses must pay to use the authentication and other security features of X-Pack, so many companies either don’t implement this, or implement it for the trial period and let it expire, again leaving the database open with no authentication requirements.
In addition to the lack of authentication, organizations are failing to properly configure network isolation. Take the Capital One breach. More than 100 million consumer applications for credit, including Social Security numbers, were exposed to the public. The problem seems to have stemmed at least in part from a misconfigured open source Web Application Firewall (WAF) being used for an Amazon Web Services (AWS) deployment. The WAF should provide protection against several vulnerabilities that attackers commonly use. However, the WAF was apparently left in the default configuration, which allowed the adversary to manipulate the firewall using the well-known Server Side Request Forgery (SSRF) attack. In addition, the WAF was configured to reach an IP address range that was too broad, allowing access to the AWS metadata service. Finally, and this is speculation, AWS identity access management may have been configured with too many permissions. Also, the AWS CloudTrail service may not have been properly configured based on the facts that the WAF allowed access to the AWS S3 bucket data, and the scope was not completely clear for what was accessed.
Once again, simply focusing on security and ensuring proper configuration of the deployment could have prevented this breach.
What Can Companies Do?
Organizations must ensure that developers are fully educated on the security features of the entire development stack and the risks to the organization of improper configuration and use.
It does no good to build the most secure bank vault in the world if the doors to the vault and the bank are simply left open to the public. And if bank personnel don’t understand how to properly lock the doors, they can never make the bank safe. Likewise, developers must understand how to configure their tools for security. In part, this means they should never assume default configurations are secure. In the case of Capital One, developers also needed to understand how to properly configure the cloud to provide appropriate identity and access management (IAM) permissions, as well as the WAF, including the use of whitelists which, if correctly configured, would have blocked 90% of typical attack attempts.
Further, while a firewall is essential for security, by itself, it is never enough. Other tools, whether MongoDB, Elasticsearch, AWS, or any other tool in the stack, must also be properly configured, including authentication requiring valid credentials.
Beyond the development team, vulnerability scanners can be deployed to help spot security issues before applications are put into production. As organizations begin to grow, they can also create security teams whose role is to oversee the security of production environments. These could include, for example, AWS Certified Architects, who have a deep understanding of AWS security issues. Expert third-party consultants are also available to review the security of application stacks.
Businesses must also create a culture of security. They need to stop thinking that “move fast and break things” will lead to successful innovation. They must stop putting pressure on developers to bring products to market as fast as possible without regard for security. This is a culture change that must start at the top.