Giovanni Merlos Mellini is the Head of Information, Systems and Network Security at Enav S.p.A., the Italian Air Navigation Service Provider. He is also the founder of the not-for-profit association Cyber Saiyan and the organiser of RomHack, a free security event that took place in Rome on last September.
During Codemotion Rome 2019, Giovanni delivered a speech explaining how, as security people, we must take care about security from the beginning of any project. This means implementing a security-by-design approach. You’ll experience security issues sooner or later if you don’t use this approach.
Uploading a dangerous payload
What happens if a system is not secured by design? If you are lucky enough to have an effective security process somewhere in your company, there is a chance you intercept the project before it goes live. However, during his speech Giovanni showed an example where a security issue was there in a production environment. We knew about this web application only after the IT department deployed it and it was actively used by the users.
Giovanni scheduled a penetration test to check for vulnerabilities on the target system. The test exposed a vulnerability: an upload form was not checking in the right way the file being uploaded. In particular, an attacker could upload arbitrary files to the server. To exploit this vulnerability, Giovanni tried to upload a simple ASPX web shell using the vulnerable web page.
The web shell will execute the Windows cmd.exe to interact with the system. Moreover, Windows anti-malware protection system removes the web shell just after the uploading.
In the first test, it was identified as malicious software. However, it was quite easy to bypass the protection: just rename cmd.exe to Cmd.ExE. This is funny and scary at the same time.
Demo time: exploit the RCE
This kind of attack is called RCE, Remote Code Execution, and is one of the worst vulnerabilities. It needs to be fixed as soon as possible.
In real life, patching and validation tasks take time. Therefore, the aforementioned web application is exposed to a high risk until the issue is fixed.
There are two possible solutions:
- go offline: shutdown the system until developers fix the issue;
- stay online: mitigate the risk while keeping the system online.
Mitigate the risk of keeping the system online
Let’s imagine to go for keeping the system online, trying to mitigate the vulnerability risk. The first thing to do is understanding the scenario and collecting relevant logs. In the case shown by Giovanni, the web application run on an IIS Web server with ASPX on Windows.
As a defender, you need to know your systems. One way to achieve this goal is to collect relevant data to analyse them. In this lab, Giovanni used Splunk to collect data, but there are a lot of other options (eg. Elastic Search).
These are the actions to put in place:
- collect the logs;
- find the IIS log directory;
- send the logs to a central log collector (configure a local agent to monitor in real-time the IIS logs and send them to the central collector that keep also a secure copy of the log files – it can also be useful in case of forensic activities);
- analyse logs while the problem is happening;
- find attack patterns.
Write your own detection rule
We are now ready to write our detection rule. To this end, we need to:
- identify pattern unique fields: starting from the log analysis, we look for unique fields into the logs while the attack happens;
- minimise the false positives: the goal is to be accurate to reduce the number of false positives, so security analysts will only work on real events;
- schedule a search for the pattern: no one can identify the pattern by hand, we have to automate the detection phase;
- create an alert: when the event happens an action will be executed, a script is called that will open a ticket on our service desk platform.
At this point, we mitigated the vulnerability risk; we could detect the event in real-time, generate an action and respond to the events.
Respond to the incident
We are now ready to react to the attack. While the attack happens we are notified on our service desk and we can easily see the attack details. Having all process phases and procedures in place, we can react.
Final remarks
It is clear that, in my view, security is an enabler and not a blocker!
You must think secure from the beginning of the project and ask for security requirements.
Remember, there is not a magic potion: security problems are often a chain of missing controls and missing controls and configurations.
