The news is filled with instances where companies inadvertently leave databases exposed on the web – even sometimes for just hours before they realise the mistake has been made.
Comparitech set up a honeypot to do some research to see if it left a fake database exposed, what would happen. Researcher Bob Diachenko left the data exposed from May 11, 2020 to May 22, 2020. During that time, 175 unauthorised requests were made. He broadly refers to these requests as “attacks”. The honeypot averaged 18 attacks per day and the first attack came on May 12, just 8 hours and 35 minutes after deployment.
Accidental exposure of databases is a lot more common than people think. We see this all the time and notify clients daily about small exposures they may have introduced in their environments as part of our continuous asset profiling service. There has been a substantial improvement during the great cloud migration. Using a service such as AWS or Azure, which automatically locks down your machines and services, is a great way to reduce the likelihood of leaving something exposed. These providers, in fact, have this control enabled by default, meaning that users have to go out of their way to leave anything exposed on the internet. The issues with exposed databases are introduced when teams are managing technologies that don\’t have this control enabled by default – there is an assumption of security, and this leads organisations down the path of accidental exposure.
Finding exposed databases or devices on the internet today quite easy, as further proven by Comparitech’s honeypot research. There are specially designed search engines that look for exposed devices on the internet, and even malware like Kaiji (as one example) automatically looks for exposed operating systems with root access. For this reason, a timestamp of less than 9 hours before the first “attack” started is nothing surprising. It however shows that there is not much time for companies to find a mistake and repair it before there is potential for a bad actor to identify and manipulate it.
Every mistake in provisioning your resources can lead to big problems. We see often that insecure steps are made when deploying instances in the cloud environment. Insecure security settings lead to exploitable systems and devices. I recommend that companies have procedures around provisioning resources and hold to them much like a pilot’s check list in preparation for takeoff. This then leads to 2 important things: first, the creation of security policies and procedures and secondly, a check list that does not allow room for mistakes.