How do you deal with low risk level vulnerabilities? Small issues, big problems…
Disclaimer: This story is a fiction, any resemblance to real people and networks, living or dead, is purely coincidental.… or not.
Wait ! Do you have an IT manager named Jean ? 😉
The story timeline
November 2016
Your company is growing, you’re not a start-up anymore and you have new needs and requirements. With Jean; your IT manager, you have decided to install a new server in the cloud to enhance corporate communication with your consultants.
The project is quite simple: Make non-sensitive data already present on your intranet, available to your consultants.
Jean is quite concerned about security. He knows that the intranet application was developed a long time ago and he refuses to expose the server to the big bad Internet.
Actions:
- So, he decides to place the intranet server into a DMZ, and limit the access to this DMZ to a single server on which is installed a CMS (known to be secure).
- Also, to make sure that this new brand you “openness” doesn’t put your business at risk, Jean plans a black box pentest by a well-known security firm (Approach ?).
Results: The result of the penetration test is really good and reports only one vulnerability (No it’s not Approach! Choice is yours…):
As the risk level is « Low », you don’t give too much importance to the report and your IT manager goes on with his day to day activities …
December 15, 2018 – new need …
It’s almost the end of the year and you want to organize a business day to bring your consultants together.
You need some kind of doodle on the CMS to harvest the availabilities of your team for the event, but the IT manager is overbooked and delegates the development task to his trainee.
December 20, 2018 – impact ….
You receive a phone call from the data protection authority: the complete dump of your intranet database was found on the darknet. Including sensitive information about clients and contracts.
What happened?
Your trainee made a small error while coding the database query in the plugin and introduced a SQL injection vulnerability.
A hacker could leverage it using the « SELECT INTO OUTFILE » SQL query. So, he/she was able to execute PHP code and execute system commands.
- To do this, he/she injected a similar SQL code:
- Next, he/she could execute system commands from his browser:
You probably think it’s the student’s fault. After all he introduced the SQL injection!
In fact, it’s a little bit more complex: To escalate the SQL injection into a remote code injection, the attacker had to know the full path to the web directory… and you gave him the information!
Do you remember this « low » level issue in the report?
All the hacker had to do, once the web server owned, was to attack your old and very vulnerable intranet server and dump its database.
And the story ends, at least that’s what you like to think:
You were a small start-up only two years ago, time goes by and you never took the time to put a good monitoring system in place.
So you’ll probably never know what happened to your internal network but …
Moral of the story is:
Nothing should be left behind when speaking in terms of security. This attack could have been mitigated in many ways, from server hardening to web application firewall installation and maintenance.
Approach offers all the services you might need to secure your infrastructure:
